Das vierte Gebot …

…“Du sollst einen Testplan (Konzept) schreiben.“
Wie man das Kind nun genau nennt ist nicht so wichtig, wichtig ist eigentlich nur, dass die wesentlichen Punkte enthalten sind. Der Anspruch an einen Testplan sollte grundsätzlich sein, dass er alle Informationen enthält, die ein anderer Performance Engineer brauchen würde um den Test tatsächlich so durchführen zu können, wie es geplant war.
So ein Testplan kann in der Form eines Worddokumentes, eines Excel Sheets oder einer PowerPoint Präsentation erstellt werden. Auch das ist nicht entscheidend. Im Zweifel tut es auch eine E-Mail oder ein einfaches Textdokument. Welche Form am geeignetsten ist entscheide ich normalerweise danach, welche Form in dem jeweiligen Projekt geläufiger ist.

Die zweite wichtige Funktion des Testplanes ist, dass er auch als Abstimmungsgrundlage der am Projekt beteiligten Parteien dienen können sollte. Im Idealfall ist dieses Dokument zumindest inhaltlich final, bevor der Test beginnt und wurde von allen wesentlichen Steakholdern (Projektleitung, Entwicklung, Testmanagement, Administration etc.) abgenommen oder zumindest gereviewed. Auf diese Weise kann man sicher stellen, dass alle Beteiligten das Gleiche meinen, wenn sie das Gleiche sagen.

Was sollte nun also in so einem Testplan enthalten sein?
Ich habe mal ein Inhaltsverzeichnis zusammengestellt, dass sich aus meiner Sicht bewährt hat. Es enthält die Punkte, die ich in fast allen Projekten für den Mindestumfang halte. Es mag sein, dass der ein oder andere Punkt in einem konkreten Projekt auch mal unnötig ist, vor allem aber kann es erforderlich sein, dieses zu erweitern. Das hängt dann von den Besonderheiten des Projektes, der Anwendung, des Testes, des Umfeldes ab.

Das erste Kapitel: INTRODUCTION soll alle Informationen über das Projekt, die zu testende Anwendung, die generellen Testziele und die Infrastruktur enthalten. Mögliche Gliederungspunkte wären hier:
1.1 PURPOSE: Was haben wir eigentlich vor, was ist der Sinn dieses Dokuments
1.2 INTENDED AUDIENCE: An Wen richtet sich dieses Dokument?
1.3 TIMELINES AND MILESTONES: Was sind die wesentlichen bekannten zeitlichen Rahmenbedingungen? Wann ist beispielsweise der Release geplant oder das Testende? Ab wann steht die Testumgebung zur Verfügung? etc.
1.4 DEPENDENCIES: Gibt es Abhängigkeiten für diesen Test, die wesentlich zu beachten sind? Wer muss informiert sein? Wer muss was und wann bereitstellen? etc.
1.5 SCOPE: Was ist Bestandteil des Tests und was ist es nicht?
1.6 OBJECTIVE STATEMENT: Was ist das Ziel des Tests? Wann ist er erfolgreich beendet?
1.7 TEST OBJECT: Beschreibung des Testobjektes, also der Anwendung, der Systemarchitektur, der Systemlandschaft bzw. den Kontext in der Systemlandschaft. Insbesondere die Nicht-Funktionalen Anforderungen sollten hier als Unterkapitelfestgehalten werden.
1.8 TEST ENVIRONMENTS: Auf welcher Umgebung wird tatsächlich getestet? Gibt es Unterschiede zur Produktionsumgebung? Wenn ja: Welche?
1.9 REQUIREMENTS ON TEST DATA: Gibt es für diesen Test besondere Anforderungen an die Testdaten? Muss ein bestimmter Satz Stammdaten vorhanden sein etc.
1.10 TOOLS Welche Tools werden eingesetzt, und wie sind diese Verfügbar. Welches Lasttesttool, aber auch welche Monitoring Tools oder Performanceanalyse Tools sollen verwendet werden? In welchen Versionen und wie sind diese zugänglich?

Das zweite Kapitel STAKEHOLDERS / CONTACT PPERSONS sollte alle Namen, Kontaktinformationen und Rollen von Personen, die an diesem Projekt beteiligt sind enthalten. Aber auch alle anderen Informationen über organisatorische Besonderheiten sollten hier festgehalten werden.

Das wesentliche Kapitel ist nun das dritte Kapitel TEST APPROACH. Hier wird der konkrete Testansatz beschrieben, der verwendet werden soll.
Die Gliederung könnte dann wie folgt aussehen
3.1 USE CASE DESCRIPTION: Die detaillierte Beschreibung der Anwendungsfälle, die automatisiert werden sollen. Jeder Anwendungsfall repräsentiert bei einer GUI Anwendung einem Script. Bei Services vielleicht einer Action. Da eine Beschreibung der Anwendungsfälle in der Form von Klickpfaden mit Screenshots für alle Beteiligten am eindeutigsten sind, bevorzuge ich diese Form. In diesem Fall kann man in diesem Kapitel auf die jeweiligen Dokumente verweisen. Es sollte aber ein einheitlicher eindeutiger Name verwendet werden.
3.2 QUANTITY STRUCTURE: Wenn bereits ein detaillierter Workload feststeht ist dieses Kapitel nicht unbedingt nötig, da dies aber meist nicht der Fall ist bevorzuge ich dieses. In diesem Teil sollte alles genannt werden, was an quantitativen Angaben über das System bekannt ist. Es dient vor allem dazu das zustande kommen des Workloads zu erklären.
3.3 WORKLOAD: Die Konkrete Definition des Workloads. Oftmals definiere ich auch mehrere wie beispielsweise „Average Business Day“ oder „Busy Business Day“. Wesentlich ist aber, dass hier je Workload genannt ist, welche Anwendungsfälle enthalten sind und wie oft jeder Fall pro Stunde ausgeführt werden soll.
3.4 SZENARIO PLANNING: In diesem Kapitel werden die Testläufe geplant. Für jeden Testlauf sollte festgehalten werden: Welcher Workload wird verwendet? Welche Nicht funktionalen Anforderungen sollen nachgewiesen werden? Wie viele vUser werden verwendet? Wie ist das Pacing je Gruppe? Dauer des Tests, Verlauf der Lastwechsel

Wie oben schon erwähnt kann dies in einem Worddokument passieren dann macht die Gliederung sinn. Die verschiedenen Kapitel können aber jeweils auch auf ein paar PowerPoint Seiten oder Excel Blättern mit weniger Prosa festgehalten werden.

1 Gedanke zu “Das vierte Gebot …”

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.