Was ist ein Testplan?
Ein Testplan ist ein detailliertes Dokument, das die Teststrategie, Ziele, Ressourcen, den Zeitplan und den Umfang eines Testvorhabens umreißt. Er ist die Blaupause für die gesamte QA-Phase — er beantwortet, wer was, wie und wann testet und wie „fertig" aussieht.
Betrachte einen Testplan als Vertrag zwischen dem QA-Team, den Entwicklern und den Stakeholdern. Er setzt Erwartungen, definiert Verantwortlichkeiten und liefert eine Roadmap für die Testausführung. Ob du eine kleine Website oder eine große Enterprise-Anwendung testest — ein guter Testplan hält alle im Einklang.
Dieser Artikel bietet eine kostenlose, zum Kopieren bereite Testplan-Vorlage mit einem praxisnahen Beispiel, sodass du deinen eigenen Testplan in wenigen Minuten erstellen kannst.
Testplan-Vorlage (Zum Kopieren bereit)
Nachfolgend findest du eine umfassende Testplan-Vorlage. Kopiere sie in dein Dokument, deine Tabelle oder dein Projektmanagement-Tool und passe sie an dein Projekt an.
Test Plan
=========
### 1. Introduction
1.1 Purpose
[Brief description of why this test plan exists]
1.2 Scope
[What is being tested — include features, modules, systems]
1.3 Out of Scope
[What is NOT being tested — be explicit]
1.4 References
[Links to requirements docs, design specs, user stories]
### 2. Test Objectives
[What you want to achieve with testing. Examples:]
- Verify all critical business workflows function correctly
- Ensure cross-browser compatibility (Chrome, Firefox, Safari, Edge)
- Validate data integrity across all CRUD operations
- Achieve 95%+ test case pass rate before sign-off
### 3. Test Strategy
3.1 Testing Levels
[ ] Unit Testing
[ ] Integration Testing (SIT)
[ ] System Testing
[ ] User Acceptance Testing (UAT)
3.2 Testing Types
[ ] Functional Testing
[ ] Regression Testing
[ ] Performance Testing
[ ] Security Testing
[ ] Usability Testing
[ ] Accessibility Testing
3.3 Test Environment
- Staging URL: [https://staging.example.com]
- Database: [PostgreSQL 15, staging replica]
- Browser targets: [Chrome 125+, Firefox 125+, Safari 17+, Edge 125+]
- Mobile targets: [iOS 17+, Android 14+]
- Test tools: [BugCapturer, Lighthouse, axe DevTools]
### 4. Test Deliverables
[ ] Test Plan Document (this document)
[ ] Test Case Specifications
[ ] Test Data (dummy accounts, sample content)
[ ] Bug Reports (logged during execution)
[ ] Test Execution Report (pass/fail summary)
[ ] UAT Sign-Off Document
### 5. Test Schedule
| Phase | Start Date | End Date | Duration |
|-------|------------|----------|----------|
| Test Planning | [Date] | [Date] | [X days] |
| Test Case Preparation | [Date] | [Date] | [X days] |
| Test Execution (Round 1) | [Date] | [Date] | [X days] |
| Bug Fixing | [Date] | [Date] | [X days] |
| Test Execution (Round 2) | [Date] | [Date] | [X days] |
| UAT | [Date] | [Date] | [X days] |
| Sign-Off | [Date] | [Date] | [X days] |
### 6. Roles & Responsibilities
| Role | Name | Responsibilities |
|------|------|-----------------|
| Test Manager | [Name] | Plan, coordinate, report |
| QA Engineer | [Name] | Write test cases, execute tests, log bugs |
| Developer | [Name] | Fix bugs, support troubleshooting |
| Product Owner | [Name] | Define acceptance criteria, UAT sign-off |
| UAT Participants | [Names] | Execute UAT scenarios |
### 7. Test Case Summary
| Module | Total Test Cases | Automation % | Priority |
|--------|-----------------|--------------|----------|
| User Registration | [XX] | [X%] | High |
| Login / Auth | [XX] | [X%] | High |
| Checkout | [XX] | [X%] | Critical |
| Search | [XX] | [X%] | Medium |
| Admin Panel | [XX] | [X%] | Low |
### 8. Bug Tracking Process
1. Tester finds a bug
2. Tester logs bug report with:
- Screenshot or screen recording (annotated)
- Steps to reproduce
- Environment details (URL, browser, OS)
- Expected vs actual result
3. Test Manager triages and assigns priority
4. Developer fixes the bug
5. Tester verifies the fix
6. Bug is closed
Recommended tool: BugCapturer for one-click bug reports
with auto-captured metadata and annotated screenshots.
### 9. Entry & Exit Criteria
9.1 Entry Criteria (what must be true before testing starts)
[ ] All critical features are developed
[ ] Staging environment is stable
[ ] Test data is prepared
[ ] Test cases are reviewed and approved
9.2 Exit Criteria (what must be true before testing ends)
[ ] All critical and high-priority bugs are fixed
[ ] 95% of test cases passed
[ ] UAT is signed off by stakeholders
[ ] Performance targets are met
### 10. Risks & Mitigation
| Risk | Impact | Probability | Mitigation |
|------|--------|-------------|------------|
| Staging environment unstable | High | Medium | Have a rollback plan, backup environment |
| Third-party API changes | Medium | Medium | Mock external services early |
| Limited UAT participant availability | High | Low | Recruit backup testers, extend UAT window |
| Scope creep | Medium | High | Freeze requirements before testing starts |
### 11. Approvals
| Role | Name | Signature | Date |
|------|------|-----------|------|
| Test Manager | [Name] | | |
| Project Manager | [Name] | | |
| Product Owner | [Name] | | |
Testplan-Beispiel
Hier ist ein ausgefülltes Testplan-Beispiel für den Launch einer E-Commerce-Website:
Projekt: AcmeShop.com v2.0 Launch Test Manager: Alex Wang Zeitplan: 4 Wochen (2 Wochen Ausführung + 1 Woche Bug-Behebung + 1 Woche UAT)
Umfang:
- Nutzerregistrierung, Login, Passwort-Reset
- Produktsuche, Suche, Filterung
- Warenkorb und Checkout
- Bestellhistorie und -verfolgung
- Admin-Bestellverwaltung
- Payment-Gateway-Integration (Stripe)
Außerhalb des Umfangs:
- Third-Party-Bestandsverwaltungssystem (separater Anbieter)
- Validierung der Migrationsdaten von Legacy v1.0
- Lasttests über 1.000 gleichzeitige Nutzer hinaus
Testfall-Zusammenfassung:
- Gesamt: 245 Testfälle (85 automatisiert, 160 manuell)
- Module: Auth (32), Produkte (48), Warenkorb (55), Checkout (70), Admin (40)
- Erwartete Bestehensquote: 95 % vor dem UAT, 98 % vor dem Launch
Wichtigste Risiken:
- Die Stripe-API-Sandbox verhält sich anders als die Produktion — gemindert durch zusätzliche Testfälle für Randfälle
- UAT-Teilnehmer sind Vertriebsmitarbeiter mit begrenzter Verfügbarkeit — 10 Teilnehmer rekrutiert, Ziel sind 5 aktive
Bug-Tracking:
- Nutzung von BugCapturer für alle Bug-Meldungen
- Kritische Bugs: innerhalb von 4 Stunden beheben, sofort erneut testen
- Bugs mit hoher Priorität: innerhalb von 24 Stunden beheben, am selben Tag erneut testen
- Bugs mit mittlerer Priorität: vor dem Launch beheben
- Bugs mit niedriger Priorität: Backlog für nach dem Launch
Beispiel-Testplan: Wichtige Abschnitte erklärt
Testziele
Dies ist der wichtigste Abschnitt. Er beantwortet „warum testen wir?". Gute Ziele sind spezifisch und messbar:- ❌ „Die Website gründlich testen"
- ✅ „Sicherstellen, dass alle 20 Checkout-Flows ohne Fehler über Chrome, Firefox, Safari und Edge hinweg abgeschlossen werden"
Eintritts- und Austrittskriterien
Eintrittskriterien verhindern verschwendeten Aufwand (nicht mit dem Testen eines defekten Builds beginnen). Austrittskriterien verhindern eine verfrühte Freigabe (Testing nicht für fertig erklären, solange kritische Bugs offen sind).Bug-Tracking-Prozess
Ein klarer Bug-Tracking-Prozess ist für eine reibungslose Testausführungsphase unerlässlich. Je schneller Bugs gemeldet werden, desto schneller werden sie behoben. Die Verwendung eines Tools wie BugCapturer während der Testausführung beschleunigt die Feedback-Schleife:- Screenshot-Anmerkung — Tester können Probleme direkt auf der Seite mit Pfeilen, Rechtecken und Text hervorheben
- Automatische Technik-Metadaten — URL, Browser, OS, Bildschirmauflösung und Viewport werden automatisch erfasst
- Bildschirmaufnahme — ein kurzes WebM-Video des Bugs aufnehmen, dann trimmen und Schlüsselframes extrahieren
- Erfassung von Diagnosedaten — Konsolenfehler und fehlgeschlagene Netzwerk-Requests werden zusammen mit den visuellen Belegen erfasst
- Excel/TSV-Export — ein Ein-Klick-Kopieren einer strukturierten Bug-Meldungszeile in deine Zwischenablage für die Team-Nachverfolgung
Wie du einen Testplan erstellst
Schritt 1: Das Projekt verstehen
Lies die Anforderungen, sprich mit Stakeholdern und verstehe, was gebaut wird. Ein Testplan ist nur so gut wie dein Verständnis des Projekts.Schritt 2: Umfang definieren
Sei explizit darüber, was im und außerhalb des Umfangs liegt. Vager Umfang ist die Ursache Nr. 1 für Testplan-Streitigkeiten.Schritt 3: Strategie wählen
Entscheide, welche Testebenen und -typen für dein Projekt gelten. Eine kleine Marketing-Site benötigt anderes Testing als eine Bankanwendung.Schritt 4: Ressourcen und Zeitplan schätzen
Nutze historische Daten aus früheren Projekten. Wenn du keine historischen Daten hast, füge deinen Schätzungen 30 % Puffer hinzu.Schritt 5: Den Plan schreiben
Nutze die obige Vorlage. Beginne mit der Vorlage und passe sie dann an. Schreibe nicht von Grund auf neu.Schritt 6: Genehmigungen einholen
Ein Testplan, den niemand freigegeben hat, ist ein Testplan, dem niemand folgt. Hole die schriftliche Genehmigung von Projektmanager und Product Owner ein.Download: Testplan-Vorlage
Die obige Vorlage funktioniert in jedem Format:
- Google Docs / Word — die Abschnittsstruktur als formales Dokument nutzen
- Confluence / Notion — eine Testplan-Seite mit Unterseiten für jeden Abschnitt erstellen
- Excel / Google Sheets — als Tabelle mit Reitern für jede Phase nutzen
- Markdown — in deinem Repo für die Versionsverwaltung halten
Wähle das Format, das dein Team nutzt. Das Format ist weniger wichtig als der Inhalt — ein guter Testplan in einem einfachen Dokument schlägt einen schlechten Testplan in einem ausgefallenen Tool.