Ein solider Testplan ist das, was verhindert, dass Bugs in die Produktion gelangen. Mit Trupeer kannst du dir Stunden bei der Testplanung sparen, indem du mit einer kostenlosen Testplan-Vorlage startest, sie mit deinen Brand Guidelines anpasst und Testpläne in Video-Durchläufe umwandelst, die Engineering, Product und QA ausrichten.

Was ist eine kostenlose Testplan-Vorlage?

Eine kostenlose Testplan-Vorlage ist eine wiederverwendbare Struktur für das Dokument, das festlegt, was bei einer bestimmten Version oder einem Projekt getestet wird, in welchen Umgebungen, durch wen, nach welchem Zeitplan und wie du erkennst, dass das Testen abgeschlossen ist.

Die Abschnittsliste ist Standard und unstrittig. Scope, Vorgehen, Umgebungen, Ressourcen, Zeitplan, Entry Criteria, Exit Criteria, Risiken, Deliverables. Jede veröffentlichte Vorlage enthält sie, und sie ist seit den ISO- und IEEE-Traditionen, die sie seit Jahrzehnten etabliert haben, weitgehend stabil.

Die Vorlage ist nicht der Ort, an dem Testpläne scheitern. Sie scheitern an einem ganz bestimmten Moment, Monate nachdem der Plan genehmigt wurde, und das Scheitern hat immer die gleiche Form.

Das Format folgt der Nutzung. Eine kostenlose Testplan-Vorlage als Word-Datei passt zum Plan selbst: Prosa, die geprüft und vereinbart wird, und für ein kleines Release reicht ein simples Word-Layout der Testplan-Vorlage mit ein oder zwei Seiten. Eine kostenlose Testplan-Vorlage als Excel-Version passt zum Zeitplan, zur Coverage-Matrix und zur Ressourcenzuweisung. Eine kostenlose Testplan-Vorlage als PDF ist die genehmigte Kopie, die an den Release-Datensatz angehängt wird, und ein Beispiel-PDF für einen Testplan aus einer veröffentlichten Quelle ist der beste Weg, um zu sehen, wie es richtig gemacht wird.

Testpläne werden einmal gelesen und später diskutiert

Ein Testplan wird Wochen geschrieben, bevor das Testen beginnt, wenn niemand unter Druck steht. Er wird ruhig geprüft, vereinbart und abgelegt.

Dann wird er genau ein weiteres Mal gelesen: an dem Tag, an dem jemand shippen will und das Testen noch nicht fertig ist.

In diesem Moment ist jeder im Raum investiert. Das Datum wurde kommuniziert. Kunden erwarten es. Marketing hat etwas eingeplant. Das Engineering-Team arbeitet seit Wochen darauf hin und würde es gern hinter sich bringen. Und dann öffnet jemand den Testplan, liest die Exit Criteria und stellt fest, dass damit nichts wirklich geklärt ist.

Alle High-Priority-Defects gelöst. Regression Suite bestanden. UAT-Sign-off erhalten.

Jedes dieser Dinge klingt verbindlich, und keines hält unter Druck stand – aus Gründen, die im nächsten Abschnitt behandelt werden. So wird die Entscheidung getroffen, wie sie ohnehin immer getroffen worden wäre: von der Person, die am seniorsten und am stärksten investiert ist. Und der Testplan liefert ein Dokument, auf das man sich berufen kann, statt eine Einschränkung zu sein.

Der gesamte Nutzen, einen Testplan im Voraus zu schreiben, besteht darin, dass Entscheidungen, die ruhig getroffen werden, besser sind als Entscheidungen, die donnerstags um neun Uhr abends getroffen werden. Dieser Nutzen wird nur realisiert, wenn die Entscheidungen tatsächlich getroffen wurden – und in den meisten Plänen wurden sie nur beschrieben.

So passt du diese Vorlage in Trupeer an

Schritt 1: Öffne den Bereich „Templates“

Gehe im Hauptmenü zum Bereich „Templates“.

Schritt 2: Wähle eine Vorlage aus und öffne sie

Klicke auf eine beliebige Vorlage, mit der du arbeiten möchtest, um sie zu öffnen.

Schritt 3: Ansicht der Vorlage erweitern

Wenn nötig, erweitere die Vorlagenansicht, um das vollständige Layout und die Details klar zu sehen.

Schritt 4: Vorlage bearbeiten

Klicke auf „Edit“, um mit dem Ändern der ausgewählten Vorlage zu beginnen.

Im Editor kannst du:

• Neue Abschnitte hinzufügen

• Formatierungsregeln definieren oder aktualisieren

• Ein Logo hinzufügen und seine Position sowie die zugehörigen Einstellungen anpassen

Schritt 5: Speichere deine angepasste Vorlage

Nachdem du alle notwendigen Änderungen vorgenommen hast, klicke auf „Save“, um die aktualisierte Vorlage als deine eigene zu speichern.

Schritt 6: Vorschau ansehen und die Vorlage feinjustieren

Wenn du sehen möchtest, wie deine angepasste Vorlage aussieht, öffne die Vorschau.

Ausgehend vom Vorschau-Bildschirm kannst du bei Bedarf weiterhin direkt Anpassungen vornehmen und so sicherstellen, dass die Vorlage genau so erscheint, wie du es möchtest.

Mit einer Testplan-Vorlage kannst du:

• Stunden beim Schreiben sparen: Überspringe die leere Seite – mit einer Struktur, die für QA gebaut ist.

• Testabdeckung verbessern: Integrierte Abschnitte stellen sicher, dass nichts Kritisches übersehen wird.

• Im Brand bleiben: Nutze dein Logo, deine Schriftarten und Farben mit Trupeer's Brand Kit.

• Über Releases hinweg standardisieren: Verwende für jedes Produkt und jedes Release dieselbe Testplan-Vorlage.

• Audit-ready bleiben: Ausgerichtet auf IEEE 829, ISO 29119 und ähnliche Standards.

• Globale Teams erreichen: Übersetze Testpläne mit einem Klick in 65+ Sprachen.

Schreibe zuerst die Exit Criteria und nenne, wer sie aussetzen darf

Zwei Änderungen, beide günstig – und das ist das gesamte Argument dieser Seite.

Schreibe die Exit Criteria, bevor du irgendetwas anderes im Plan machst. Vor Scope, vor Vorgehen, vor dem Zeitplan. Das kehrt die übliche Reihenfolge um und zwingt die schwierigste Frage nach vorne, wenn es eine Diskussion ist – nicht eine Verhandlung. Alles andere im Plan existiert, um die Exit Criteria zu erfüllen. Wenn du sie zuerst entscheidest, entsteht außerdem tendenziell ein kürzerer Plan.

Nenne, wer jede einzelne aussetzen darf. Nicht das Team. Eine Person – nach Rolle – und ausdrücklich nicht die Person, deren Aufgabe es ist, das Release zu shippen.

Die Befugnis zum Aussetzen ist die Änderung, die die Arbeit erledigt. Exit Criteria werden fast nie formell außer Kraft gesetzt, weil es keinen Mechanismus dafür gibt – stattdessen werden sie neu interpretiert. Ein Defect wird umklassifiziert. Ein Kriterium wird großzügig gelesen. Jemand unterschreibt etwas, das er nicht verifiziert hat.

Neuinterpretation ist unsichtbar und hinterlässt keine Aufzeichnung. Ein Aussetzen ist sichtbar, erfordert eine namentlich benannte Person, die ihren Namen dafür einträgt, und erzeugt etwas, das du danach ansehen kannst. Dieser Unterschied verändert das Verhalten, bevor er irgendetwas anderes verändert – denn einen Defect in einem Meeting umzuklassifizieren ist leicht, aber eine Aussetzungsbestätigung zu unterschreiben nicht.

Füge ein weiteres Feld hinzu: Wenn ein Kriterium ausgesetzt wird, halte fest, welche kompensierende Maßnahme ergriffen wird. Zuerst das Shippen für zehn Prozent der Kunden, oder mit einem vorbereiteten Rollback, oder mit briefed Support. Eine Aussetzungsbestätigung ohne Kompensation ist nur die Entscheidung, das Risiko zu akzeptieren – und das ist manchmal richtig und sollte zumindest so benannt werden.

Exit Criteria durchsetzbar machen

Drei Eigenschaften – und die meisten veröffentlichten Kriterien haben keine davon.

Eine Zahl. Nicht „Regression Suite bestanden“, sondern „Regression Suite: hundert Prozent der Priority-One-Fälle ausgeführt, fünfundneunzig Prozent bestanden, null Priority-One-Fehler offen“. „Bestanden“ und „ausgeführt“ sind unterschiedliche Dinge. Ein Plan, der das nicht unterscheidet, meldet neunzig Prozent bestanden für eine Suite, die nur zu sechzig Prozent ausgeführt wurde.

Ein Verifizierer, der nicht die Person unter Druck ist. Die Severity-Klassifizierung ist der wunde Punkt in jedem Testprozess, weil die Menschen, die Defects klassifizieren, häufig auch die sind, die shippen wollen. Wenn du benennst, wer die Severity zuweist, und sicherstellst, dass es jemand außerhalb der Delivery Line ist, nimmst du den einfachsten Weg, um an einem Kriterium vorbeizukommen.

Eine namentlich benannte Befugnis zum Aussetzen. Wie oben – und sie sollte eine andere Person sein als der Release Owner.

Eine hilfreiche Prüfung für einen bestehenden Plan. Lies die Exit Criteria und frage für jedes einzelne: Was müsste jemand tun, um daran vorbeizukommen, ohne zu lügen? Wenn die Antwort in weniger als zehn Sekunden verfügbar ist, braucht das Kriterium eine Zahl und einen Verifizierer.

Was eine Testplan-Vorlage enthalten muss

Zehn Komponenten – zuerst die Exit Criteria.

Die Zeilen zu Umgebungen und Testdaten verdienen mehr Platz, als Vorlagen ihnen geben. Sehr viele Defects, die in die Produktion gelangen, wurden nicht übersehen, weil die Testfälle schwach waren. Sie waren unerreichbar, weil die Testumgebung tausend Datensätze hatte, während Produktion vier Millionen hat – oder weil die Timing-Bedingung, die sie auslöst, auf einer einzelnen Maschine nicht auftreten kann.

Kostenlose Testplan-Vorlage: die Struktur zum Kopieren

Mit einem echten Beispiel statt Platzhaltern ausgefüllt. Das System ist POS-Software für Convenience Stores.

Von hier kopieren.

Exit criteria. Zuerst geschrieben, mit Zahlen, Verifizierern und Befugnis zum Aussetzen.

Aussetzungen werden schriftlich mit der kompensierenden Maßnahme dokumentiert – vor dem Release, nicht danach.

Entry criteria. Build in Staging bereitgestellt. Smoke Test bestanden. Testdaten geladen und aktualisiert. Keine offenen Priority-One-Defects aus dem vorherigen Zyklus.

Scope. Im Scope: Till-Transaktionen, Rückerstattungen, End-of-Day-Abgleich, Offline-Modus und die neue Promotions-Engine. Außerhalb des Scopes: die Back-Office-Reporting-Suite, die in diesem Release unverändert bleibt; Hardware-Zertifizierung für neue Peripheriegeräte, die separat erfolgt; sowie Integrationen mit Drittanbieter-Loyalty-Providern, die durch deren eigenes Supplier-Testing abgedeckt sind und auf dieser Basis akzeptiert werden – ein Risiko, das unten dokumentiert ist.

Approach. Automatisierte Regression für die bestehenden Till- und Refund-Pfade. Manuelles exploratives Testing auf der Promotions-Engine, die neu ist. Performance-Testing bei simuliertem Peak. Offline-Modus getestet durch physisches Trennen, nicht durch Simulation.

Environments. Staging, mit einer Datenbank, die aus einem Production-Snapshot eines großen Store-Estate wiederhergestellt wurde. Vier physische Tills aus zwei Hardware-Generationen. Beachte, dass Staging einen einzelnen Application Server hat, während Production sechs hat. Daher wird das Load-Balancing-Verhalten nicht abgebildet – und dies ist als Risiko ausgewiesen.

Test data. Production Snapshot, anonymisiert, wöchentlich aktualisiert. Enthält mindestens einen Store mit mehr als fünfzigtausend historischen Transaktionen, da volumenbezogene Defects zuvor aufgetreten sind.

Schedule and window. Drei Wochen. Geschätzter Aufwand für die Ausführung: elf Tage für zwei Tester, das sind vierzehn Arbeitstage gegenüber einem Zeitfenster von fünfzehn Tagen. Ein Tag Kontingenz, der knapp ist und als Risiko dokumentiert wird.

Resources. Zwei Tester, Vollzeit. Ein Performance Engineer für drei Tage. Business Owner für zwei Tage UAT. Wenn einer der Tester in den Support gezogen wird, hält das Zeitfenster nicht mehr und Kriterium zwei ist das erste, das gefährdet ist.

Risks. Ein einzelner Application Server in Staging. Ein Tag Zeitplan-Kontingenz. Drittanbieter-Loyalty-Integration nicht von uns getestet. Business Owner ist neu in der Position.

Deliverables. Ausgeführte Testergebnisse mit Nachweisen, Defect-Reports, ein Test-Summary-Report und der unterzeichnete Aussetzungsdatensatz, falls vorhanden.

Von hier kopieren.

Testplan-Beispiel: drei High-Priority-Defects, die zu zwei wurden

Danecroft Retail Systems liefert POS-Software an Convenience Stores und beschäftigt etwa einhundertachtzig Mitarbeitende. Es veröffentlichte eine Major-Version für einen Bestand von dreihundertvierzig Stores.

Der Testplan war ein normaler. Seine Exit Criteria lauteten: alle High-Priority-Defects gelöst, Regression Suite bestanden, UAT-Sign-off erhalten.

Am Tag der Release-Entscheidung waren drei High-Priority-Defects offen. Die Regression Suite war zu neunundneunzig Prozent ausgeführt, und der Plan unterschied nicht zwischen „ausgeführt“ und „bestanden“. UAT war von einem Product Owner signiert worden, der seit fünf Wochen in der Position war.

Der Release Manager sprach das mit dem CTO an. Der CTO fragte, ob die drei Defects wirklich High Priority seien.

Zwei wurden in diesem Meeting auf Medium umklassifiziert. Der dritte wurde akzeptiert, weil ein Workaround existierte.

Niemand hatte gelogen und niemand hatte irgendetwas außer Kraft gesetzt. Der Plan enthielt keine Definition von High Priority, keine Aussage dazu, wer die Severity zuweist, keine Schwelle für die Regression-Ausführung und keine namentlich benannte Befugnis zum Aussetzen. Es gab nichts, was man außer Kraft setzen konnte – also gab es auch nichts, das man dokumentieren musste.

Einer der beiden umklassifizierten Defects führte zu Till-Freeze unter einer spezifischen Promotions-Bedingung. Er trat am Samstag zur Peak-Zeit im gesamten Estate auf. Der Retailer schätzte verlorene Verkäufe auf etwa achthundertundneunzigtausend Pfund, verhängte eine vertragliche Vertragsstrafe und Danecroft schrieb mehrere Monate an Gebühren gut.

Die Review identifizierte drei konkrete Schwächen – alle in den Exit Criteria und keine im Testen.

Die Severity wurde von den Menschen unter Druck zu shippen zugewiesen. „Bestanden“ und „ausgeführt“ wurden synonym verwendet, sodass neunundneunzig Prozent wie eine Pass-Rate klangen. Und der Sign-off nannte keine einzelne Person und spezifizierte nichts darüber, was sie bestätigten, getan zu haben.

Die Überarbeitung gab jedem Kriterium eine Zahl, benannte einen Verifizierer außerhalb der Delivery Line, benannte eine Befugnis zum Aussetzen, die nicht der Release Manager war, und verlangte Aussetzungen schriftlich mit einer kompensierenden Maßnahme.

Über die folgenden sechs Releases hinweg wurden zwei Aussetzungen ausgestellt. Beide wurden dokumentiert, beide trugen eine kompensierende Maßnahme, und während eines Release-Entscheidungsmeetings wurde kein Defect umklassifiziert.

Das Testen war ausreichend. Der Plan hatte keine Mechanik vorgesehen, damit das Testen überhaupt eine Rolle spielt.

So schreibst du einen Testplan in sechs Schritten

1. Schreibe zuerst die Exit Criteria, mit Zahlen, bevor du irgendetwas anderes im Dokument machst.

2. Benenne für jedes Kriterium einen Verifizierer, und stelle sicher, dass es nicht jemand ist, dessen Ziele das Release-Datum beinhalten.

3. Benenne für jedes Kriterium eine Befugnis zum Aussetzen, einschließlich der Kriterien, die überhaupt nicht ausgesetzt werden können. Mindestens eines, das nicht ausgesetzt werden kann, macht die anderen erst sinnvoll.

4. Schreibe den Scope, einschließlich dessen, was rausfällt, und erkläre, warum jede Ausschlussentscheidung akzeptabel ist.

5. Beschreibe die Umgebung ehrlich, insbesondere dort, wo sie sich von Production unterscheidet und Defects verstecken könnte.

6. Rechne den Zeitplan durch und dokumentiere die Kontingenz, sodass bei einer Komprimierung des Zeitfensters das Gespräch darüber geht, welche Kriterien gefährdet sind – statt darüber, ob das Testen fast fertig ist.

Schritt drei ist der, der die Ergebnisse verändert. Ein Plan, bei dem alles vom Shippen durch die Person ausgesetzt werden kann, ist eine Beschreibung von Absichten.

Scope und was du nicht testest

Der Abschnitt „Außerhalb des Scopes“ ist der zweitwertvollste Teil eines Testplans und bekommt in den meisten Fällen genau eine Zeile.

Drei Kategorien gehören hinein – und sie sind unterschiedlich.

Absichtlich ausgeschlossen, weil es unverändert ist. Angemessen und es wert, mit dem Grund genannt zu werden, denn „unverändert“ ist eine Annahme, die sich gelegentlich als falsch herausstellt.

Ausgeschlossen, weil es jemand anderes testet. Komponenten von Drittanbietern, Supplier-Integrationen, Hardware-Zertifizierung. Nenne, wer es testet und welche Nachweise du akzeptierst. Hier findet der Risiko-Transfer still statt.

Ausgeschlossen, weil es hier nicht getestet werden kann. Load-Balancing-Verhalten, echte Zahlungsnetzwerke, Produktionsdatenvolumen, echte Parallelität. Das sind die ehrlichen Punkte – und sie sollten sowohl im Risiko-Abschnitt als auch im Scope-Abschnitt auftauchen, weil sie die Defects benennen, die dein Prozess nicht abfangen kann.

Die dritte Kategorie ist die, die Produktionsvorfälle vorhersagt. Ein Team, das auflisten kann, was sein Testen nicht erreichen kann, ist ein Team, das weiß, wo es suchen muss, wenn etwas schiefgeht.

Testplan, Teststrategie oder Testfall?

Drei Ebenen – und die Verwirrung zwischen ihnen ist häufig genug, um es klar auszusprechen.

Eine Teststrategie ist organisatorisch. Wie dieses Unternehmen testet, welche Testarten es nutzt und welche Standards gelten. Einmal geschrieben, gilt sie über Projekte hinweg.

Ein Testplan ist spezifisch für ein Release oder ein Projekt. Diese Seite.

Ein Testfall ist eine einzelne Prüfung mit Schritten und einem erwarteten Ergebnis. Die Testdokumentations-Vorlagen-Seite behandelt das, einschließlich warum das erwartete Ergebnis dort ist, wo die meisten Test-Suites schiefgehen.

Über allen drei steht der QA-Plan, der alles abdeckt, was getan wird, um Defects zu verhindern – statt sie zu finden: Review der Anforderungen, Definition of Done, Standards für Code Reviews. Die QA-Plan-Vorlage deckt diese Unterscheidung ab. Wenn dein QA-Plan nur Testing enthält, hast du einen Testplan mit einem breiteren Titel geschrieben.

Ob das Release überhaupt shippen kann, ist eine breitere Frage als ob das Testen fertig ist – denn auch Dokumentation, Support-Readiness und Billing-Konfiguration sind Gate-Kriterien. Die Release-Anforderungen-Vorlage deckt das ab.

Varianten von Testplänen

Die Struktur bleibt, und der Fokus verschiebt sich.

Agile- oder per-Sprint-Testpläne. Meist deutlich kürzer, oft eine einzelne Seite, und häufig in die Definition of Done eingearbeitet. Das Argument zu den Exit Criteria gilt unverändert und ist wichtiger, weil die Entscheidung sich in jedem Sprint wiederholt.

User-Acceptance-Testpläne. Das Exit-Kriterium ist eine Person, die etwas unterschreibt. Daher solltest du spezifizieren, was sie bestätigt, persönlich getan zu haben. Eine Unterschrift auf einem Dokument, das niemand gelesen hat, ist die schwächste Kontrolle in der gängigen Praxis.

Performance- und Load-Testpläne. Schwellenwerte sind naturgemäß numerisch, wodurch diese Pläne am einfachsten sind, um durchsetzbare Kriterien dafür zu formulieren. Die Schwierigkeit verlagert sich darauf, ob die Umgebung repräsentative Last erzeugen kann.

Regulierte und validierte Umgebungen. In pharmazeutischen, medizinproduktbezogenen und ähnlichen Kontexten gibt es definierte Anforderungen an Testdokumentation, Traceability und Freigaben. Der Plan ist Teil eines Evidence-Pakets, das möglicherweise Jahre später inspiziert wird. Erstelle nach dem anwendbaren Standard mit qualifiziertem Input, da nichts auf dieser Seite ihn ersetzt.

Hardware und integrierte Systeme. Testpläne müssen physische Konfigurationen und Umgebungsbedingungen abdecken, und der Abschnitt zu den Umgebungen wird in der Regel der längste Teil des Dokuments.

Was eine kostenlose Testplan-Vorlage nicht beheben kann

Ein Datum, das sich nicht verschieben lässt. Wenn das Release unabhängig davon rausgeht, dokumentiert der Plan, was übersprungen wurde – statt es zu verhindern. Das ist manchmal eine legitime Business-Entscheidung und sollte offen benannt werden, statt als bestandenes Kriterium verkleidet zu werden.

Eine Umgebung, die den Defect nicht sichtbar machen kann. Kein kostenloser Download einer kostenlosen Testplan-Vorlage wird dir Produktionsdatenvolumen oder echte Parallelität liefern.

Severity, die von der interessierten Partei zugewiesen wird. Der häufigste Weg, wie Exit Criteria umgangen werden, und es ist eine Governance-Entscheidung – nicht eine Frage der Dokumentation.

Ein Zeitfenster, das nie realistisch war. Wenn du die Rechnung im Plan zumindest durchführst, wird die Lücke sichtbar, solange noch Zeit bleibt, etwas zu ändern.

Zeige, dass das Testen stattgefunden hat

Exit Criteria hängen von Nachweisen ab – und in den meisten Organisationen ist der Nachweis eine Statusspalte.

Die Regression Suite wurde ausgeführt. Jemand hat die Fälle abgehakt. Ob jeder Fall wie beschrieben ausgeführt wurde und was tatsächlich beobachtet wurde, wird nirgendwo festgehalten. Das bedeutet: Ein Kriterium, das „hundert Prozent ausgeführt“ liest, basiert auf einer Behauptung statt auf einem Datensatz. Nach einem Vorfall wird diese Behauptung geprüft – und sie lässt sich in der Regel auch nicht eindeutig in die eine oder andere Richtung belegen.

Trupeer AI erstellt den Datensatz als Nebenprodukt. Das Aufzeichnen eines Testlaufs ergibt einen schriftlichen Durchlauf mit bereits erfassten und platzierten Screenshots – zusammen mit dem Video – in deinem eigenen Branding. Was in jedem Schritt beobachtet wurde, existiert statt behauptet zu werden. Genau das braucht ein Verifizierer, um ein Kriterium ehrlich zu signieren.

Dokumentiere es. Marke es. Übersetze es. Trupeer es.

Zwei Punkte folgen. Wenn das Testen von einem ausgelagerten oder Offshore-Team durchgeführt wird, ist der Nachweis dessen, was tatsächlich getan wurde, mehr wert als ein Statusbericht – und eine Aufzeichnung ist die günstigste Form davon. Und eine Aufzeichnung eines erfahrenen Testers, der ein komplexes Szenario durchgeht, ist es, wie ein neuer Tester lernt, wie korrektes Prüfen aussieht – die Gewohnheit, die kein schriftlicher Testfall vermittelt.

Das Material liegt in deiner Knowledge Base und dient gleichzeitig als Training. Konsistenz über deine Dokumente hinweg ist eine Frage, das Brand Kit einmal festzulegen. Das Setup wird im Dokumentvorlagen-Setup-Guide abgedeckt.

Häufig gestellte Fragen

Gibt es eine kostenlose Testplan-Vorlage als Word-Version?

Word passt zum Plan selbst, weil der Großteil davon Prosa ist, die geprüft und vereinbart wird – und weil sie in der Regel auch eine Freigabe benötigt. Eine Testplan-Vorlage als Word-Datei ist das richtige Arbeitsformat.

Setze die Tabelle mit den Exit Criteria auf Seite eins. Jede Vorlage platziert sie nahe ans Ende – dort werden sie beim Entwurf zuletzt gelesen, erhalten die geringste Aufmerksamkeit und sind der einzige Teil des Dokuments, der jemals unter Druck verwendet wird.

Gibt es eine einfache Testplan-Vorlage als Word-Version?

Ja, und für ein kleines Release oder einen einzelnen Sprint ist eine einfache Testplan-Vorlage als Word-Datei mit ein oder zwei Seiten völlig angemessen.

Schneide die Abschnitte „Approach“ und „Resources“, bevor du die Exit Criteria kürzt. Ein Ein-Seiten-Plan mit numerischen Kriterien, einem benannten Verifizierer und einer Befugnis zum Aussetzen ist mehr wert als ein 15-Seiten-Plan ohne diese.

Gibt es eine kostenlose Testplan-Vorlage als Excel-Version?

Excel passt zu den Teilen eines Testplans, die tabellarisch sind: der Zeitplan, die Coverage-Matrix, die Ressourcenallokation und die Tabelle mit den Exit Criteria selbst. Eine Testplan-Vorlage als Excel-Datei erledigt das gut.

Die Abschnitte zu Scope, Vorgehen und Risiko sind Prosa und gehören in ein Dokument. Das Aufteilen eines Plans auf zwei Dateien ist in Ordnung, solange eine die andere referenziert und nur eine davon die genehmigte Version ist.

Gibt es eine kostenlose Testplan-Vorlage als PDF?

PDF ist die genehmigte Kopie, die an den Release-Datensatz angehängt wird. Exportiere eine kostenlose Testplan-Vorlage als PDF einmal, nachdem sie vereinbart wurde – mit Version und Datum – und behalte sie zusammen mit den Ergebnissen und jedem Aussetzungsdatensatz.

Dieses Paket wird geprüft, wenn später etwas schiefgeht. Und der Aussetzungsdatensatz ist der Teil, den sich die Leute am ehesten gewünscht hätten. Ein Plan ohne Aufzeichnung dessen, was ausgesetzt wurde, lässt alle dabei sein, ein Meeting aus dem Gedächtnis zu rekonstruieren.

Wo finde ich ein Beispiel-PDF für einen Testplan?

Universitäten, Beschaffungsstellen des öffentlichen Sektors und regulierte Branchen veröffentlichen echte Beispiele. Ein Beispiel-PDF für einen Testplan aus diesen Quellen ist nützlicher als eine kommerzielle Vorlage, weil es unter realen Bedingungen geschrieben wurde und oft von jemandem mit entsprechender Autorität geprüft wurde.

Lies die Exit Criteria und den Abschnitt „Außerhalb des Scopes“. Diese beiden zeigen, ob der Plan eine Kontrolle oder eine Formalität war – und es sind die Abschnitte, die sich am stärksten zwischen Organisationen unterscheiden, die zuverlässig shippen, und denen, die es nicht tun.

Lohnt sich ein kostenloser Download einer Testplan-Vorlage?

Die Abschnittsliste ist seit Jahrzehnten stabil. Daher spart dir ein kostenloser Download einer Testplan-Vorlage wenig – und jede Version bietet ungefähr dieselbe Struktur.

Beurteile jede davon anhand einer Frage. Haben die Exit Criteria Platz für eine Schwelle, einen Verifizierer und eine Befugnis zum Aussetzen? Keine davon. Das Hinzufügen dieser drei Spalten dauert zwei Minuten und ist der Unterschied zwischen einem Plan, der etwas entscheidet, und einem Plan, der nur eine Absicht beschreibt.

Was sollten Exit Criteria tatsächlich sagen?

Zahlen, Verifizierer und Befugnis zum Aussetzen. Nicht „Regression Suite bestanden“, sondern „hundert Prozent der Priority-One-Fälle ausgeführt und bestanden, verifiziert durch den QA Lead, nicht aussetzbar“.

Der Test ist, ob jemand das Kriterium erfüllen könnte, ohne die Arbeit zu machen und ohne zu lügen. Wenn ein Defect umklassifiziert werden kann, kann eine Prozentzahl als Pass-Rate gelesen werden – oder eine Unterschrift kann von jemandem gegeben werden, der nichts verifiziert hat. Dann hat das Kriterium einen Weg daran vorbei und braucht eine weitere Klausel.

Wer sollte den Testplan schreiben?

Wer auch immer das Testen anführt – wobei die Exit Criteria von jemandem vereinbart werden, der das Release-Datum nicht besitzt. Diese Trennung ist der Punkt. Deshalb haben Pläne, die komplett innerhalb eines Delivery-Teams geschrieben werden, oft weiche Kriterien.

Lass den Business Owner die Exit Criteria ausdrücklich lesen. Denn eines davon hängt in der Regel an seiner Unterschrift, und er sollte im Voraus wissen, was er bestätigt, persönlich getan zu haben.