Testplanung

R 2.1.0

Was ist Testplanung?

Was ist Testplanung?

Eine Aktivität im Testprozess zur Erstellung und Fortschreibung des Testkonzepts.

Anwendungsbeispiel

Anwendungsbeispiel
ALT MISSING

Theo blickte auf das vor ihm liegende Excel-Sheet, das er kurz vor der anstehenden Planungsrunde ausgedruckt hatte. Dort waren die wichtigsten Daten des Projektes aufgeführt: Sprintende, planning poker, Reviews und Retrospektive, sowie die Meilensteine, die sie sich selbst gesetzt hatten.

ALT MISSING

Zunächst hatte er mit seinem Team die Testobjekte bestimmt. Das war weniger leicht gewesen, als sie anfänglich gedacht hatten. Worauf sollten sich die Aussagen über die vorgefundene Softwarequalität beziehen? Die Fachanwendung? Einzelne fachlich definierte Module wie zum Beispiel die Personensuche? Technische Einheiten, wie beispielsweise die Workflow-Engine? Oder sollten sie die Verifikation einzelner Anforderungen in den Vordergrund stellen? Die hatten sie in sogenannten User Stories beschrieben, also eher kleinteilig. Je feingranularer ihre Testobjekte definiert waren, desto engmaschiger würde das Überwachungsnetz werden, das sie mit ihren Testaktivitäten darüber spannten. Die große Gefahr bei diesem Vorgehen war allerdings, dass sie das Zusammenspiel der einzelnen Anforderungen, Module oder Komponenten aus den Augen verlieren würden. Das wiederum sprach für die Wahl größerer, fachlich zusammenhängender Einheiten. Dann durften aber nicht die untersten Teststufen, der Komponententest und der Integrationstest, vernachlässigt werden.

ALT MISSING

Nach der Entscheidung wurden die Testobjekte priorisiert. Dazu untersuchten sie die einzelnen Objekte im Hinblick auf ihre Komplexität und das mit einem Ausfall verbundene Risiko. Dieses Verfahren hatten sie schon mehrfach angewandt und es war in die Überlegungen zur Auswahl des Testobjektes mit eingeflossen. Denn wenn die Testobjekte zu grobgranular gewählt waren, wären die Prioritäten schnell trivial geworden, denn ein Ausfall wäre stets katastrophal gewesen. Bei zu klein gewählten Einheiten dagegen wären Pflege und Aktualisierungsaufwand der fortlaufenden Risikopriorisierung schnell aus dem Ruder gelaufen.

ALT MISSING

Nach der Festlegung der Testobjekte und ihrer systematischen Priorisierung, konnte die eigentliche Planung erst ernsthaft erfolgen. Jeder Risikoklasse ordnete Theo verschiedene Testaktivitäten zu und berechnete die notwendigen Zeiträume anhand von Erfahrungswerten und der Teamgröße. Ein „Sicherheitsrahmen" berücksichtigte Krankheitszeiten und noch nicht bekannte Urlaubszeiten. Neben den reinen Testzeiten plante Theo auch notwendige Zeiten für die Erstellung von Test- und QS-Berichten ein. Eine Lehre aus der Vergangenheit war nämlich, dass diese Dokumentationspflichten allzu leichtfertig nach hinten geschoben oder am Ende überhaupt nicht erledigt wurden, weil die Erkenntnisse aus der Qualitätssicherung noch nicht Teil eines ganzheitlichen Softwareentwicklungsprozesses war und entsprechend durch die Projektleitung zur Ergänzung der Steuerungsaufgaben nicht abgerufen wurden.

ALT MISSING

Nur mit dem Excel-Sheet war Theo nicht richtig zufrieden: Die fehlende Möglichkeit zu historisieren, die Schwierigkeit, Änderungen nachzuverfolgen oder auf einen Blick kenntlich zu machen sowie die Tatsache, dass diese Sheets schnell unübersichtlich wurden und eigentlich nicht zur Textverarbeitung gedacht waren, verursachten ihm Unbehagen. Sie hatten zur Sprintplanung JIRA eingesetzt und auch das Agile-Plugin installiert. Er recherchierte im Netz nach geeigneten Planungstools. Tatsächlich gab es da einige Möglichkeiten, die sie noch unbedingt evaluieren wollten, bevor sie sich mit einer Kompromisslösung wie Excel auf den Weg machten. Letztendlich wollten sie ja agiler werden und dazu gehörte eben, dass ihre Werkzeuglandschaft Änderungen in den Anforderungen und im Vorgehen unterstützte. Dazu gehörte eben auch eine kontinuierliche Verbesserung und Anpassung der Testplanung.

Beschreibung

ALT MISSING
Abb. 1: Fundamentaler Testprozess

Bevor Softwaretests starten können, stellt sich vor der konkreten Umsetzung in den Projekten zunächst die Frage, wie man beim Testen am besten vorgeht.

Der fundamentale Testprozess nach ISTQB bietet für diese Frage eine geeignete Orientierung. Er wird durch die Testplanung und -steuerung eingeleitet. Alle folgenden Phasen im Prozess sind abhängig von den erarbeiteten Vorgaben aus dieser ersten Stufe. Die Ergebnisse der Testplanung werden im Testkonzept festgehalten und während der Projektlaufzeit fortlaufend aktualisiert.

In der Testplanung werden zunächst die abstrakten Rahmenbedingungen wie Strategie, der Umfang und das Testobjekt für den Test definiert. Die Planung des zeitlichen Aufwands sowie der benötigten Ressourcen gehören genauso dazu wie die Definition des Vorgehens inkl. Metriken und Ein- und Ausgangskriterien. Es wird ebenso definiert, welche Werkzeuge verwendet werden und wie die Berichterstattung sowie die Einbeziehung der Beteiligten vorgesehen ist.

Der konkrete zeitliche und organisatorische Testplan für die Durchführung der Testmaßnahmen entsteht in der Phase Realisierung und Durchführung und ist folgendermaßen definiert:

Testplan

Ein Testplan ist eine Liste von Aktivitäten, Aufgaben oder Ereignissen des Testprozesses, mit Angabe ihrer geplanten Anfangs- und Endtermine sowie ihrer gegenseitigen Abhängigkeiten.

Testplanungen werden grundsätzlich von einem Testmanager erstellt. Ihre Erstellung erfolgt in den meisten Fällen als ein tagesgenauer Zeitplan in Tabellenform. In einem Testplan kann abgelesen werden, welche Person zu welchem Zeitpunkt die Testfälle mit einer bestimmten Priorität oder zu einer bestimmten Anforderung vorbereiten oder durchführen soll. Ein Testplan ist so angelegt, dass Abweichungen vom geplanten Vorgehen und deren Auswirkungen automatisch aktualisiert werden können und somit unmittelbar erkennbar sind. Bei größeren Projekten empfiehlt sich der Einsatz einer speziellen Software mit Schnittstelle zum Projektplanungstool.

Wichtig für die Testplanung ist die Kenntnis des jeweiligen Testziels, da sich daraus der Umfang der Testdurchführung und die notwendigen Testfälle ergeben. Andernfalls sind Testziel oder Umfang der Testdurchführung unklar und reduzieren die Aussagekraft des Tests. Die Rahmenbedingungen für die Durchführung werden im Testkonzept festgelegt.

Vorgehen in klassischen/schwergewichtigen Prozessen

In Projekten, die dem phasengesteuerten Wasserfallmodell folgen, ist die Erstellung und Abnahme eines formalen Testplans ein Eingangskriterium, um die Prüfphase beginnen zu können.

In solchen Projekten kann für jede Teststufe ein Testplan erforderlich sein, der langfristig Anwendung findet.

Für welchen (Release-)Zeitraum der Plan jeweils zu erstellen ist, wird von der Projektleitung festgelegt.

Vorgehen in agilen/leichtgewichtigen Prozessen

In Projekten, die einem iterativen Ansatz folgen, ist die Erstellung und Abnahme eines formalen Testplans in aller Regel nicht zielführend.

Für das Testen neuer Funktionen innerhalb eines agilen Entwicklungszeitraums kann üblicherweise nicht bereits vorab ein umfassender Testplan erstellt werden. Die Planung und Entstehung liegt anders als bei phasengesteuerten Vorgehensweisen im Sprint selbst, analog zur Testfallspezifikation. Es muss kurzfristig reagiert und angepasst werden können.

Anders als die beschriebenen Tests neuer Funktionen und Regressionstests sind abschließende Abnahmetests - sofern zusätzlich gefordert - i.d.R. nicht Teil eines Sprints. In diesen Fällen sollte eine separate Planung der Tests erfolgen, z.B. durch den Product Owner.

Schätzungen des Testaufwands

Wie bereits im Baustein Risikobasiertes Testen im QS-Baukasten erwähnt, ist der vollständige Test einer Anwendung aufgrund der Vielzahl von Abhängigkeiten und Eingabeoptionen unmöglich. Bezüglich des einzuplanenden Aufwands für Testmaßnahmen in Entwicklungsprojekten besteht daher zunächst eine gewisse Unsicherheit. Durch den Einsatz strukturierter Methoden (z.B. Expertenschätzungen, analoge Schätzungen, Delphi-Methode, 3-Punkt-Schätzverfahren) können Schätzverfahren dazu beitragen, diese Unsicherheit zu verringern und eine fundierte Prognose für die Testplanung und Kalkulation zu schaffen.

Häufig basieren die Schätzverfahren auf Annahmen und Erfahrungswerten, was immer noch einen gewissen Rest an Unsicherheit mit sich bringt. Eine kontinuierliche Überprüfung und Anpassung der Schätzverfahren ist daher im gesamten Projektverlauf wichtig.

Ein in der Praxis häufig auftretendes Problem stellt die Einsortierung des Tests als letzte Aktion vor der Inbetriebnahme dar. In dieser letzten von aufeinander folgenden Phasen kommt es dann nicht selten dazu, dass sich die ausstehenden Entwicklungsarbeiten verzögern, während der Go-Live Termin jedoch feststeht und aus unterschiedlichen Gründen nicht verschoben werden darf. Somit werden die eingeplanten Testkapazitäten aus Terminzwängen oft gekürzt und eingespart. Eine Lösung für diese Herausforderung ist der sogenannte „Shift-Left-Ansatz“, welcher die Testaktivitäten früher und effizienter in den Entwicklungsprozess einbinden soll. Maßnahmen dieser Art können dazu beitragen, den Testaufwand zu optimieren.

Eine projektübergreifende Verallgemeinerung des Testaufwands ist aus den genannten Gründen sehr schwierig. Nach der im Buch "Basiswissen Softwaretest" von Andreas Spillner und Thilo Linz ausgesprochenen Empfehlung sollte der angenommene Aufwand für die gesamten QS-Maßnahmen der Tests nicht unter 50% des Entwicklungsaufwandes angesetzt werden. Liegen keine detaillierten Anhaltspunkte zum Projekt vor, hat sich diese Faustregel in der Praxis durchaus bewährt.

Grundsätzlich erfordern umfangreiche Entwicklungsarbeiten oft auch umfassendere Tests. Das Verhältnis zwischen Entwicklungs- und Testaufwand kann jedoch je nach eingesetzter Technologie, Projektkontext oder Testmethoden variieren. Es empfiehlt sich, ein ausgewogenes Verhältnis zwischen den beiden anzuwenden, damit Fehler früh entdeckt und kostengünstig korrigiert werden können.

Vorlagen

Im Bereich der Vorlagen sind als Anregung und Einstieg in das Thema initiale Testplanung zwei Tools auf Excel Basis hinterlegt. Diese Entwürfe sollen anhand eines vereinfachten Beispiels darstellen, wie die Berechnung der benötigten Ressourcen für eine feststehende Menge an Testfällen bzw. User Stories erfolgen kann.

Die Benutzung wird in dem jeweiligen Tabellenblatt "HowTo" erklärt.

Quellen