Test Solution Architect: Wer ist es und wann wird es benötigt?

Jeden Tag gibt es im Bereich der IT immer neue Aufgaben, auch im Bereich des Testens. Wenn ein Tester früher einfach nach Anforderungen (oder ohne diese) testen musste, muss er jetzt zuerst verstehen, wie es überhaupt getestet werden kann, welche Technologien dafür benötigt werden, was automatisiert werden kann und wie ein Release-Zyklus in all diese Schande einbezogen werden kann und etc. Wer sollte diese Fragen beantworten? Wer wird mit dem Kunden kommunizieren und die Anforderungen klären? Wer erstellt die Ansätze und testet die Architektur, Anforderungen?

Als Leiter und Koordinator des Testens von Projekten für große Unternehmen und der Lösung all dieser Probleme im Laufe von drei Jahren wurde mir klar, dass es wichtig ist, immer noch eine Person zu gewinnen, die die Hauptfrage beantwortet: "Wie werden Tests durchgeführt?"
Ich habe eine kleine Untersuchung durchgeführt und festgestellt, dass eine solche Rolle bereits vorhanden ist. Sie heißt Test Solution Architect (TSA), aber nur wenige wissen davon. Und die Beschreibung von TSA-Stellenangeboten auf den Websites der Arbeitgeber überrascht mit ihrer Liste von Aufgaben und Fähigkeiten, aber ich denke, dies ist wahrscheinlicher, weil man nicht weiß, wer die TSA ist.

Aufgrund meiner Erfahrung in dieser Richtung habe ich mich entschlossen, anhand eines der realen Projekte zu zeigen, wer TSA ist und wann es gebraucht wird.

Kurze Projektbeschreibung

Ziel des Projekts war es, eine Datenbank durch eine andere zu ersetzen, genauer gesagt, Cassandra und ihr Anhang in Form von FilloDB wurden von SnowFlake im Rahmen eines täglichen, stündlichen und sogar minütlichen Flusses von Lieferung und Datenverarbeitung ersetzt. Es gab mehr als 50 solcher Abläufe, und wie von den Architekten geplant, sollte dies eine große Anzahl von Problemen lösen, die mit der Leistung, dem Datenverlust, den Wartungskosten und dem Erwerb zusätzlicher Lizenzen für Cassandra usw. zusammenhängen. Aber welche dieser Erwartungen wurden erfüllt und welche nicht - das ist das Thema eines anderen Artikels.

Welche Testrollen waren im Projekt?

In der Vergangenheit wurden beim Testen die folgenden Rollen unterschieden: ein manueller Tester oder ein Funktionstester, ein Testautomatisierungstool (derjenige, der den Code und die Tests schreibt) und ein Testmanager (derjenige, der alle anderen Probleme löst). Unser Projekt war keine Ausnahme. Das Projekt umfasste:

• 1 Testleiter oder Testleiter
• 40 manuelle Tester, die mit Scrum-Teams gearbeitet haben (7 Teams)
• 2 Entwickler (dies ist eher eine Ausnahme, da Entwickler nicht gerne an Automatisierungsaufgaben arbeiten) und 2 Testautomatisierung
• 2 Tester, die Stresstests durchgeführt haben
• 1 Funktionstester zum Testen von Produkten, der von Entwicklern und Testautomation entwickelt wurde

Manuelle Prüfung

Das Hauptziel der Funktionstester war es, die Anwendung zu testen und festzustellen, ob sie den Anforderungen des Kunden entspricht. Dafür haben Tester in der Regel:

1. Erstellen Sie Testpläne.
2. Erstellen Sie eine Teststrategie.
3. Erstellen Sie Testfälle mit geplanten Schritten (mit dem erwarteten und aktuellen Ergebnis).
4. Führen Sie Testfälle durch und lassen Sie sich von der Qualität der Anwendung überzeugen.

Wir hatten keine Kundenanforderungen oder Systembeschreibungen. Es gab nur das alte und das neue System und den Wunsch: „Lass es funktionieren, aber mit einer neuen Basis.“ Daher konnten wir nur den Like-for-Like-Ansatz anwenden - den Vergleich der Ergebnisse des alten und des neuen Systems. Alles wurde durch die Tatsache erschwert, dass wir mit einem Produktionssystem und täglich aktualisierten Daten gearbeitet haben. Leider konnten wir unser System nicht zur selben Zeit wie das Produktionssystem starten, und wir haben es später gestartet. Dies führte dazu, dass die Daten im alten und im neuen System unterschiedlich waren.

In dieser Phase stellten sich Fragen:

1. Wie kann man schlussfolgern, dass unser System ordnungsgemäß funktioniert, wenn wir aufgrund einer Zeitverschiebung Ergebnisse erzielen, die sich von denen des alten Systems unterscheiden?
2. Können wir uns von der Datenproduktion lösen und an stabilen Daten arbeiten? Was sind die Risiken?
3. Und wenn wir dennoch zu stabilen Daten kommen, wie kann dann nachgewiesen werden, dass unser System mit täglich aktualisierten Daten korrekt funktioniert?

Dies ist nur die Spitze des Eisbergs in der Liste ähnlicher Fragen, die sich während des funktionalen / manuellen Tests im Projekt stellten.

Testautomatisierung

Das Testen von Automatisierungsingenieuren (und Entwicklern) hatte das Ziel, Anwendungen zu schreiben, die die Arbeit von Funktionstestern automatisch testen und / oder erleichtern können:

• Selbsttests, die in CI / CD integriert wären;
• Anwendungen, mit denen Funktionstester getestet werden konnten;
• und andere Entwicklungen, die für die internen Bedürfnisse des Projekts benötigt wurden.

Bei dem Projekt sollten alle Anwendungen, die zum Testen entwickelt wurden, ein separates Produkt sein, das allen Entwicklungsregeln entsprach und daher an den Kunden geliefert worden wäre. Und dementsprechend stellten sich Fragen:

1. Wer entwickelt zusammen mit dem Kunden nichtfunktionale Anforderungen für Testanwendungen? Solution Architect sagte, dass dies nicht ihre Aufgabe sei SAs arbeiten mit der vom Kunden bestellten Anwendung.
2. Wer entwickelt die Funktionsanforderungen zum Testen von Anwendungen? Es gibt offensichtliche Anforderungen, aber es gibt nicht offensichtliche. Müssen wir beispielsweise die Protokolle unserer Anwendungen speichern und analysieren?
3. Wer erarbeitet mit dem Kunden die Umgebung für Anwendungen und behebt diese Anforderungen? Beispielsweise gab es speziell für dieses Projekt eine Einschränkung für Spark 1.4, die erst nach dem Erstellen der Anwendung festgestellt wurde.

Und das ist auch weit entfernt von allen Fragen, die sich im Hinblick auf die Testautomatisierung im Projekt ergeben.

Testleiter, auch bekannt als Test Lead

Der Testleiter sollte die Testprozesse im Projekt organisieren. Zu seinen Aufgaben gehörten die Verteilung von Aufgaben, das Abhalten von internen Besprechungen mit Testern, die Organisation der Arbeit mit dem Kunden (Herausfinden von Details, Überprüfen der Ergebnisse) usw. Das heißt, er konzentrierte sich auf den aktuellen Prozess und die Lösung der täglichen Probleme / Aufgaben und nicht auf die Aufgaben des Ansatzes, der Strategie und des Testens der Architektur.

Wenn es sich um technisches Test Lead handelt, dann war es verantwortlich für technische Lösungen: Die Entwicklung von Testanwendungen zu organisieren, um ein separates Softwareprodukt zu erstellen, das alle Entwicklungsregeln einhält, z etc.

In unserem Projekt wurden diese Rollen von zwei Personen gespielt, und jeder Zeitplan sah folgendermaßen aus:


In beiden Fällen ist der Testleiter damit beschäftigt, an der bereits gewählten Teststrategie zu arbeiten, aber niemand ist dafür verantwortlich, die Strategie selbst zu wählen, diese Wahl dem Kunden zu rechtfertigen und sie an Änderungen und andere Probleme anzupassen. Zum Beispiel:

1. Entwicklung eines Plans mit dem Kunden, um in die Phase der Abnahmeprüfung durch den Kunden (UAT) einzutreten.
2. Untersuchung der Anforderungen mit dem Kunden, wenn berücksichtigt wird, dass die Funktionalität auf das UAT übertragen werden kann.
3. Lernen Sie mit dem Kunden die Annahmen des Testens in verschiedenen Umgebungen (ein sehr heikler Punkt). Da die Testumgebung in der Regel nicht der Produktion entspricht, sollten alle Fragen zum Testen in einer anderen Umgebung mit dem Kunden geklärt werden.
4. Studieren Sie mit dem Kunden eine akzeptable Abweichung von Metriken in verschiedenen Arten von Tests. Welches Ergebnis erwartet ein Client beispielsweise beim Leistungstest? Vielleicht reicht es ihm, dass das System nicht schlechter funktioniert.
5. Das Sammeln aller möglichen Metriken in Zahlen, z. B. Datenabweichungen für diese Tabelle, ist zu höchstens 10% zulässig, oder das Skript sollte nicht länger als acht Stunden ausgeführt werden.

Was ist hier falsch?

Die obigen Fragen werden normalerweise auf die Schultern des Testbleis gelegt, aber es gibt einen fehlerhaften Ansatz:

1. Sie erfahren nicht, in welchen Prozessen Test Lead all diese Probleme mit dem Kunden lösen sollte. Meistens versteht ein erfahrener Testleiter dies und weiß vielleicht sogar, wie, aber höchstwahrscheinlich bleibt ein so wichtiger Teil wie das Ziel eines Unternehmens oder bestimmte Verbesserungen außerhalb des Rahmens seines Verständnisses. Dementsprechend können falsche Prioritäten eingestellt werden.
2. Test Lead tritt normalerweise in ein Projekt ein, wenn die Entwicklung bereits läuft oder gerade beginnt, d. H. er ist mit den bedingungen konfrontiert, dass es bereits vereinbarungen gibt oder sogar schon alles geregelt ist. Es ist ein Glück, wenn SA eine ausreichend erfahrene und kompetente Person ist, die sich dem Testen widmet - es hilft, die anfänglichen Vereinbarungen mit dem Kunden an die Testbedürfnisse anzupassen. In einem anderen Fall muss die Führung das Rad neu erfinden.

Und dies sind nicht alle Probleme, die auf die Messleitung fallen, wenn es keine TSA gibt.

Also, wer ist diese TSA und warum wird sie benötigt?

Test Solution Architect ist eine Person, die die Aufgabe aus betriebswirtschaftlicher, informationstechnischer und technischer Sicht betrachtet, Anforderungen mit dem Kunden abstimmt und entwickelt, eine Roadmap mit Terminen erstellt und Lösungen auf Schnittstellenebene entwickelt.

Projekte bestimmen jetzt andere Bedingungen. Projekte sind größer geworden, technisch und prozessual komplizierter und können verschiedene Branchen und Technologien abdecken. Testen ist nicht nur eine Dienstleistung, sondern auch ein Lieferant (Entwickler) von Software für den Kunden geworden. Daher muss beim Testen eine ähnliche Rolle hervorgehoben werden. Darüber hinaus sollte diese Person zusammen mit SA, die an der Produktionsanwendung beteiligt ist, in das Projekt eintreten und gleichzeitig mit der Bearbeitung aller Probleme beginnen.

Speziell in unserem Projekt spielte Test Lead die Rolle des TSA, der sich dem Projekt drei Monate nach Beginn der Entwicklung anschloss. Dies beinhaltete eine Menge zusätzlicher Arbeiten zur Harmonisierung von Anforderungen und Umgebungen, um die Vision der endgültigen Testergebnisse des Kunden herauszufinden. Infolgedessen erfüllte das Projekt die Fristen für den größten Teil seines Lebens nicht und die Kunden waren mit den Lieferungen und dem Testergebnis unzufrieden. Nicht weil die Arbeit schlecht gemacht wurde, sondern weil das vom Team produzierte Ergebnis nicht den Erwartungen des Kunden entsprach.

Wann wird TSA nicht benötigt?

Es ist klar, dass eine solche Rolle nicht für alle Projekte benötigt wird. Im Folgenden schlage ich den einfachsten Weg vor, um den Bedarf an TSA für ein Projekt zu bestimmen, je nachdem, wie der Kunde den Testansatz sieht.

Die erste Art von Projekt - der Kunde gibt die Einstellung der Testprozesse nach Ermessen des Unternehmens, das er beauftragt hat.

In diesem Fall tritt die TSA von dem Moment an in das Projekt ein, in dem sie zusammen mit SA mit der Arbeit beginnt, entwickelt Testanforderungen, entwickelt ein Testschema auf hoher Ebene, entscheidet, was als separate Anwendungen automatisiert / entwickelt wird, bestimmt die Anforderungen für diese Anwendungen und koordiniert natürlich Priorisiert mit dem Kunden die Projektziele in Übereinstimmung mit den Geschäftserwartungen.

Die zweite Art von Projekt - der Kunde hat sein eigenes Testverständnis, ein klares Bild und optimierte Prozesse.

In diesem Fall ist TSA möglicherweise nicht erforderlich, da Tests nur erforderlich sind, um sich in das vorhandene Bild der Welt einzufügen und es zu unterstützen. Wenn das Verständnis jedoch oberflächlich ist, muss die TSA nicht nur alle diese Aktionen für die erste Art von Projekten ausführen, sondern auch dem Kunden beweisen, dass dies alles notwendig ist.

Die dritte Art von Projekt - der Kunde benötigt keine TSA-Dienste.

Die Gründe können unterschiedlich sein:

1. Ein kleines und kurzfristiges Projekt mit einfacher Funktionalität.
2. Der Kunde hat eine eigene TSA.
3. Der Kunde weigerte sich zu testen, etc.

TSA Fähigkeiten

Die Praxis des Solution Architect wird seit langem erfolgreich in der Entwicklung angewendet. Aufgrund dieser erfolgreichen Erfahrung und unter Berücksichtigung des Umfangs und der Komplexität von Projekten, die über den Verantwortungsbereich von Test Lead hinausgehen, können wir sagen, dass die Zuweisung der Rolle von TSA eine natürliche Entwicklung von Ereignissen ist. Darüber hinaus muss die TSA in den gleichen Prozessen, Techniken und Ansätzen wie die SA geschult werden.

Kurz gesagt, meiner Meinung nach sollte die TSA Folgendes haben:

1. Mit technischen Kenntnissen im Allgemeinen und in dem Bereich, in dem er arbeitet, um die Probleme in diesem Bereich, typische Fehler, Probleme und Möglichkeiten zu deren Überprüfung zu kennen.
2. Gute Kommunikationsfähigkeiten, um den Kunden auf Testprobleme aufmerksam zu machen, Testanforderungen, Testansätze, Testberichte und viele verwandte Themen wie die Testumgebung zu erarbeiten.
3. Führungsqualitäten und proaktiv sein, weil Tests versuchen sehr oft, für später zu verlassen.
4. Gute Kenntnisse des Testens im Allgemeinen, der Testdokumentation, der Testprozesse, des Testberichts, der Ansätze usw .;
5. Gute Kenntnisse der Softwareentwicklungsregeln: Freigaberichtlinien, Versionsrichtlinien, Verständnis für CI / CD-Prozesse usw.

Auf der Grundlage des Vorstehenden sollte die TSA über dieselben Kenntnisse wie die SA verfügen, sich jedoch auf die Aufgaben konzentrieren, dem Kunden ein Qualitätsprodukt zur Verfügung zu stellen. Die Arbeit der TSA wird durch die Tatsache erschwert, dass man die Meinung des Kunden zum Testen häufig ändern muss, da es sich ausschließlich um die interne Küche des Projekts handelt.

Genau das Wissen, das ich an der Solution Architect-Schule erhalten habe, hat es mir ermöglicht, das Vertrauen der Kunden in das oben beschriebene Projekt wiederherzustellen, viele Testprobleme zu lösen und die Bereitstellung aller Funktionen fast pünktlich abzuschließen sowie Prozesse einzurichten und Verträge für zukünftige Arbeiten zu unterzeichnen.

Fazit

Die IT-Branche entwickelt sich, es treten neue Aufgaben auf (Herausforderungen, wenn Sie dies wünschen), und im Falle von Tests ist die hervorgehobene TSA-Position dringend geworden. Natürlich hängt alles vom Projekt ab, aber bei Projekten, für die eine TSA erforderlich ist, müssen Sie sich bereits in der Anfangsphase mit der Arbeit befassen. Dies vermeidet Probleme in der Zukunft und hilft bei der Entwicklung des Projekts.