Führung im Test: Testplanung
Hinweis der Redaktion: Willkommen zur Reihe „Führung im Test“ von Softwaretest-Experte & Berater Paul Gerrard. Die Reihe soll Testern mit einigen Jahren Erfahrung—insbesondere in agilen Teams—helfen, als Test Leads und in Managementrollen erfolgreich zu sein.
Im vorherigen Artikel haben wir uns intensiv mit Dokumentation und Best Practices beschäftigt. Dieses Mal wenden wir viel Wissen aus den vorherigen Artikeln an und nutzen es, um ein Testprojekt zu planen.
Melde dich für den Newsletter von The QA Lead an, um benachrichtigt zu werden, wenn neue Teile der Reihe erscheinen. Diese Beiträge sind Auszüge aus Pauls Leadership In Test Kurs, den wir sehr empfehlen, wenn du tiefer in dieses und andere Themen eintauchen möchtest. Falls du dich anmeldest, nutze unseren exklusiven Gutscheincode QALEADOFFER, um $60 Rabatt auf den Gesamtpreis des Kurses zu erhalten!
Was ist überhaupt ein Plan?
Ein Projektplan kombiniert die Projekttätigkeiten, geschätzten Zeitdauern, Abhängigkeiten und Ergebnisse zu einem terminierten Modell der Realität.
Wenn man einen Plan als Zukunftsvorhersage betrachtet, wäre man sehr vorsichtig, sich darauf zu verlassen – doch genau das tun wir in der Regel.
Vielleicht hast du schon Projektmanager kennengelernt, die ihren Plan als ihre ganz persönliche Realität betrachten – ihre eigene Welt der Illusionen. Doch sollten wir mit Projektmanagern nicht zu hart ins Gericht gehen – sie sind oft motiviert, einen Plan zu erstellen und ihn unter allen Umständen einzuhalten.
Möchten Sie mehr vom The CTO Club?
Erstellen Sie ein kostenloses Konto, um diesen Beitrag fertigzulesen und einer Community von CTOs und Technikleitern beizutreten, die praxisnahe Frameworks, Tools und Einblicke für die Entwicklung, Einführung und Skalierung KI-gesteuerter Technologien teilen.
Have an account? Log In
Der Plan ist nicht die Realität; er ist ein Modell der Realität und erfordert ständige Anpassung.
In diesem Artikel gehe ich auf jede Phase der Testplanung ein, einschließlich:
- Ergebnisse
- Vorgehensweise
- Ressourcen
- Dein Unterstützungsnetzwerk
- Schätzungen
- Abhängigkeiten, Risiken und Annahmen
- Kommunikation, Engagement und Fortschrittsberichte
Doch zunächst klären wir, wie nützlich ein Plan wirklich ist.
Warum planen?
Der Zweck der Planung ist in der Regel, eine abgestimmte Vorgehensweise, ein Set an Vereinbarungen, Abhängigkeiten, Kosten und einen Zeitplan für die Durchführung eines Projekts festzulegen. Der Plan ist die Einigung zwischen den Projektbeteiligten, Lieferanten und Teilnehmern und enthält typischerweise Folgendes:
- Welche Ressourcen wann benötigt werden
- Wann Aufgaben beginnen und enden und wer sie ausführt
- Die für die Aufgaben notwendigen Kompetenzen
- Die Werkzeuge und Technologien, die den Plan unterstützen
- Die Ergebnisse und deren Liefertermine
- Die erforderlichen Kosten für Aufwand und Ressourcen
- Den Ablauf für die Umsetzung des Projekts/Prozesses durch die einzelnen Stufen
- Die Risiken, die die Lieferung gefährden.
Einige dieser Aspekte können in einer Strategie festgelegt oder bereits vorhanden sein. Es kann z.B. bekannt sein, welche Lieferanten involviert sind und welche Aufgaben sie im Rahmen des Projekts übernehmen. Die zu verwendenden Werkzeuge und Technologien können ebenfalls bereits feststehen und verfügbar sein. Auch Personal, Testumgebung und Daten können bereitstehen. Außerdem kann es schon eine Strategie geben, die den Ablauf, den Ansatz oder die zu nutzenden Techniken regelt.
Doch während die Strategie die Grundsätze oder die Theorie festlegt, beschreibt der Plan die praktische oder logistische Seite der Projektdurchführung in der Realität.
Eine Strategie legt fest, wie ein Projekt prinzipiell umgesetzt wird – der Plan definiert und bestätigt, wie das Projekt tatsächlich umgesetzt wird.
Für viele Projektmanager ist der Plan das, was in Microsoft Project steht, aber ein tragfähiger Plan setzt voraus, dass alle Projektbeteiligten wissen, was sie tun und wie. Um das zu erreichen, müssen Plan und Wissen über das Vorgehen allen Beteiligten vermittelt werden und ihr Engagement finden.
Planung ist eine Reise, keine Aufgabe
Um den ehemaligen US-Präsidenten Dwight D. Eisenhower zu zitieren: „Planung ist alles. Der Plan ist nichts.“ Diese Aussage ist so bedeutsam, dass sie in nahezu jedem Kontext von Systemprojekten wiederholt werden sollte. Aber was bedeutet es, wenn der Plan nichts ist? Was bringt die Planung, wenn das Ergebnis ein wertloser Plan ist?
Der Plan, den man am Ende hat, ist nie nutzlos, aber Eisenhowers Aussage bezieht sich auf die Bedeutung der Planung und deren Wert im Vergleich zum eigentlichen Plan. Vergleichen wir kurz, wie Planung in länger laufenden, strukturierten Projekten und in agilen/kontinuierlichen Projekten funktioniert.
Strukturierte vs. Agile Planung
In einem langfristigen Projekt müssen Ihr Unternehmen, Lieferanten und internes IT-Personal wissen, welche Verpflichtungen auf sie zukommen, damit sie die Verfügbarkeit von Personen und physischen Ressourcen einplanen können.
Es kostet wertvolle Zeit, die erforderlichen Informationen zusammenzutragen, um einen Plan zu erstellen. Angesichts all der Abhängigkeiten von Ressourcen und Menschen sowie dem Engagement und der Leistung von Lieferanten und internen Personen, können viele Dinge schieflaufen. Einige Dinge werden sicher schieflaufen. Deshalb ist ein Plan als Vorhersage der Zukunft mit vielen Schwierigkeiten behaftet.
Schon am Tag nach der Veröffentlichung eines Plans – und dann Tag für Tag – treten neue Informationen auf, und es sind Anpassungen nötig. Anforderungen werden gestrichen; Lieferanten liefern zu spät; Umgebungen, Testdaten oder Werkzeuge sind nicht rechtzeitig einsatzbereit. Die Liste lässt sich beliebig fortsetzen. Planung ist niemals eine einmalige Aufgabe, sie ist eine kontinuierliche – fast tägliche – Aktivität.
Oft werden ungeplante Ereignisse als Störgeräusche abgetan und erhalten wenig Aufmerksamkeit. Doch später werden einige dieser kleinen Störungen zu großen Problemen. Eine der Herausforderungen bei Wasserfallprojekten ist, dass diese kontinuierliche Anpassung belastend sein kann, da jede Änderung als unnötiges Herumbasteln angesehen wird. Projekte laufen dann oft einfach weiter, in der Hoffnung, „dass schon alles gut gehen wird“. Aber das ist selten der Fall, und es wurde schon oft gesagt:
Wie kommt es, dass ein Projekt ein Jahr verspätet ist? Einen Tag nach dem anderen.
Der agile Ansatz ist teilweise eine Reaktion auf die Frustration über feste oder unflexible Pläne. Agilität ist die bewährte Alternative zur Trägheit schwerfälliger, phasenbasierter Herangehensweisen. Bedeutet das aber, dass agile Projekte keine Planung betreiben? Nein.
Auch im agilen Umfeld ist eine gewisse Vorabplanung notwendig, um die Arbeit zu strukturieren, Ressourcen bereitzustellen und – zumindest grob – den Release-Prozess für die kommenden Monate zu terminieren. Doch Iteration für Iteration, oft sogar Tag für Tag, wird der Gesamtplan laufend angepasst, um auf Ereignisse und neue Erkenntnisse zu reagieren.
Planung ist eine fortwährende Lernreise, keine Aufgabe mit einem festen Ergebnis.
Testplanung
Bisher haben wir Projektplanung allgemein betrachtet und angedeutet, dass es sich um eine kontinuierliche Tätigkeit handelt. Nun konzentrieren wir uns speziell auf die Planung des Testens in Projekten.
Testplanung ähnelt sehr der Projektplanung – im Grunde handelt es sich einfach um einen Plan im kleineren Maßstab. Natürlich muss der Testplan auch in den übergeordneten Projektplan integriert werden, da er von anderen Projektaktivitäten und Ergebnissen abhängig ist (und andere Aufgaben wiederum vom Testen abhängen). Häufig werden Testpläne gestört, weil diese Abhängigkeiten nicht erfüllt werden.
Testpläne sind in ihrer Übersicht relativ einfach. Es kann mehrere Aktivitäten geben, die von übergeordneten Projekten abhängen. Diese erscheinen häufig als Aufgaben im größeren Projektplan. Allerdings sind diese Aktivitäten auf ein Team verteilt, bei dem möglicherweise eine große Anzahl von Testobjekten geplant und getestet werden muss.
Diese Detailtiefe ist für den Zeitplan des Projektmanagers nicht so relevant und wird in der Regel intern im Testteam definiert und verwaltet.
Schauen wir uns einige der Kernelemente Ihres Testplans an.
Ergebnisse
Was sind die Ergebnisse des Testens?
Was für eine Frage! Natürlich sind das die Testspezifikationen, die Tests, die Ergebnisse und Berichte, oder? Die Ergebnisse stecken im Grunde in der Dokumentation – also müssen wir uns nur darum kümmern, die Unterlagen zu erstellen und ein paar Häkchen zu setzen.
Aber dieser Ansatz, so weit verbreitet er auch sein mag, trägt teilweise dazu bei, dass Testen (und Tester) den Ruf erhalten, teure, schwerfällige Bürokraten zu sein, die wenig Mehrwert bieten. Wer liest schließlich diese umfangreichen Dokumente?
Stellen wir uns vor, es wird in einem agilen Projekt gar nicht beabsichtigt, Testdokumentation zu erstellen. Das ist sehr wahrscheinlich – aber was liefert das Testen dann in diesen Situationen überhaupt? Welchen Wert hat Testen eigentlich? Ist es dafür nicht längst zu spät, diese Fragen zu stellen?
Wenn eine Komponente, ein Subsystem oder das gesamte System getestet wurde, besteht das Ergebnis aus Nachweisen darüber, wie sich das System in einer bestimmten Situation oder einem bestimmten Kontext verhält. Nachweise über das Systemverhalten werden gesammelt und zusammengefasst, um sie den Beteiligten (Entwickler, Nutzer, Manager, usw.) vorzulegen, damit sie eine Entscheidung treffen können: Fehler beheben, eine Komponente integrieren, Funktionalität akzeptieren oder ablehnen, ein Subsystem oder das Gesamtsystem freigeben oder bereitstellen.
Das Ergebnis des Testens ist der Nachweis des Systemverhaltens, der von den Beteiligten zur Entscheidungsfindung genutzt wird.
In manchen Projekten ist es unerlässlich, Testdokumentation bereitzustellen, um festzuhalten, wie ein Test entworfen, gestaltet, implementiert und durchgeführt wurde. Aber der Nachweis des Systemverhaltens ist das eigentliche, für die Beteiligten wertvolle Ergebnis.
Der Wert von Tests bemisst sich am Maß des Vertrauens, das Stakeholder auf Grundlage der Testergebnisse in ihre Entscheidungen legen können.
Diese Nachweise können systematisch in anspruchsvollen Testmanagement-Lösungen gesammelt, tabellarisch erfasst und ausgewertet und den Stakeholdern in eleganten grafischen Darstellungen präsentiert werden. Oder handschriftliche Notizen können von einem Tester genutzt werden, um dem Product Owner die Testergebnisse mündlich in einem Stand-up-Meeting zu schildern.
Wie auch immer die Ergebnisse gesammelt und präsentiert werden, die letzte Aufgabe von Tests ist die Übergabe der Nachweise.
Wie
Unabhängig vom Umfang oder der Methodik des Projekts basiert das Testen auf einer bestimmten Abfolge von Aktivitäten. Wir betrachten einen generischen Prozess aus der Perspektive des Testers (oder Teams) und gehen anschließend auf einige der auftretenden Variationen ein.
Es gibt sogenannte „Testaktivitäten“ und dazu „testunterstützende“ oder „logistische“ Aktivitäten. Damit Sie sicherstellen, dass Sie alle Aktivitäten im Plan berücksichtigen, könnten die folgenden Tabellen als nützliche Checklisten dienen.
Eine Aktivität in der obigen Tabelle ist Ihnen vielleicht weniger geläufig: die Feedback-Aktivität. Sie mussten sicherlich auch schon mit mangelhaften Anforderungen arbeiten.
Die Aktivität Feedback, Review und Challenge ist der Punkt, an dem Tester nach eingehender Analyse und Modellierung einer Anforderung auf Probleme stoßen und mit Beispielen aufzeigen können, wo Anforderungen fehlen, unklar oder widersprüchlich sind.
Wenn Sie Anforderungen als schlecht ansehen, lohnt es sich auf jeden Fall, für diese Aktivität Raum im Ablauf einzuplanen.
Testlogistik
Testlogistik unterstützt die oben genannten Testaktivitäten. Während die Testaktivitäten relativ umfassend aufgelistet sind, variieren die logistischen Anforderungen bei jedem Projekt und in jeder Organisation. Die nachfolgende Liste ist daher nicht vollständig. In Ihrem Projekt sollten Sie sich die Mühe machen, jede Aktivität oder Abhängigkeit zu bedenken, die zur Durchführung der Tests erforderlich ist.
Ressourcen (personell, physisch)
Wir verwenden den Begriff Ressourcen oft, um die Personen in unseren Projekten zu bezeichnen, und einigen ist das unangenehm. Menschen sind keine Dinge, sondern selbstverständlich menschliche Wesen. In kleineren Projekten ist es möglich, Namen zu nennen, doch in größeren Organisationen – wenn Projektteams beteiligt sind, die vielleicht noch nicht vollständig besetzt sind – steht hinter der Zahl der Ressourcen schlicht die Zahl der Personen.
Wichtiger ist jedoch: Es zählt nicht zwangsläufig die reine Anzahl der Personen – entscheidend sind vielmehr deren Fähigkeiten. Natürlich arbeiten Menschen unterschiedlich und meist auch in unterschiedlichem Tempo, weshalb dies in der Planung berücksichtigt werden sollte.
Neben den Menschen benötigen Sie in verschiedenen Phasen unterschiedliche physische Ressourcen, damit die Tests erfolgreich durchgeführt werden können. Diese reichen vom Alltäglichen bis hin zum Hochspezialisierten, und das Fehlen von Ressourcen kann die Testmission gefährden.
Vielleicht haben Sie das Glück, bereits Zugang zu einem voll ausgestatteten, gemanagten, dedizierten Testlabor zu haben. Ist das nicht der Fall, müssen Sie möglicherweise alles spezifizieren – vom Raum und Mobiliar bis hin zu Post-its und Radiergummis – um Ihre Arbeitsumgebung zu definieren.
In der nachfolgenden Tabelle finden Sie einige typische benötigte Ressourcen. Ihre eigene Liste wird sich sicherlich in vielen Punkten unterscheiden.
Wenn Sie alle für die Umsetzung Ihres Plans erforderlichen Ressourcen ermittelt haben, überlegen Sie, ob Sie zusätzliche Aktivitäten einplanen müssen, um diese zu beschaffen.
Ihr Unterstützungsnetzwerk
Wenn die Menschen und Fähigkeiten, die Sie für die Durchführung der Tests benötigen, in Ihrem Verantwortungsbereich lägen, wären Projekte oft viel einfacher! Aber nur wenige Teams verfügen über alle Kompetenzen, die sie brauchen, oder über Befugnis und Zugriff auf die nötigen physischen Ressourcen. Viele Projekte werden im Stil von Matrixorganisationen besetzt und organisiert. Wichtige Teammitglieder berichten tatsächlich anderen Fachabteilungsleitern und können oft nur ein begrenztes Engagement zusichern.
Sie müssen eventuell eine bestimmte Stundenzahl pro Tag oder konkrete Zeitfenster für den Zugriff auf die oben genannten Spezialkompetenzen vorgeben. Manchmal werden Sie gebeten, einen akzeptablen Service-Level zu definieren, z. B. „Anfragen mit hoher Priorität werden innerhalb von dreißig Minuten beantwortet“ usw.
Schätzungen
Schätzungen in Softwareprojekten sind eine knifflige Angelegenheit. Vieles ist darüber geschrieben worden, wie schwierig oder gar unmöglich es ist, zu schätzen. Dennoch werden Schätzungen in allen Projekten gefordert, und je größer das Projekt, desto mehr sind wir auf sie angewiesen.
Wir benötigen Schätzungen, um einen Zeitplan zu erstellen, aber das Problem ist, dass Schätzungen keine Genauigkeit liefern. Das Beste, was wir erreichen können, ist, den Aufwand oder die verstrichene Zeit mit einem gewissen Maß an Vertrauen oder Wahrscheinlichkeit zu berechnen.
Manche Menschen betrachten das Schätzen als eine undurchsichtige Kunst, und es gibt sogar eine #NoEstimates-Bewegung mit einer beträchtlichen Anhängerschaft. Es gibt viel Streit darüber, ob Schätzungen jemals genau genug sein können oder ob sie überhaupt eine gute Praxis in Softwareprojekten sind.
Schätzen wird niemals eine exakte Wissenschaft sein. Aber aus meinen Erfahrungen heraus fühle ich mich wohl dabei, diese Prinzipien zu teilen:
- Anforderungen sind fehleranfällig und ungenau.
- Menschen sind mehr oder weniger kompetent, gewissenhaft und fleißig.
- Je kleiner das Arbeitspaket, desto einfacher ist es zu schätzen; unterteile große Aufgaben, wo immer möglich, in kleinere Einheiten und summiere die Schätzungen zur größeren Aufgabe auf.
- Schätzungen basieren auf Erfahrung. Wenn du keine hast, suche nach Erfahrungen anderer, die relevant sind und sich anpassen lassen.
- Dein Arbeitspaket ist einzigartig, also suche nach Arbeitsmustern in anderen bekannten Situationen, in denen du Erfahrung hast.
- Bitte andere um eine Schätzung und vergleiche. Das Diskutieren von Abweichungen offenbart Unterschiede in Erwartungen, Vertrauen und Gründlichkeit.
- Schätze die Best-Case-Situation und dann die Worst-Case-Situation. Eine gute Schätzung liegt irgendwo dazwischen.
Schätze heute und beginne mit der Arbeit; morgen und an jedem weiteren Tag wird sich, mit dem gewonnenen Wissen, deine Fertigstellungsprognose verbessern.
Abhängigkeiten, Risiken und Annahmen
In einem früheren Artikel haben wir Risiken und die Rolle des Testens im Risikomanagement besprochen. Produktrisiken beziehen sich darauf, ob das Produkt die Anforderungen der Nutzer an Funktionalität oder Technik erfüllt. Hier liegt der Fokus auf Risiken des eigentlichen Lieferplans.
In Projekten kann immer etwas schiefgehen. In deiner Planungsaktivität musst du klarstellen, welche Ausfallrisiken du berücksichtigt und eingeplant hast. Dabei gibt es drei Aspekte: Abhängigkeiten, Risiken und Maßnahmen.
Abhängigkeiten
Abhängigkeiten sind eine Liste der benötigten personellen und materiellen Ressourcen sowie Vorgängeraktivitäten, die abgeschlossen sein müssen, damit deine geplanten Aktivitäten erfolgreich sind und geliefert werden können.
Es gibt immer Abhängigkeiten bei jeder Testaktivität, ob es sich um einen großangelegten Systemtest oder eine explorative Testsitzung einer Funktion handelt. Abhängigkeiten betreffen hauptsächlich drei Aspekte.
Risiken
Das Risiko ist die Wahrscheinlichkeit, dass dein Plan bei der Umsetzung scheitert. Risiken hängen mit folgenden Dingen zusammen:
- Deine Schätzungen: Was könnte dazu führen, dass deine Schätzungen falsch sind? Ein komplexeres, fehlerhaftes, unvollständiges oder sich ständig wandelndes System könnte deine Schätzungen beeinflussen.
- Menschen, die nicht verfügbar sind, an Erfahrung oder Fähigkeiten fehlen oder sich nicht vollständig auf deine Projektphase einlassen. Das können Teammitglieder oder Personen im Unterstützungsnetzwerk sein.
- Infrastruktur wie Testumgebungen, Werkzeuge (oder Schulungen im Umgang damit) oder Büroräume, die nicht verfügbar, nicht korrekt vorbereitet oder fehlerhaft sind.
- Vorgängeraktivitäten, die nicht rechtzeitig abgeschlossen werden (oder abgebrochen werden, nur teilweise oder fehlerhaft liefern oder gar nicht liefern).
Maßnahmen
Für jedes dieser Risiken musst du die Wahrscheinlichkeit, die Auswirkung und – bei bedeutenden Risiken – eine angemessene Maßnahme oder erwartete Konsequenz bewerten. Diese Maßnahmen nehmen oft eine der folgenden Formen an:
- Annahme: Das Risiko ist als gering genug einzustufen, um es zu ignorieren oder als unbedeutend zu betrachten. Aber es steht auf dem Radar und wird als Annahme vermerkt (z.B. Verfügbarkeit, Vollständigkeit usw.)
- Anpassen: Das Risiko ist erheblich, aber es gibt eine Handlung, die seine Auswirkung auf den Plan verringern kann. Zum Beispiel kann bei einem nur teilweise ausgelieferten System der Testplan entsprechend angepasst werden, sodass nur die verfügbaren Funktionen getestet werden.
- Konsequenz: Manche Risiken lassen sich nicht integrieren. Wird das System zu spät geliefert, kann das Testen erst beginnen, wenn es geliefert wurde.
Kommunikation, Commitment und Fortschrittsberichterstattung
Zuletzt kommen wir zu einem sehr wichtigen, aber oft übersehenen Aspekt der Planung. Du kannst einen Projektplan erstellen, in dem alle Aufgaben, Teilnehmer, Ressourcen, Verantwortlichkeiten, Abhängigkeiten, Zeitrahmen, Aufwände und Kosten aufgeführt sind. Oder es handelt sich um ein mündliches Verständnis unter Mitgliedern eines agilen Teams.
So oder so muss der Plan an alle effektiv kommuniziert werden, damit jeder weiß, was und wann etwas benötigt wird.
Ein abgestimmter Plan ist ein Vertrag zwischen den Beteiligten. Wenn ein Teammanager einen Plan abzeichnet, ist dies implizit oder explizit ein Commitment, dass sein Team seinen Teil des Vertrags erfüllt.
Der Plan ist ein Vertrag zwischen den Beteiligten.
In weniger formellen Projekten existiert möglicherweise überhaupt kein schriftlicher Plan oder keine Verpflichtungen. In diesen Fällen ist der Plan eine laufende Unterhaltung zwischen den Teammitgliedern. Das Team trifft sich täglich und die aktiven Aufgaben im Plan werden in Echtzeit besprochen. Woran arbeiten die einzelnen Personen? Entspricht der Fortschritt den Erwartungen? Mit welchen Problemen sind die Beteiligten konfrontiert? Welche Probleme blockieren den Fortschritt?
In allen Projekten dient die Fortschrittsberichterstattung einem doppelten Zweck. Offensichtlich muss kommuniziert werden, wo jeder in Bezug auf seine aktuelle Projektaktivität steht. Aber der Fortschrittsbericht ist auch eine fortlaufende, regelmäßige Überprüfung, ob der Fortschritt aufrechterhalten werden kann und ob die Verpflichtung der Teilnehmer zuverlässig ist.
Vielen Dank fürs Lesen! Schauen Sie beim nächsten Mal wieder vorbei, wenn es – Sie haben es geahnt – um die Umsetzung geht!
Abonnieren Sie 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 sehr empfehlen, um noch tiefer in dieses und andere Themen einzutauchen. Falls Sie teilnehmen möchten, nutzen Sie unseren exklusiven Gutscheincode QALEADOFFER, um $60 auf den Gesamtpreis des Kurses zu sparen!
