Führung im Test: Testplanung
Hinweis der Redaktion: Willkommen zur Serie „Führung im Test“ von Softwaretest-Guru und Berater Paul Gerrard. Die Serie soll Testern mit einigen Jahren Erfahrung – besonders denen in agilen Teams – helfen, in ihren Rollen als Testleiter und Manager erfolgreich zu sein.
Im vorherigen Artikel sind wir tief in die Dokumentation und einige Best Practices eingestiegen. Diesmal wenden wir viel Wissen aus früheren Artikeln an und nutzen es, um ein Testprojekt zu planen.
Abonniere den The QA Lead-Newsletter, um benachrichtigt zu werden, wenn neue Teile der Serie veröffentlicht werden. Diese Beiträge sind Auszüge aus Pauls Leadership In Test-Kurs, den wir wärmstens empfehlen, um tiefer in dieses und andere Themen einzusteigen. Falls du dich anmeldest, nutze unseren exklusiven Gutscheincode QALEADOFFER und spare $60 auf den regulären Kurspreis!
Was ist überhaupt ein Plan?
Ein Projektplan kombiniert die Projekttätigkeiten, geschätzte Dauer, Abhängigkeiten und Liefergegenstände zu einem zeitlich geplanten Abbild der Realität.
Wenn man den Plan als Vorhersage der Zukunft betrachtet, sollte man sehr vorsichtig sein, sich darauf zu verlassen – aber genau das tun wir in der Regel.
Vielleicht bist du schon Projektmanagern begegnet, die ihren Plan als ihre persönliche Realität sehen – ihre eigene Wunschwelt. Aber wir sollten mit Projektmanagern nicht zu streng sein – oft sind sie motiviert, einen Plan zu erstellen und ihn unter allen Umständen einzuhalten.
Der Plan ist nicht die Realität; er ist ein Modell der Realität, das ständiger Anpassung bedarf.
In diesem Artikel beleuchte ich jede Phase der Testplanung, einschließlich:
- Liefergegenstände
- Wie
- Ressourcen
- Dein Unterstützungsnetzwerk
- Schätzungen
- Abhängigkeiten, Risiken und Annahmen
- Kommunikation, Verpflichtung und Berichterstattung zum Fortschritt
Zuerst wollen wir aber klären, wie nützlich ein Plan überhaupt ist.
Warum planen?
Der Zweck der Planung besteht in der Regel darin, ein abgestimmtes Vorgehen, Verpflichtungen, Abhängigkeiten, Kosten und einen Zeitplan für die Umsetzung eines Projekts zu schaffen. Der Plan ist ein gegenseitiges Verständnis zwischen Projektbeteiligten, Lieferanten und Teilnehmern und legt typischerweise Folgendes fest:
- Welche Ressourcen wann benötigt werden
- Wann Aufgaben beginnen und enden müssen und wer sie durchführt
- Welche Fähigkeiten zur Erledigung der Aufgaben erforderlich sind
- Die Werkzeuge und Technologien, die den Plan unterstützen
- Die Liefergegenstände und wann sie geliefert werden
- Die Kosten für Aufwand und benötigte Ressourcen
- Der Prozess zur Weiterentwicklung des Projekts/Prozesses durch seine Phasen
- Die Risiken, die die Lieferung gefährden.
Einige dieser Aspekte könnten in einer Strategie beschrieben oder bereits vorhanden sein. Es kann zum Beispiel bekannt sein, welche Lieferanten beteiligt sind und welche Aufgaben sie im Projekt übernehmen. Die verwendeten Werkzeuge und Technologien stehen möglicherweise fest und sind im Einsatz. Das Personal, Testumgebungen und Testdaten können ebenfalls bereitstehen. Es kann auch bereits eine Strategie geben, die Vorgehen, Methoden oder Techniken festlegt.
Während die Strategie also die Prinzipien oder die Theorie skizziert, beschreibt der Plan die praktische Umsetzung oder Logistik, wie das Projekt tatsächlich durchgeführt wird.
Eine Strategie legt fest, wie ein Projekt im Prinzip ausgeführt werden soll, der Plan definiert und bestätigt, wie das Projekt in der Praxis umgesetzt wird.
Für viele Projektmanager ist der Plan das, was in Microsoft Project steht. Ein tragfähiger Plan hängt jedoch davon ab, dass alle Projektbeteiligten wissen, was sie tun und wie sie es tun. Um das zu erreichen, müssen der Plan und das Wissen, wie Aufgaben erledigt werden, allen Beteiligten kommuniziert und von ihnen zugesagt werden.
Planung ist eine Reise, keine Aufgabe
Um den früheren US-Präsidenten Dwight D. Eisenhower zu zitieren: „Planung ist alles. Der Plan ist nichts.“ Diese Aussage ist so wichtig, dass sie in fast jedem Kontext der Arbeit an Systemprojekten wiederholt werden sollte. Doch was bedeutet es zu sagen, der Plan sei nichts? Wozu überhaupt planen, wenn das Ergebnis ein wertloser Plan ist?
Der Plan, den man am Ende hat, ist niemals wertlos, doch Eisenhowers Aussage bezieht sich auf das Planen selbst und dessen Wert im Vergleich zum Plan. Vergleichen wir kurz, wie Planung in längeren, strukturierten und agilen/kontinuierlichen Projekten jeweils funktioniert.
Strukturierte vs. Agile Planung
In einem langfristigen Projekt müssen Ihr Unternehmen, Lieferanten und das interne IT-Personal wissen, welches Engagement von ihnen verlangt wird, damit sie die Verfügbarkeit von Personal und physischen Ressourcen planen können.
Es kostet wertvolle Zeit, die erforderlichen Informationen zu sammeln, um einen Plan zu erstellen. Mit all den Abhängigkeiten von Ressourcen und Personen sowie der Zusage und Leistung von Lieferanten und internen Mitarbeitern kann vieles schiefgehen. Manche Dinge werden schiefgehen. Deshalb ist der Plan als Prognose für die Zukunft mit Schwierigkeiten behaftet.
Am Tag nach der Veröffentlichung eines Plans, und an jedem weiteren Tag, kommen neue Informationen ans Licht und Anpassungen werden nötig. Anforderungen werden verworfen; Lieferanten liefern zu spät; Umgebungen, Testdaten oder Werkzeuge sind nicht rechtzeitig einsatzbereit. Die Liste geht weiter. Planung ist niemals eine einmalige Aufgabe, sondern eine kontinuierliche – fast tägliche – Tätigkeit.
Oft werden ungeplante Ereignisse als Nebengeräusche behandelt und wenig beachtet. Doch später werden einige dieser kleinen Störungen zu großen Problemen. Eine der Herausforderungen von Wasserfallprojekten ist, dass diese kontinuierliche Anpassung mühsam sein kann, weil Änderungen meist als unnötiges Herumprobieren angesehen werden. Projekte machen oft trotzdem weiter, in der Hoffnung, dass am Ende schon alles gutgehen wird. Das ist jedoch selten der Fall, und es wurde schon oft gesagt:
Wie kommt es, dass ein Projekt ein Jahr zu spät fertig wird? Einen Tag nach dem anderen.
Der agile Ansatz ist zum Teil eine Reaktion auf die Frustration über feste oder unflexible Pläne. Agilität ist die bewährte Alternative zur Trägheit schwerfälliger, gestufter Vorgehensweisen. Bedeutet das jedoch, dass agile Projekte keine Planung benötigen? Nein.
Auch bei agilen Projekten ist eine gewisse Vorab-Planung nötig, um die Arbeit zu strukturieren, Ressourcen zu bündeln und zumindest grob den Release-Prozess für die kommenden Monate zu terminieren. Aber von Iteration zu Iteration, oft sogar täglich, wird der Gesamtplan ständig angepasst, um neue Ereignisse und Informationen zu berücksichtigen, die bekannt werden.
Planung ist eine kontinuierliche Lernerfahrung, keine Aufgabe mit einem ablieferbaren Ergebnis.
Testplanung
Bisher haben wir das Projektmanagement im Allgemeinen betrachtet und vorgeschlagen, dass Planung eine sehr kontinuierliche Aktivität ist. Nun konzentrieren wir uns speziell auf die Planung der Tests in Projekten.
Testplanung ähnelt sehr der Projektplanung – sie ist im Grunde ein Plan im kleineren Maßstab. Natürlich muss auch der Testplan in den größeren Projektplan integriert werden, da er von anderen Projektaktivitäten und -lieferobjekten abhängig ist (und umgekehrt andere Aufgaben von den Tests abhängen). Häufig werden Testpläne gestört, weil diese Abhängigkeiten nicht erfüllt werden.
Testpläne sind in der Übersicht vergleichsweise einfach. Es kann mehrere Aktivitäten geben, die von dem Hauptprojekt abhängig sind. Diese erscheinen häufig als Aufgaben im größeren Projektplan. Doch diese Aufgaben sind auf ein Team verteilt, das womöglich eine große Anzahl von Testobjekten zu planen und durchzuführen hat.
Dieses Detailniveau ist für den Zeitplan des Projektmanagers meist nicht relevant und wird in der Regel auf lokaler Ebene im Testteam definiert und verwaltet.
Sehen wir uns nun einige der Kernelemente Ihres Testplans an.
Lieferergebnisse
Was sind die Lieferergebnisse des Testens?
Was für eine Frage! Sicherlich sind es die Testspezifikationen, die Tests, die Ergebnisse und Berichte? Die Lieferergebnisse befinden sich letztlich in der Dokumentation, also müssen wir uns nur darum kümmern, das Papier abzuarbeiten und ein paar Kästchen abzuhaken.
Aber dieser Ansatz, obwohl verbreitet, trägt teilweise dazu bei, dass das Testen (und Tester) den Ruf erhalten, teure, schwerfällige Bürokraten ohne großen Wert zu sein. Immerhin: Wer liest diese endlos langen Dokumente überhaupt?
Nehmen wir an, in einem agilen Projekt ist gar keine Testdokumentation vorgesehen. Das ist wahrscheinlich, also was liefert das Testen dann? Welchen Wert hat das Testen überhaupt? Es ist etwas spät für diese Fragen, nicht wahr?
Wenn eine Komponente, ein Subsystem oder das gesamte System getestet wird, besteht das Ergebnis darin, Nachweise darüber zu erbringen, wie das System sich in bestimmten Situationen oder Kontexten verhält. Belege für das Systemverhalten werden gesammelt und zusammengestellt, um sie den Beteiligten (Entwicklern, Nutzern, Managern etc.) vorzulegen, damit diese eine Entscheidung treffen: ob Fehler behoben, eine Komponente integriert, Funktionen akzeptiert oder abgelehnt, ein Subsystem oder das ganze System freigegeben/deployt werden.
Das Lieferergebnis des Testens ist ein Nachweis über das Systemverhalten, das den Beteiligten als Entscheidungsgrundlage dient.
In manchen Projekten ist es notwendig, Testdokumentation bereitzustellen, um festzuhalten, wie ein Test ausgelegt, entworfen, implementiert und durchgeführt wurde. Aber die Beweise für das Systemverhalten sind letztlich das wichtigste und wertvollste Lieferergebnis für die Beteiligten.
Der Wert des Testens bemisst sich an dem Maß an Vertrauen, das die Stakeholder bei Entscheidungen auf Grundlage der Testergebnisse haben.
Diese Nachweise können systematisch gesammelt, tabellarisch aufbereitet und in ausgefeilten Testmanagement-Lösungen analysiert und den Stakeholdern in eleganten grafischen Formaten präsentiert werden. Oder handschriftliche Notizen dienen dem Tester dazu, die Test-Story in einem Stand-up-Meeting mündlich dem Product Owner zu erläutern.
Unabhängig von der Art der Sammlung und Präsentation ist die finale Aufgabe des Testens die Übergabe der Nachweise.
Wie
Unabhängig von Projektumfang oder Methodik basiert das Testen auf einer bestimmten Abfolge von Aktivitäten. Wir betrachten zunächst einen generischen Prozess aus Sicht des Testers (oder Teams) und anschließend einige Variationen, die auftreten können.
Es gibt sogenannte „Testaktivitäten“ und es gibt „testunterstützende“ bzw. „logistische“ Aktivitäten. Um sicherzustellen, dass Sie alle Aktivitäten im Plan berücksichtigen, können die folgenden Tabellen als nützliche Checklisten dienen.
