① Testkonzept — CTFL Kap. 5.1 · FL-5.1.1 (K2)
Was ist ein Testkonzept?
Das zentrale Planungsdokument
Test Plan — ISO/IEC/IEEE 29119-3
Ein Testkonzept beschreibt Testziele, Ressourcen und Prozesse für ein Testprojekt. Es erfüllt vier Kernfunktionen:
1. Dokumentiert Mittel und Zeitplan zur Erreichung der Testziele
2. Hilft sicherzustellen, dass Testaktivitäten festgelegte Kriterien erfüllen
3. Dient als Kommunikationsmittel mit Teammitgliedern & Stakeholdern
4. Zeigt dass das Testen sich an Testrichtlinie und Teststrategie hält — oder erklärt warum es davon abweicht
1. Dokumentiert Mittel und Zeitplan zur Erreichung der Testziele
2. Hilft sicherzustellen, dass Testaktivitäten festgelegte Kriterien erfüllen
3. Dient als Kommunikationsmittel mit Teammitgliedern & Stakeholdern
4. Zeigt dass das Testen sich an Testrichtlinie und Teststrategie hält — oder erklärt warum es davon abweicht
ISO/IEC/IEEE 29119-3
Kommunikationsmittel
Planungsgrundlage
Typische Inhalte
Was steht im Testkonzept?
Kontext des Testens (Umfang, Ziele, Testbasis)
Annahmen & Einschränkungen
Stakeholder (Rollen, Verantwortlichkeiten, Schulungsbedarf)
Kommunikation (Formen & Häufigkeit)
Risikoverzeichnis (Produkt- & Projektrisiken)
Testansatz (Stufen, Arten, Verfahren, Liefergegenstände)
Eingangskriterien & Endekriterien
Unabhängigkeit des Testens
Zu erhebende Metriken
Anforderungen an Testdaten & Testumgebung
Budget & Zeitplan
In der Praxis
Dein Team soll ein neues Online-Banking-Portal testen. Bevor du anfängst, schreibst du ein Testkonzept: Welche Module testest du? (Umfang) — Wer ist für Systemtests zuständig? — Welche Testumgebung braucht ihr? — Bis wann müssen alle kritischen Bugs geschlossen sein? Das Testkonzept ist dein Vertrag mit dem Projektmanager: beide wissen danach was getestet wird, wann, mit welchen Ressourcen und was „fertig" bedeutet.② Eingangskriterien & Endekriterien — CTFL Kap. 5.1 · FL-5.1.3 (K2)
Eingangskriterien (Entry Criteria)
Vorbedingungen für den Teststart
Definieren die Vorbedingungen für die Durchführung einer bestimmten Aktivität. Wenn nicht erfüllt: Aktivität schwierig, aufwendiger als nötig und risikobehafteter.
Typische Beispiele:
Typische Beispiele:
Verfügbarkeit von Ressourcen (Personal, Werkzeuge, Umgebungen, Testdaten, Budget)
Verfügbarkeit von Testmitteln (Testbasis, testbare Anforderungen, Testfälle)
Anfängliche Qualität des Testobjekts (Smoke-Test bestanden)
Endekriterien (Exit Criteria)
Abschlussbedingungen für den Teststop
Definieren was erreicht sein muss, bevor eine Testaktivität als abgeschlossen gilt. Bildet die Basis für Go/No-Go-Entscheidungen.
Typische Beispiele:
Typische Beispiele:
Erreichter Überdeckungsgrad
Anzahl ungelöster Fehlerzustände
Fehlerdichte unter Schwellwert
Anzahl fehlgeschlagener Testfälle
Zeit/Budget aufgebraucht (gültiges Endekriterium!)
In Agile: Definition of Done
Zusammenhang — Stufenverkettung: Die Endekriterien einer Teststufe sind typischerweise Teil der Eingangskriterien der nächsten Teststufe (Verbindung zu Kap. 2.2). Endekriterien bilden also die Brücke zwischen den Stufen — und müssen im Testkonzept definiert sein, bevor getestet wird, nicht danach.
In der Praxis
Eingangskriterium Systemtest: „Das Login-Modul hat den Komponententest bestanden und ist in der Staging-Umgebung deployed." — Wenn die Entwickler das Modul noch gar nicht geliefert haben, fängst du nicht an. Du würdest sonst auf einem halbfertigen System testen und deine Zeit verschwenden.Endekriterium Systemtest: „Alle Testfälle ausgeführt, 0 kritische Bugs offen, Anweisungsüberdeckung ≥ 80 %." — Erst wenn das erreicht ist, gibst du das System für den Abnahmetest frei. Das schützt dich davor, unter Druck zu früh freizugeben.
③ Iterations- & Releaseplanung — CTFL Kap. 5.1 · FL-5.1.2 (K1)
Releaseplanung
Mehrere Iterationen — Produktperspektive
Sieht die Bereitstellung eines Produkts vor · Definiert das Produkt-Backlog bzw. passt es an · Kann die Verfeinerung größerer User Stories in kleinere beinhalten.
Beitrag des Testers: Risikobasierte Analyse des Releases · Priorisierung von User Stories · Einschätzung der Testbarkeit · Aufwandsschätzung für das Release.
Beitrag des Testers: Risikobasierte Analyse des Releases · Priorisierung von User Stories · Einschätzung der Testbarkeit · Aufwandsschätzung für das Release.
Produkt-BacklogUser Story VerfeinerungTestbarkeitseinschätzung
Iterationsplanung
Eine Iteration — Sprintperspektive
Sieht das Ende einer einzelnen Iteration voraus · Befässt sich mit dem Iterations-Backlog · Tester nehmen an der detaillierten Risikoanalyse teil.
Beitrag des Testers: Detaillierte Risikoanalyse von User Stories · Bestimmung der Testbarkeit · Aufschlußüber User Stories, Tasks und Features · Testaufwandsschätzung je Story.
Beitrag des Testers: Detaillierte Risikoanalyse von User Stories · Bestimmung der Testbarkeit · Aufschlußüber User Stories, Tasks und Features · Testaufwandsschätzung je Story.
Iterations-BacklogStory-RisikoanalyseSprint-Testplanung
④ Schätzverfahren — CTFL Kap. 5.1 · FL-5.1.4 (K3 — anwenden)
Metrikbasiert 1
Schätzung per Verhältniszahlen
Zahlen aus früheren Projekten werden gesammelt → „Standard”-Verhältniszahlen werden abgeleitet → diese Verhältniszahlen werden auf das neue Projekt angewendet.
Beispiel: Historisch: 40 Teststunden je 100 Funktionspunkte → Neues Projekt hat 250 FP → Schätzung: 100 Teststunden.
Beispiel: Historisch: 40 Teststunden je 100 Funktionspunkte → Neues Projekt hat 250 FP → Schätzung: 100 Teststunden.
MetrikbasiertHistorische Daten
Metrikbasiert 2
Extrapolation
Messungen werden so früh wie möglich im laufenden Projekt durchgeführt. Wenn genügend Beobachtungen vorliegen, wird der Aufwand durch Extrapolation der Daten vorhergesagt.
Beispiel: Nach 2 Sprints: Velocity = 30 Story Points/Sprint mit 15 Teststunden → 5 weitere Sprints → Schätzung: 75 weitere Teststunden.
Beispiel: Nach 2 Sprints: Velocity = 30 Story Points/Sprint mit 15 Teststunden → 5 weitere Sprints → Schätzung: 75 weitere Teststunden.
MetrikbasiertLaufende Messung
Expertenbasiert 1
Breitband-Delphi
Iteratives Verfahren: Jeder Experte schätzt allein den Aufwand → Ergebnisse werden geteilt → Diskussion → neue Einzelschätzung → Wiederholung bis Konsens.
Verhindert Group Thinking · Alle Perspektiven fließen ein · Erfordert mehrere Runden.
Verhindert Group Thinking · Alle Perspektiven fließen ein · Erfordert mehrere Runden.
ExpertenbasiertIterativKein Group Thinking
Expertenbasiert 2
Drei-Punkt-Schätzung (PERT)
Drei Schätzungen: a (optimistisch) · m (wahrscheinlichste) · b (pessimistisch)
Formel: E = (a + 4m + b) / 6
Standardabweichung: SD = (b − a) / 6
Beispiel: a=6, m=9, b=18 → E = (6 + 36 + 18) / 6 = 10 h · SD = 12/6 = 2 → Bereich: 8–12 h
Formel: E = (a + 4m + b) / 6
Standardabweichung: SD = (b − a) / 6
Beispiel: a=6, m=9, b=18 → E = (6 + 36 + 18) / 6 = 10 h · SD = 12/6 = 2 → Bereich: 8–12 h
ExpertenbasiertPERT-FormelPrüfungsrelevant K3
In der Praxis — Wann welches Verfahren?
Verhältniszahlen: Dein Unternehmen macht seit Jahren E-Commerce-Projekte — ihr wisst aus Erfahrung: „Wir brauchen immer ca. 3 Teststunden pro Story Point." Neues Projekt hat 80 Story Points geplant → Schätzung: 240 Teststunden.Extrapolation: Ihr steckt mitten im Projekt, habt 3 Sprints gemessen — im Schnitt 12 Bugs pro Sprint. Noch 4 Sprints geplant → Prognose: ~48 weitere Bugs, entsprechend Testaufwand einplanen.
PERT: Niemand weiß wie lang der Migrationstest dauert. Senior Tester sagen: Bestfall 3 Tage, realistisch 6, Worst Case 15. → E = (3 + 4×6 + 15) / 6 = 42/6 = 7 Tage.
⑤ Priorisierung von Testfällen — CTFL Kap. 5.1 · FL-5.1.5 (K3 — anwenden)
Strategie 1
Risikobasierte Priorisierung
Reihenfolge richtet sich nach den Ergebnissen der Risikoanalyse. Testfälle die die wichtigsten Risiken überdecken werden zuerst ausgeführt.
Vorteil: Kritischste Fehlerzustände werden früh gefunden · höchste Risikoreduzierung bei frühem Abbruch.
Vorteil: Kritischste Fehlerzustände werden früh gefunden · höchste Risikoreduzierung bei frühem Abbruch.
Risikostufe bestimmt ReihenfolgeShift-Left für kritische Tests
Strategie 2
Überdeckungsbasierte Priorisierung
Reihenfolge richtet sich nach der Überdeckung (z.B. Anweisungsüberdeckung). Testfälle die die höchste Überdeckung erreichen werden zuerst ausgeführt.
Vorteil: Maximale Codeabdeckung bei minimalem Aufwand · Sinnvoll wenn Überdeckungsziele definiert sind.
Vorteil: Maximale Codeabdeckung bei minimalem Aufwand · Sinnvoll wenn Überdeckungsziele definiert sind.
Überdeckungsgrad bestimmt ReihenfolgeCode Coverage zuerst
Strategie 3
Anforderungsbasierte Priorisierung
Priorität der Anforderungen wird auf die Testfälle übertragen. Tests für die wichtigsten Anforderungen werden zuerst ausgeführt.
Vorteil: Direkte Traceability Anforderung ↔ Test · Sinnvoll wenn Stakeholder Anforderungsprioritäten gesetzt haben.
Vorteil: Direkte Traceability Anforderung ↔ Test · Sinnvoll wenn Stakeholder Anforderungsprioritäten gesetzt haben.
Anforderungspriorität bestimmt Reihenfolge
⚠ Prüfungshinweis K3: Ressourcenverfügbarkeit kann die ideale Ausführungsreihenfolge durchbrechen — z.B. wenn eine Testumgebung erst später verfügbar ist. Priorisierung ist also immer ein Kompromiss zwischen strategischer Reihenfolge und operativer Verfügbarkeit.
In der Praxis
Risikobasiert: Beim Online-Banking ist der Zahlungsverkehr das höchste Risiko — also testest du Überweisungen zuerst, auch wenn die Kontoverwaltung technisch einfacher zu testen wäre.Überdeckungsbasiert: Euer Ziel ist 80 % Codepfade abgedeckt — du startest mit den Testfällen, die die meisten neuen Pfade aufmachen, statt mit denen, die sich überlappen.
Anforderungsbasiert: Der Product Owner hat Anforderung R-001 „Login" als Priorität 1 markiert — also testest du Login-Szenarien als erstes, egal wie simpel sie technisch sind.
⑥ Testpyramide & Testquadranten — CTFL Kap. 5.1 · FL-5.1.6 (K1) / FL-5.1.7 (K2)
Testpyramide — Granularität & Automatisierungsgrad
Je höher die Ebene, desto geringer die Granularität, geringer die Isolation und größer die Ausführungszeit. Shift-Left: möglichst viele Tests in die untere Ebene verlagern — dort ist das Verhältnis Testaufwand : Fehlerfindung am besten.
In der Praxis
Unten (Unit): 300 JUnit-Tests für die Zinsenberechnungslogik — laufen in 8 Sekunden, finden sofort ob eine Formel falsch ist.Mitte (Integration): 40 API-Tests die prüfen ob Konto + Zahlung + Benachrichtigung korrekt zusammenspielen — laufen in 2 Minuten.
Oben (E2E): 5 Selenium-Tests die einen kompletten Überweisungsflow im Browser durchklicken — laufen 20 Minuten, sind fragil, brechen bei jedem UI-Änderung. → Deshalb: so wenige wie möglich oben, so viele wie möglich unten.
Testquadranten (Brian Marick) — Agile Testklassifikation
Team unterstützen
Produkt kritisch betrachten
Geschäftlich orientiert
Q2
Funktionale Tests
Beispiele · User-Story-Tests · Prototypen · API-Tests · Simulationen. Manuell & automatisiert.
Q3
Explorative Tests
Gebrauchstauglichkeit · UAT. Benutzerorientiert, manuell, nicht automatisierbar.
Technologieorientiert
Q1
Komponenten- & CIT-Tests
Automatisiert, in CI integriert. Technische Qualität.
Q4
Nicht-funktionale Tests
Smoke-Tests · Performance · Sicherheit. Häufig automatisiert.
Zusammenhang: Testquadranten zeigen dass Teststufen und Testarten orthogonal sind — dieselbe Idee wie in Kap. 2.2.2. Q1 und Q4 sind technologieorientiert (mehr automatisierbar), Q2 und Q3 sind geschäftlich orientiert (mehr manuell). Kein Quadrant ist besser als die anderen — alle sind nötig.
In der Praxis
Q1 (technisch, Team unterstützen): Entwickler schreibt JUnit-Test für jede neue Methode — läuft bei jedem Commit automatisch in Jenkins.Q2 (geschäftlich, Team unterstützen): Tester und PO schreiben gemeinsam Akzeptanztests in Gherkin: „Given ein eingeloggter Nutzer, When er auf Überweisung klickt, Then…"
Q3 (geschäftlich, Produkt kritisch betrachten): Usability-Tester lässt echte Nutzer das neue Banking-Dashboard ausprobieren — nicht automatisierbar, sehr wertvoll.
Q4 (technisch, Produkt kritisch betrachten): Lasttest mit JMeter: 10.000 parallele Logins — hält das System stand?
⑦ Risikomanagement — CTFL Kap. 5.2 · FL-5.2.1–5.2.4 (K1/K2)
Risikodefinition
Risikostufe = Wahrscheinlichkeit × Schadensausmaß
Ein Risiko ist ein potenzielles Ereignis / Gefahr / Bedrohung, dessen Eintreten eine nachteilige Auswirkung verursacht.
Zwei Attribute: Eintrittswahrscheinlichkeit (Wert zwischen 0–1) · Schadensausmaß (Folgen des Eintretens)
Risikostufe = Eintrittswahrscheinlichkeit × Schadensausmaß — je höher, desto wichtiger die Behandlung.
Niedriges Risiko: Fußzeile mit Firmenadresse — Wahrscheinlichkeit falsch: gering, Schadensausmaß: minimal → niedrige Risikostufe, minimaler Testaufwand.
Zwei Attribute: Eintrittswahrscheinlichkeit (Wert zwischen 0–1) · Schadensausmaß (Folgen des Eintretens)
Risikostufe = Eintrittswahrscheinlichkeit × Schadensausmaß — je höher, desto wichtiger die Behandlung.
ISO 31000
Quantitativ oder qualitativ bewertbar
In der Praxis
Hohes Risiko: Zahlungsmodul — Wahrscheinlichkeit eines Fehlers: mittel, Schadensausmaß: kritisch (Kundengeld verloren, Reputationsschaden, Bußgelder) → hohe Risikostufe, intensiv testen.Niedriges Risiko: Fußzeile mit Firmenadresse — Wahrscheinlichkeit falsch: gering, Schadensausmaß: minimal → niedrige Risikostufe, minimaler Testaufwand.
Risikomatrix — Eintrittswahrscheinlichkeit × Schadensausmaß
Gering
Mittel
Hoch
Hoch
Mittel
Hoch
Kritisch
Mittel
Niedrig
Mittel
Hoch
Gering
Minimal
Niedrig
Mittel
Zeilen = Eintrittswahrscheinlichkeit · Spalten = Schadensausmaß
Projektrisiken vs. Produktrisiken — FL-5.2.2 (K2)
| Aspekt | Projektrisiken | Produktrisiken |
|---|---|---|
| Bezug | Management & Steuerung des Projekts | Qualitätsmerkmale des Produkts (ISO 25010) |
| Organisatorisch | Verzögerungen · ungenaue Schätzungen · Kostenkürzungen | — |
| Personell | Unzureichende Fähigkeiten · Konflikte · Personalmangel | — |
| Technisch | Scope Creep · unzureichende Werkzeuge | Fehlende Funktionalität · falsche Berechnungen · Sicherheitslücken |
| Lieferant | Lieferausfall · Konkurs des Unterstützers | — |
| Auswirkung | Zeitplan · Budget · Projektumfang | Unzufriedenheit · Einnahmenverlust · Schaden für Dritte · Körperliche Schäden |
In der Praxis
Projektrisiko: Euer Datenbankexperte fällt zwei Wochen vor dem Go-Live aus — das ist ein personelles Projektrisiko. Auswirkung: Testzeitplan verschiebt sich, Budget steigt. Das hat nichts mit der Qualität des Produkts zu tun.Produktrisiko: Das Passwort-Reset-Formular sendet E-Mails auch an falsche Adressen — das ist ein Produktrisiko. Auswirkung: Datenschutzverstoß, Nutzerfrust, mögliche Bußgelder.
Produktrisikosteuerung — FL-5.2.4 (K2)
Reaktionsmöglichkeiten nach der Analyse
Risikominderung durch Testen
Risikoakzeptanz
Risikoübertragung (Versicherung)
Notfallplan
Geeignete Tester & Unabhängigkeit
Reviews & statische Analysen
Geeignete Testverfahren & Überdeckungsgrade
Dynamische Tests inkl. Regressionstests
In der Praxis
Risikominderung durch Testen: Zahlungsmodul bekommt extra Testfälle, Penetrationstest und Code-Review — weil das Risiko zu hoch ist um es zu akzeptieren.Risikoakzeptanz: Die Dark-Mode-Darstellung in einem alten Browser hat einen leichten Farbfehler — Wahrscheinlichkeit niedrig, Schaden minimal → bewusste Entscheidung: nicht fixen, kein Test.
Risikoübertragung: Gegen Datenverlust durch externe Angriffe wird eine Cyberversicherung abgeschlossen.
⑧ Testüberwachung, Teststeuerung & Metriken — CTFL Kap. 5.3 · FL-5.3.1–5.3.3 (K1/K2)
Testüberwachung & Teststeuerung
Überwachen → Informationen → Steuern
Testüberwachung: Sammeln von Informationen über das Testen → Testfortschritt bewerten → prüfen ob Endekriterien erfüllt sind.
Teststeuerung: Nutzt Überwachungsinformationen → gibt Steuerungsmaßnahmen vor:
Neupriorisierung von Tests · Neubewertung von Eingangskriterien · Anpassung des Testzeitplans · Hinzufügen neuer Ressourcen.
Testabschluss: Konsolidierung von Erfahrungen & Testmitteln an Projektmeilensteinen.
Teststeuerung: Nutzt Überwachungsinformationen → gibt Steuerungsmaßnahmen vor:
Neupriorisierung von Tests · Neubewertung von Eingangskriterien · Anpassung des Testzeitplans · Hinzufügen neuer Ressourcen.
Testabschluss: Konsolidierung von Erfahrungen & Testmitteln an Projektmeilensteinen.
Kontinuierlicher KreislaufBasis: Testmetriken
In der Praxis
Es ist Woche 3 des Systemtests. Du überwachst: Von 200 Testfällen sind 140 ausgeführt (70 %), 12 kritische Bugs offen. Der Plan sagt: bis Ende Woche 3 sollten 90 % ausgeführt sein und max. 5 kritische Bugs offen. → Du steuerst: Du priorisierst die verbliebenen 60 Testfälle neu, eskalierst die 12 kritischen Bugs an den Entwickler und passt den Testzeitplan an.Testmetriken — FL-5.3.1 (K1)
Projektfortschritt
Abgeschlossene Aufgaben
Ressourcenverbrauch
Testaufwand
Testfortschritt
Testfallrealisierung (% fertig)
Ausgeführte / nicht ausgeführte Testfälle
Bestandene / fehlgeschlagene Testfälle
Produktqualität
Verfügbarkeit
Reaktionszeit
MTTF (Mean Time to Failure)
Fehlerzustände
Anzahl / Prioritäten gefunden/behoben
Fehlerdichte
DDP (Defect Detection Percentage)
Risiken & Überdeckung
Verbleibende Risikostufe
Anforderungsüberdeckung
Codeüberdeckung
Kosten
Kosten für das Testen
Org. Kosten für Qualität
Testfortschrittsbericht — während Testen
Test Progress Report
ISO/IEC/IEEE 29119-3 — auch: Teststatusbericht
Unterstützt laufende Steuerung · Liefert genügend Informationen für Änderungen am Zeitplan, Ressourcen oder Testkonzept.
Typische Inhalte:
Typische Inhalte:
Testzeitraum
Testfortschritt (vor/hinter Zeitplan)
Hindernisse & Umgehungsmöglichkeiten
Testmetriken
Neue/veränderte Risiken
Geplante Tests für nächsten Zeitraum
Testabschlussbericht — nach Teststufe/Projekt
Test Completion Report
ISO/IEC/IEEE 29119-3
Wird erstellt wenn Projekt, Teststufe oder Testart abgeschlossen ist (idealerweise nach Erfüllung der Endekriterien).
Typische Inhalte:
Typische Inhalte:
Zusammenfassung durchgeführter Tests
Bewertung gegen Testkonzept (Ziele & Endekriterien)
Abweichungen vom Testkonzept
Restrisiken & unbehobene Fehlerzustände
Metriken auf Basis Fortschrittsberichte
Lessons Learned
⑨ Konfigurationsmanagement — CTFL Kap. 5.4 · FL-5.4.1 (K2)
Was leistet KM für das Testen?
Konfigurationsmanagement als Testdisziplin
KM identifiziert, steuert und verfolgt Arbeitsergebnisse: Testkonzepte · Teststrategien · Testbedingungen · Testfälle · Testskripte · Testergebnisse · Testprotokolle · Testberichte.
KM stellt sicher:
• Alle Konfigurationselemente einschl. Testelemente werden eindeutig identifiziert, versionskontrolliert, auf Änderungen verfolgt und mit anderen Konfigurationselementen verknüpft.
• Alle identifizierten Elemente der Dokumentation und Software werden als Testmittel eindeutig referenziert.
• Bei Freigabe: alle relevanten Konfigurationselemente des Testobjekts sind bekannt → Reproduzierbarkeit von Testergebnissen.
• Rückkehr zu früheren Baselines möglich (frühere Testergebnisse reproduzieren).
In CI/CD: KM ist Teil der automatisierten DevOps-Auslieferungskette.
Oder in CI/CD: Jeder Merge in den Hauptbranch triggert automatisch die Testsuiten — das geht nur weil KM sicherstellt dass immer klar ist welcher Code zu welchen Tests gehört.
KM stellt sicher:
• Alle Konfigurationselemente einschl. Testelemente werden eindeutig identifiziert, versionskontrolliert, auf Änderungen verfolgt und mit anderen Konfigurationselementen verknüpft.
• Alle identifizierten Elemente der Dokumentation und Software werden als Testmittel eindeutig referenziert.
• Bei Freigabe: alle relevanten Konfigurationselemente des Testobjekts sind bekannt → Reproduzierbarkeit von Testergebnissen.
• Rückkehr zu früheren Baselines möglich (frühere Testergebnisse reproduzieren).
In CI/CD: KM ist Teil der automatisierten DevOps-Auslieferungskette.
VersionskontrolleBaselineReproduzierbarkeitCI/CD Integration
In der Praxis
Stell dir vor, ein Bug taucht in der Produktion auf. Dein Chef fragt: „Welchen Testfall hast du dafür gehabt, und welche Version der Anwendung war das?" — Ohne KM kannst du das nicht beantworten. Mit KM kannst du sagen: „Testfall TC-PAYMENT-012, Version 2.3.1, Testergebnis vom 10.11. — und hier ist der Log."Oder in CI/CD: Jeder Merge in den Hauptbranch triggert automatisch die Testsuiten — das geht nur weil KM sicherstellt dass immer klar ist welcher Code zu welchen Tests gehört.
⑩ Fehlermanagement & Fehlerbericht — CTFL Kap. 5.5 · FL-5.5.1 (K3 — anwenden!)
K3 — Anwenden: Du musst einen Fehlerbericht erstellen können — nicht nur beschreiben was drin steht, sondern ihn für eine gegebene Situation tatsächlich ausfüllen. Alle Pflichtfelder müssen bekannt sein.
Ziele des Fehlermanagements
Ausreichend Informationen für die Behebung liefern
Qualität des Arbeitsergebnisses verfolgen
Ideen zur Prozessverbesserung liefern
Fehlerbericht = auch bei Anomalien aus Reviews, statischen Analysen oder anderen Quellen — nicht nur dynamisches Testen. Term: Fehlerbericht = Defect Report = Bug Report
Fehlerbericht — Musterbeispiel (K3)
Fehlerbericht / Defect Report
Eindeutige KennungBUG-2025-1042
TitelLogin schlägt fehl bei Gültigen Sonderzeichen im Passwort
Datum / Autor2025-11-14 · Maria M. (Tester, QA-Team)
Testobjekt / UmgebungLogin-Service v2.3.1 · Chrome 130 / Windows 11
KontextTestfall TC-LOGIN-007 · Systemtest · Sprint 8 · Äquivalenzklassentest
Reproduktionsschritte1. Login-Seite aufrufen 2. Nutzer: test@beispiel.de 3. Passwort: P@ss#2024! eingeben 4. „Anmelden“ klicken
Erwartetes ErgebnisErfolgreicher Login, Weiterleitung zur Startseite
Tatsächliches ErgebnisFehlermeldung: „Ungültiger Nutzername oder Passwort“ — Login verweigert
Schweregrad / PrioritätKritisch (Severity: Critical) · Priorität: Hoch
StatusOffen (Open)
Logs / AnhangScreenshot_login_error.png · browser_console.log
⚠ Prüfungsfalle K3: Schweregrad (Severity = technische Auswirkung) ≠ Priorität (Priority = Dringlichkeit der Behebung aus Geschäftssicht). Ein Bug kann hohen Schweregrad aber niedrige Priorität haben (z.B. seltener Spezialfall) — oder niedrigen Schweregrad aber hohe Priorität (z.B. Tippfehler auf Startseite).
In der Praxis — Severity ≠ Priority
Hohe Severity, niedrige Priority: Ein Absturz tritt nur auf wenn jemand gleichzeitig zwei Tabs öffnet und binnen 3 Sekunden zweimal auf Speichern klickt. Technisch kritisch — aber so selten, dass der Product Owner entscheidet: „Nicht jetzt, nächstes Release."Niedrige Severity, hohe Priority: Auf der Startseite steht „Wilkommen" statt „Willkommen". Kein Datenverlust, kein Absturz — aber der CEO sieht das morgen in der Demo. Sofort fixen.
Wer entscheidet was? Severity bewertet der Tester (technisch). Priority entscheidet der Product Owner oder Projektmanager (geschäftlich).