Was ist ein Testplan? Aufbau und echtes Beispiel

Ein Testplan ist das Dokument, das festhält, was geprüft wird, wie, von wem, auf welchen Geräten und bis wann. Er definiert außerdem, was „fertig“ bedeutet, damit später niemand darüber streitet, ob das Testen abgeschlossen ist. Wenn Sie Ihr Produkt zum ersten Mal an ein QA-Team übergeben, ist dieses Dokument das, was beide Seiten auf dasselbe Ergebnis ausrichtet.

Ein guter Plan ist kein Papierkram um seiner selbst willen. Testen ohne diese Absprache läuft erfahrungsgemäß aus dem Ruder: Das QA-Team greift sich heraus, was wichtig aussieht, die Entwickler gehen davon aus, dass jemand anderes den Rest abgedeckt hat, und die Lücken zeigen sich erst nach dem Release.

Dieser Leitfaden geht durch, was in einen echten Testplan gehört, wie QAwerk das Testen mit Kunden plant und wo Testfälle hineinpassen. Statt eine generische Vorlage durchzugehen, nutzen wir Beispiele aus Projekten, die wir tatsächlich durchgeführt haben. Sich auf einen Testplan zu einigen, gehört zum Ersten, was unser engagiertes QA-Team mit einem neuen Kunden tut.

Was ein Testplan tatsächlich enthält

Die meisten Testpläne folgen demselben Aufbau, und das aus gutem Grund: Jeder Teil beantwortet eine Frage, die irgendwann jemand stellt. Der Foundation-Level-Lehrplan von ISTQB, mit dem weltweit Softwaretester zertifiziert werden, führt nahezu dieselben Abschnitte auf. Der internationale Standard für Testdokumentation, ISO/IEC/IEEE 29119-3, legt eine passende Liste fest. Das kommt hinein, in klaren Worten.

• Ziele: Das ist es, was das Testen erreichen soll, etwa zu bestätigen, dass der Checkout vor einer Weihnachtsaktion funktioniert oder dass nach einem Redesign nichts kaputtgegangen ist.
• Umfang: Er listet auf, welche Funktionen geprüft werden und, ebenso wichtig, welche nicht. Festzuhalten, was außerhalb des Umfangs liegt, verhindert die häufigste Auseinandersetzung in jedem Testprojekt.
• Testansatz: Er beschreibt, wie getestet wird: von Hand, mit automatisierten Skripten oder in Kombination. Derselbe Abschnitt nennt, was zu prüfen ist, etwa Funktionen, Geschwindigkeit oder Sicherheit.
• Ressourcen: Hier steht, wer die Arbeit übernimmt, auf welchen Geräten und Browsern und mit welchen Werkzeugen.
• Testumgebung: Sie legt fest, wo getestet wird, üblicherweise eine separate Kopie Ihres Produkts, die so eingerichtet ist, dass Tester nie echte Kundenkonten oder Daten berühren.
• Zeitplan: Er bestimmt, wann jede Testrunde beginnt und endet und wie sich diese Termine zu Ihren Release-Daten verhalten.
• Eintritts- und Austrittskriterien: Das sind die Bedingungen für den Start, zum Beispiel dass die neue Version installiert ist und die Anmeldung funktioniert. Die Austrittskriterien markieren anschließend, wann die Arbeit erledigt ist, etwa dass keine kritischen Fehler mehr offen sind.
• Risiken: Sie erfassen, was die Arbeit zum Entgleisen bringen könnte, etwa ein verspäteter Build oder ein fehlendes Testkonto, und den Ausweichplan des Teams für jeden Fall.
• Berichterstattung: Sie erklärt, wie oft Sie über Fortschritt und Fehler hören und in welcher Form.

Austrittskriterien funktionieren am besten als Zahlen, die jeder nachprüfen kann, etwa die Software-Testmetriken, auf die sich Teams für diese Entscheidung üblicherweise stützen.

Betrachten Sie diese Liste als Testplan-Vorlage: Das ist es, was Sie von jedem infrage kommenden QA-Partner erwarten sollten, nur auf Ihr Produkt zugeschnitten. Wenn Sie ein ausführlicheres Beispiel brauchen, sehen Sie sich unsere Checkliste zum Testen von mobilen Apps an.

Echte Beispiele: Wie QAwerk das Testen plant

QAwerk erstellt für jeden Kunden einen Testplan, und so läuft der Prozess in der Praxis ab:

1. Produktprüfung: Bevor wir irgendetwas planen, lesen wir Ihre Anforderungen und sehen uns an, was bereits gebaut ist, um zu erkennen, wo Probleme immer wieder auftreten.
2. Vereinbarter Umfang: Beide Seiten zeichnen ab, was getestet wird, bis hin zu exakten Geräten und Browsern. Beim Marktplatzprojekt Unpakt etwa nannte die Liste Windows 10 mit Chrome und ein iPhone X mit Safari.
3. Prioritäten: Getestet wird in Phasen, wobei die Funktionen, die für Ihr Geschäft am wichtigsten sind, zuerst geprüft werden.
4. Unerwartete Szenarien: Ein Teil des Aufwands, im Unpakt-Projekt rund 20%, geht darauf, was passiert, wenn Nutzer etwas tun, womit niemand gerechnet hat.
5. Berichterstattung: Fehler landen direkt in Ihrem eigenen Bugtracker, und Fortschrittsmeldungen kommen täglich.
6. Vollständige Abdeckung: Eine gemeinsame Checkliste hält jeden bestandenen und fehlgeschlagenen Test fest, damit nichts durchrutscht.

Natürlich wird der Prozess an die Bedürfnisse jedes Kunden angepasst. Hier einige Fälle, die sehr unterschiedliche Pläne erforderten:

• Ein knapper Termin: Mit rund einem Monat Vorlauf deckten wir für Escuela Coaching alle Funktionen, beide Nutzerrollen und 7 Geräte ab. Die App ging planmäßig live.
• Überhaupt kein QA-Prozess: Für DrAnsay haben wir zuerst die Web- und Mobil-Apps auditiert und das Testen auf die wiederkehrenden Probleme ausgerichtet, die wir gefunden haben. Seitdem sind mehr als 60 Fehler nicht in die Produktion gelangt.
• Ein Produkt noch in Entwicklung: ChitChat holte uns dazu, während die Funktionen noch geplant wurden, also haben wir die Prüfungen Funktion für Funktion entworfen, während die App Gestalt annahm. Getestet wurde auf 24 Telefonen, die auf den sambischen Markt abgestimmt waren.

So schreiben Sie einen Testplan mit Ihrem QA-Team

Wenn Sie ein QA-Team beauftragen, ist das Schreiben des Testplans Aufgabe der Tester. Ihr Teil besteht darin, zu liefern, was nur Sie wissen:

• Vorhandene Dokumente: Spezifikationen, Tickets, Designs und frühere Fehlerberichte zeigen, wie sich das Produkt verhalten soll. Lücken sind in Ordnung, denn der Plan macht aus fehlenden Details offene Fragen.
• Prioritäten: Sagen Sie dem Team, welche Funktionen Geld einbringen oder am meisten schaden würden, wenn sie kaputt wären, damit das Testen dort beginnt.
• Nutzungsdaten: Analysen zu den Telefonen und Browsern, die Ihre Kunden tatsächlich verwenden, bestimmen die Geräteliste.
• Zugänge: Testkonten und eine separate Kopie des Produkts erlauben dem Team zu arbeiten, ohne der Live-Version nahezukommen.
• Release-Termine und Freigabe: Ihr Zeitplan legt fest, wann jede Runde läuft, und Ihre Zustimmung macht den Plan endgültig.

Über diese Zulieferungen hinaus hängt vieles davon ab, was Sie bauen. Bei einer Website liegt der Schwerpunkt auf Browserkompatibilität, Telefonbildschirmen und Ladegeschwindigkeit, wie unsere Checkliste für Website-Tests zeigt. Ein Spiel dagegen ergänzt Prüfungen bei hohem Andrang, Compliance-Reviews der Stores und Beta-Runden, alles dargelegt in unserer Checkliste zum Testen von Handyspielen.

KI-Werkzeuge können inzwischen schnell einen Planentwurf erstellen. Laut dem State-of-Testing-Bericht 2026 von PractiTest nutzt die Hälfte der kleinen QA-Teams KI bereits für die Testplanung, doch nur 19,9% der Tester verlassen sich darauf, um Risiken zu erkennen. Anders gesagt: Ein Werkzeug beschleunigt das Schreiben, während die Einschätzung, was Ihrem Geschäft wirklich schaden könnte, weiterhin erfahrene QA-Ingenieure erfordert.

Wenn zu Ihrem Produkt bislang wenig schriftlich vorliegt, können unsere Dienstleistungen zum Schreiben von technischen Dokumentationen die Testfälle und weitere QA-Dokumente parallel zum Plan verfassen.

Testplan und Testfall: Wo liegt der Unterschied?

Testpläne und Testfälle werden oft verwechselt, doch die beiden Dokumente arbeiten auf sehr unterschiedlichen Ebenen.

Wenn Sie mit einem QA-Team arbeiten, schreiben und führen die Tester die Testfälle aus, und was Sie erreicht, sind Ergebnisse und Fehlerberichte. Wenn Sie die Mechanik interessiert, erklären wir in einem eigenen Artikel, wie man Testfälle schreibt.

Sie hören vielleicht auch von einer Teststrategie, die den allgemeinen Ansatz für ein ganzes Unternehmen oder eine Produktlinie festlegt. Ein Testplan setzt diese Grundsätze dann in einem konkreten Projekt um. Größere Organisationen führen die Strategie meist als eigenes Dokument, während kleinere Teams in der Regel mit einem einzigen Plan auskommen. Für einen genaueren Blick darauf, wie sich die beiden Dokumente die Arbeit teilen, lesen Sie über Teststrategien für Software.

Wo ein Testplan hingehört und warum er sich auszahlt

Im Softwaretesten-Lebenszyklus kommt die Testplanung direkt nach der Anforderungsanalyse und bevor jemand Testfälle schreibt. Diese Reihenfolge ist wichtig, weil unklare Spezifikationen einen vagen Plan hervorbringen. Unser eigener Beitrag zu den Anforderungen an Softwaretests erklärt, welche Dokumente am meisten helfen. Von dort aus prägt die Planung jede der übrigen Phasen des Softwaretests.

Ein Testplan zeigt seinen größten Wert, wenn ein Projekt die Richtung wechselt, etwa wenn eine Funktion gestrichen wird, ein Termin sich verschiebt oder eine neue Plattform hinzukommt. Statt den gesamten Umfang neu zu verhandeln, aktualisieren beide Seiten nur die betroffenen Teile und machen weiter.

Jede Zusammenarbeit mit QAwerk beginnt mit einem Testplan, damit Team und Kunde sich von Tag eins an über die Prioritäten einig sind. Das Dokument hilft unseren Testern außerdem, sich schnell in ein neues Produkt einzuarbeiten. Auf Ihrer Seite dient der Plan zugleich als klarer Nachweis dessen, was abgedeckt wurde. Lassen Sie sich einen Testplan für Ihr Produkt erstellen.

Häufige Fragen

Sehen Sie, wie QAwerk 8 Bildungsportale über Chrome, Edge und Firefox plus 12 echte iOS- und Android-Geräte für eine Plattform mit 110 Millionen jährlichen Besuchern verifiziert hat

Bitte geben Sie Ihre Geschäfts-E-Mail ein ist keine Geschäfts-E-Mail

Fallstudie Erhalten