Um zu wissen, wie man einen Testplan schreibt, muss man zuerst lernen, wie man einen Test plant.

Testplanung ist eine echte Denkaufgabe. Man sollte eine Menge Fragen stellen, um etwas über den Bereich des Projekts zu erfahren. Ihr solltet euch über die Stakeholder des Projekts informieren.

Ein Teil der Planung besteht in der Testschätzung. Hier ist etwas, das euch den Einstieg erleichtern könnte – https://www.patelmilin.com/blog/testing/points-consider-test-estimation.html

Und hier ist eine kleine Liste von Fragen, die ihr euch stellen solltet, bevor ihr mit der Aufgabe beginnt – https://www.patelmilin.com/blog/testing/questions-before-testing-software.html

Betrachten Sie diese 2 Listen nicht als eine Bibel. Sie können richtig, falsch oder unzureichend für Ihren Kontext sein. Gehen Sie sie durch und improvisieren Sie. Fügen Sie Ihre Gedanken hinzu und versuchen Sie, so viele Informationen wie möglich über das Projekt herauszufinden. Listen Sie dann Ihre Erkenntnisse auf und führen Sie eine Kosten-Nutzen-Analyse durch. Dies wird Ihnen helfen, Testideen zu entwickeln. Überlegen Sie dann, wie Sie vorgehen möchten. Erstellen Sie eine Mindmap dafür und fertig ist Ihr Testplan!

Ach ja, fast hätte ich es vergessen, schaut euch http://apps.testinsane.com/mindmaps/ an, es ist wie ein Süßigkeitenland für Tester!

 

Lasst euch einen Rat geben, den ich bei James Bach gelesen habe. Er unterscheidet gerne zwischen einem Testplan und dem Testplandokument.

Ein Testplandokument ist die schriftliche Form des Testplans. Diese kann je nach Unternehmen, für das ihr arbeitet, sehr unterschiedlich sein und meiner Erfahrung nach von schlank oder minimal bis hin zu aufgebläht reichen (ich habe in großen Unternehmen so viele aufgeblähte Testplandokumente gesehen, die auf Vorlagen basieren, die das Team „gut aussehen“ lassen oder "alles abdecken" sollen).

Die meisten „Teststandards“ wie IEEE829 scheinen sich mehr um das Dokument des Testplans und seine Struktur zu kümmern als um den Kontext dessen, was gut oder nützlich für das Team oder die Tester ist.

Ein Testplan enthält in der Regel die Logistik des Testprojekts und Ihre Teststrategie.

  • Die Logistik kann beinhalten, wer welche Tests durchführt, wann (Schätzungen) und Endtermine.
  • Bei der Teststrategie geht es darum, wie ihr die Dinge, die  ihr testen wollt, oder die Dinge, für die ihr Zeit habt, zu testen, oder die Ideen, die ihr bei der Auswahl der Tests leitet. Bachs heuristisches Teststrategie-Modell (HTSM) soll Testern helfen, ihre Teststrategie zu bestimmen.
  • Unabhängig davon, ob ihr aufschreibt (mir fallen einige Beispiele ein, bei denen ihr das nicht tun würdet) und welches Format ihr das verwendet (erstellt einen eigenen Plan für ein schlankes/minimalistisches Produkt oder ihr verwendet eine umfangreiche Vorlage), ist es am wichtigsten, den Zweck des Plans zu verstehen, und der besteht darin, eure Tests anzuleiten.

 

Zusätzlich zu den oben genannten Passagen sollte ein Testplan auch folgende Abschnitte und deren Beschreibung enthalten

  • Einstiegs- und Ausstiegskriterien: zum Starten und Beenden der Testphase
  • Kriterien für die Unterbrechung und Wiederaufnahme: Während der Testphase kann es vorkommen, dass Sie Ihre Tests aus einzelnen oder mehreren Gründen unterbrechen müssen. Dieser Abschnitt enthält die Bedingungen, unter denen Sie/Team die Tests unterbrechen und wieder aufnehmen müssen.
  • Kriterien für die Systemabnahme
  • Fehler-/Mängelmanagementprozess
  • Teamzusammensetzung mit Rollen und Verantwortlichkeiten
  • Meilensteine und Deliverables (mit geplanten Start- und Enddaten)
  • Wie bereits von anderen erwähnt, sollten Sie diese Liste nicht als eine "auf einen Felsen gezeichnete Linie" betrachten.

Euer Testplan sollte in Übereinstimmung mit Ihrem Projektplan und dem SDLC-Modell stehen, das Sie in Ihrem Projekt anwenden.

Fügt nicht zu viel in euren Plan ein, sondern haltet ihn kurz und bündig. Ich habe gesehen, dass viele Leute einen Testplan erstellen, nur um ein weiteres Dokument zu ihrem Projektrepository hinzuzufügen, und im Laufe der Zeit wird er veraltet, und das Team beginnt, auf eine andere Weise zu testen, als im Testplan angegeben.

Die Verwendung einer neuen Strategie oder eines neuen Ansatzes sind nicht schlecht, sondern es ist eine gute Sache, sich selbst und seine Strategien auf dem neuesten Stand zu halten, aber gleichzeitig sollte man auch seinen Testplan bzw. die zugehörigen Dokumente auf dem neuesten Stand halten. Der Prozess sollte also so ablaufen, dass Sie zuerst Ihren Plan aktualisieren und ihn dann umsetzen, anstatt es anders zu machen.

Ein Testplan muss das unten beschriebene Mindestgerüst aufweisen. Es ist sehr wichtig, sich den Unterschied zu merken und zu kennen. Wir sprechen hier nicht von Testkonzepten oder Strategiedokumenten. Ich habe immer Microsoft Project verwendet, um einen Plan zu erstellen und zu verfolgen, da es ein so leistungsfähiges Tool ist und eine Vielzahl von Ansichten bietet, die für jeden geeignet sind, z. B. wenn ihr jedes einzelne Element/Aufgabe und seinen Fortschritt in Prozent ansehen oder Meilensteine und sogar Ressourcen verfolgen möchtet. Außerdem ist es fast unmöglich, im gesamten Lebenszyklus des Projekts zu sehen, dass sich die Termine nicht geändert haben, sodass die Wartung einfacher wird, wenn der Testplan gut durchdacht ist. Um nun auf die konkrete Frage zurückzukommen.

Er muss enthalten:

  • Abhängigkeiten a. Design vollständig b. Entwicklung vollständig c. Testumgebung bereit d. Testressourcen verfügbar

Testaktivitäten a. Testvorbereitung abgeschlossen und abgezeichnet

  • b. Testdaten bereit
  • c. Start der Testdurchführung
  • d. Testdurchführung abgeschlossen
  • e. Test-Abschluss

Go-Live-Termine

Unterstützung bei der Inbetriebnahme

Sample Test Plan