Software-Testing: Teststrategie & Testauswahl
Dieser Skill beantwortet die Frage „Welche Tests brauche ich hier, jetzt, wofür?" —
systematisch statt aus dem Bauch. Er liefert die Entscheidungslogik; der vollständige
Katalog aller Testarten, Verfahren und Definitionen liegt in
testarten-katalog.md im selben Ordner (bei Detailfragen dort nachschlagen).
1. Ordnungsrahmen: In drei Dimensionen denken
Bevor du Tests planst oder schreibst, verorte die Aufgabe auf drei Achsen (ISTQB).
Wer nur „eine Liste von Tests" führt, vermischt die Achsen und plant lückenhaft:
| Achse |
Frage |
Ausprägungen |
| Teststufe |
Auf welcher Ebene? |
Unit → Integration → System → Abnahme |
| Testart |
Welche Eigenschaft? |
funktional / nicht-funktional / strukturbezogen / änderungsbezogen |
| Testverfahren |
Wie entstehen die Testfälle? |
Black-Box / White-Box / erfahrungsbasiert |
Quer dazu: statisch (Reviews, statische Analyse — ohne Ausführung, früheste und
billigste Fehlerfindung) vs. dynamisch (Code wird ausgeführt).
2. Situations-Router: Was liegt vor?
Wähle den Einstieg nach der konkreten Situation:
| Situation |
Vorgehen |
| Neues Feature bauen |
Abnahmekriterien VOR dem Code klären (ATDD/BDD-Denkweise). Unit-Tests parallel zur Implementierung (Äquivalenzklassen + Grenzwerte). Integrationstest für neue Schnittstellen. Einen E2E-Happy-Path, nicht mehr. |
| Bug fixen |
Erst Bug reproduzierender Test (rot), dann Fix (grün) = Re-Test. Danach Regression der Umgebung. Diagnose selbst → bugfix-protocol. |
| Refactoring |
KEINE neuen Feature-Tests — bestehende Suite ist das Sicherheitsnetz. Vorher prüfen, ob die Suite das Verhalten wirklich abdeckt (ggf. Charakterisierungstests nachziehen). Coverage/Mutation als Lückenindikator. |
| Legacy-Code ohne Tests |
Nicht mit Unit-Tests jeder Funktion beginnen. Erst Charakterisierungstests auf System-/API-Ebene um das Ist-Verhalten legen, dann beim Anfassen einzelner Teile Unit-Tests nachziehen. |
| API / Microservices |
API-Tests auf Service-Ebene als Schwerpunkt (mittlere Pyramidenebene). Bei getrennten Teams/Deployments: Contract Testing (z. B. Pact) statt gemeinsamer Staging-Integrationstests. |
| Release vorbereiten |
Reihenfolge: Smoke (Build stabil?) → volle Regression → nicht-funktionale Tests (Last, Security) → UAT/Abnahme → Smoke auf dem Release-Kandidaten. |
| Performance-Sorge |
Erst messbares Ziel definieren (z. B. „P95 < 300 ms bei 1.000 Nutzern"), sonst ist kein Test auswertbar. Lasttest = Normallast, Stresstest = Bruchpunkt + Erholung. Produktionsnahe Umgebung Pflicht. |
| Test-Pipeline aufsetzen |
CI/CD-Gates aus Abschnitt 4 implementieren; mit Unit + Lint bei jedem Commit beginnen, dann stufenweise ausbauen. |
| Teststrategie/Testkonzept schreiben |
Struktur entlang der 3 Dimensionen + Phasen-Mapping (Abschnitt 4) + risikobasierte Priorisierung (Abschnitt 6, Punkt 10). |
3. Teststufen: Prüfobjekt, Ziel, Zeitpunkt
| Stufe |
Prüft |
Wann |
Faustregel |
| Unit/Komponente |
Einzelne Funktion/Klasse isoliert (Mocks/Stubs) |
Während der Implementierung, jeder Commit |
Breite Basis der Pyramide; schnell (< Sekunden), deterministisch |
| Integration |
Zusammenspiel, Schnittstellen, DB-Anbindung |
Nach Unit-Tests, bei jedem Merge |
Inkrementell integrieren (Top-Down/Bottom-Up), nie Big Bang bei großen Systemen |
| System |
Gesamtsystem gegen technische Anforderungen |
Sobald integrierter Build existiert |
Funktional UND nicht-funktional; unabhängige Tester wertvoll |
| Abnahme |
Geschäftserwartung, realer Einsatz |
Letzte Stufe vor Go-Live |
UAT durch Fachbereich; betrieblich (Backup/Deploy/Monitoring) nicht vergessen; ggf. Alpha/Beta |
Testpyramide als Mengenverhältnis: viele Unit-, gezielte Integrations-/API-, wenige
E2E-Tests (Daumenregel ~70/20/10 als Startpunkt — nach tatsächlicher Fehlerherkunft
justieren). Umgedrehte Pyramide (viele UI-Tests) = langsam + flaky → vermeiden.
4. Phasen-Mapping: Wann prüft man was?
CI/CD-Gates (modernes Standard-Mapping)
| Pipeline-Stufe |
Gate |
| Jeder Commit |
Unit-Tests, Linter, statische Analyse (Sekunden–Minuten) |
| Pull Request |
Code-Review, SAST/SCA, gezielte Komponententests |
| Merge |
Integrations-/API-/Contract-Tests, Smoke auf Testumgebung |
| Nightly / Pre-Release |
Volle Regression, E2E, Performance-/Lasttests, DAST |
| Release-Kandidat |
Smoke auf Staging, UAT, Abnahme |
| Produktion (Shift-Right) |
Monitoring/Observability, Canary/Blue-Green, Feature Flags, ggf. Chaos-Experimente |
Zeitbudgets & Blockier-Regeln (Faustwerte aus der Praxis):
- Commit-zu-Feedback < 10 Minuten für den schnellen Pfad (Lint + Unit + kritische
Integrationstests); Gesamtpipeline bis Staging < 30–45 Minuten; volle Regression
nightly oder vor Release. Ein Regelkreis, der langsamer taktet, wird umgangen.
- Blockierend vs. meldend: Unit-, Integrations- und Smoke-Gates blockieren IMMER
(bei Rot kein Merge/Deploy). Nightly-Stufen (Regression, Last, DAST) melden per
Ticket/Fix, blockieren aber nicht jeden Commit. Nach dem Prod-Deploy: Smoke +
Monitoring — bei Rot Rollback + Incident.
- Übergabepunkt: Der Commit (git push) trennt Inner Loop (lokal: TDD, Unit,
schnelle Iteration) vom Outer Loop (geteilte Pipeline mit Gates). Was sich in den
Inner Loop verlagern lässt, wird dort am billigsten gefangen (Shift-Left).
Klassisch (V-Modell): Tests beim Spezifizieren entwerfen
Anforderungen↔Abnahmetest · Systemdesign↔Systemtest · Architektur↔Integrationstest ·
Code↔Unit-Test. Kernidee: Die Tests einer Stufe werden beim Erstellen der zugehörigen
Spezifikation entworfen — nicht erst am Ende. Reviews der Anforderungen/Designs
(statisches Testen) sind die früheste Fehlerfindung überhaupt.
Agile Testing Quadrants (Planungsraster für Sprints)
Q1 Unit/TDD + Q2 Story-Tests/BDD laufen kontinuierlich und verhindern Fehler;
Q3 explorativ/Usability/UAT + Q4 Performance/Security bewerten das Produkt, sobald
genug Produkt existiert. Details im Katalog.
5. Testentwurfsverfahren wählen
| Wenn die Testbasis … |
… dann Verfahren |
| Eingabebereiche/Wertemengen hat |
Äquivalenzklassen (ein Repräsentant je Klasse) + Grenzwertanalyse (an und direkt jenseits jeder Grenze: bei 5–50 teste 4, 5, 50, 51) — die Grundausstattung für fast jeden Unit-Test |
| komplexe Geschäftsregeln/Bedingungskombinationen hat |
Entscheidungstabellentest |
| Zustände und Übergänge hat (Workflow, Session, Gerät) |
Zustandsübergangstest (auch verbotene Übergänge testen) |
| Nutzerabläufe beschreibt |
Use-Case-/Szenariotest inkl. Fehler- und Ausnahmepfaden |
| Code ist und Abdeckung gemessen werden soll |
Anweisungs-/Zweigüberdeckung — als Lückenindikator, nicht als Ziel (100 % Coverage ≠ korrekt) |
| unklar/lückenhaft ist oder Zeit knapp |
Exploratives Testen (zeitboxte Sessions mit Charter) + Error Guessing (Null, Leerstring, Sonderzeichen, Zeitzonen, Race Conditions) |
Systematische Verfahren zuerst, erfahrungsbasierte bewusst ergänzend — sie finden,
was Skripte übersehen.
6. Best Practices (Checkliste beim Planen/Reviewen von Tests)
- Shift-Left: Reviews + statische Analyse ab der Anforderungsphase — je später ein
Fehler gefunden wird, desto teurer (verbreitete Faustregel nach Boehm; Richtung
unstrittig, exakte Faktoren umstritten).
- Testpyramide respektieren — E2E-Tests sparsam, Unit-Basis breit.
- Automatisieren, was wiederholt wird (Smoke, Regression, API, Unit) und in
CI/CD-Gates verankern; manuelle Kapazität für explorativ + Usability reservieren.
- Testfälle systematisch entwerfen (Abschnitt 5), nicht ad hoc.
- Nicht-funktionale Anforderungen messbar machen — ohne Zahlenziel kein
auswertbarer Performanz-/Lasttest.
- Re-Test ≠ Regression: erst Fix bestätigen, dann Seiteneffekte. Reihenfolge
Smoke → Sanity/Re-Test → Regression.
- Flaky Tests sofort behandeln — quarantänisieren, Ursache fixen oder löschen;
instabile Suiten zerstören das Vertrauen in die Pipeline.
- Testdaten/-umgebungen managen: reproduzierbar (Container/IaC), produktionsnah,
anonymisierte oder synthetische Daten.
- Testqualität selbst messen: Coverage als Lückenindikator; Mutation Testing
dort, wo Coverage-Zahlen täuschen könnten.
- Risikobasiert priorisieren: Testtiefe nach Ausfallwirkung ×
Fehlerwahrscheinlichkeit — nicht gleichverteilt.
- Qualität ist Teamaufgabe (Whole-Team-Approach): Tester früh in Anforderungen
einbinden; BDD/ATDD als gemeinsames Vehikel mit dem Fachbereich.
- Shift-Right nicht vergessen: Monitoring, Canary, Feature Flags; Chaos
Engineering erst bei reifer Observability.
7. Moderne Verfahren — wann zusätzlich einsetzen
| Verfahren |
Einsetzen wenn … |
| Contract Testing (Pact) |
Microservices mit getrennten Deployments/Teams |
| Mutation Testing (Stryker, PIT, mutmut) |
Güte einer bestehenden Testsuite bewertet werden soll |
| Property-Based Testing (Hypothesis, fast-check) |
Invarianten existieren („sortiert ist idempotent") und Randfälle gefürchtet sind |
| Fuzzing |
Parser, Deserialisierung, sicherheitskritische Eingaben |
| Chaos Engineering |
Verteilte Systeme + reife Observability + saubere Rollbacks |
Nachbar-Skills (nicht duplizieren)
superpowers:test-driven-development — die konkrete Red-Green-Refactor-Schleife
beim Schreiben von Code.bugfix-protocol — 6-Phasen-Diagnose eines konkreten Bugs.bugsweep — systematischer Bug-Suchlauf über eine Codebasis.dev-cycle — 8-Phasen-Gesamtzyklus (ab dessen v1.2.0: Tests werden in den
Phasen 1/3/5 entworfen, in Phase 6 geschrieben und in Phase 7 ausgeführt; dieser
Skill füllt aus, WELCHE Tests wo laufen sollen).
Referenz
Vollständiger Katalog (alle Teststufen, Testarten inkl. nicht-funktionaler Detailtabelle,
alle Entwurfsverfahren, Agile Quadrants, statisch/dynamisch, V-Modell, Quellen):
→ testarten-katalog.md (im selben Ordner)
Visuelle Gesamtkarte — Phasen, Regelkreise, Rollen und Test-Gates als „Schaltplan
der Softwareentwicklung" (Blatt BL-5 = Test-Einhängung, BL-2 = Regelkreis-Takte):
→ ../dev-cycle/SCHALTPLAN-SOFTWAREENTWICKLUNG.html (im Browser öffnen)
Änderungsprotokoll
1.0.1 (2026-08-22)
- Zeitbudgets & Blockier-Regeln für CI/CD-Gates ergänzt (< 10 min Fast Path,
< 30–45 min Pipeline; blockierend vs. meldend; Rollback nach Prod-Rot) sowie
der Commit als Übergabepunkt Inner/Outer Loop
- Verweis auf die Schaltplan-Beilage im dev-cycle-Skill; dev-cycle-Abgrenzung an
dessen v1.2.0 (Shift-Left: entwerfen 1/3/5, schreiben 6, ausführen 7) angepasst
1.0.0 (2026-08-22)
- Erstversion aus Online-Recherche (ISTQB-Systematik, Testpyramide, Agile Testing
Quadrants, CI/CD-Gates, moderne Verfahren)
1---2name: software-testing3description: Teststrategie-Berater für Softwareprojekte — wählt die richtigen Teststufen (Unit/Integration/System/Abnahme), Testarten (funktional, nicht-funktional, änderungsbezogen) und Testentwurfsverfahren (Äquivalenzklassen, Grenzwerte, Entscheidungstabellen, explorativ) für die jeweilige Situation und SDLC-/CI-Phase, inkl. Testpyramide, CI/CD-Gates, Shift-Left und Best Practices. Nutze diesen Skill IMMER, wenn Tests geschrieben, geplant, priorisiert oder bewertet werden sollen — bei "schreibe Tests", "Teststrategie", "Testplan", "Testkonzept", "was/wie soll ich testen", "welche Tests fehlen", "Testabdeckung verbessern", "QA aufsetzen", Fragen zu Regression/Smoke/Sanity/Last/Stress/Security-Tests oder beim Einrichten einer Test-Pipeline — auch wenn "Test" nur beiläufig fällt. Abgrenzung — für die TDD-Schleife selbst superpowers:test-driven-development, für Bug-Diagnose bugfix-protocol, für systematische Bug-Suche bugsweep nutzen.4---56<img src="banner.png" width="100%" alt="software-testing banner">78# Software-Testing: Teststrategie & Testauswahl910Dieser Skill beantwortet die Frage **„Welche Tests brauche ich hier, jetzt, wofür?"** —11systematisch statt aus dem Bauch. Er liefert die Entscheidungslogik; der vollständige12Katalog aller Testarten, Verfahren und Definitionen liegt in13`testarten-katalog.md` im selben Ordner (bei Detailfragen dort nachschlagen).1415---1617## 1. Ordnungsrahmen: In drei Dimensionen denken1819Bevor du Tests planst oder schreibst, verorte die Aufgabe auf drei Achsen (ISTQB).20Wer nur „eine Liste von Tests" führt, vermischt die Achsen und plant lückenhaft:2122| Achse | Frage | Ausprägungen |23|---|---|---|24| **Teststufe** | Auf welcher Ebene? | Unit → Integration → System → Abnahme |25| **Testart** | Welche Eigenschaft? | funktional / nicht-funktional / strukturbezogen / änderungsbezogen |26| **Testverfahren** | Wie entstehen die Testfälle? | Black-Box / White-Box / erfahrungsbasiert |2728Quer dazu: **statisch** (Reviews, statische Analyse — ohne Ausführung, früheste und29billigste Fehlerfindung) vs. **dynamisch** (Code wird ausgeführt).3031---3233## 2. Situations-Router: Was liegt vor?3435Wähle den Einstieg nach der konkreten Situation:3637| Situation | Vorgehen |38|---|---|39| **Neues Feature bauen** | Abnahmekriterien VOR dem Code klären (ATDD/BDD-Denkweise). Unit-Tests parallel zur Implementierung (Äquivalenzklassen + Grenzwerte). Integrationstest für neue Schnittstellen. Einen E2E-Happy-Path, nicht mehr. |40| **Bug fixen** | Erst Bug reproduzierender Test (rot), dann Fix (grün) = **Re-Test**. Danach **Regression** der Umgebung. Diagnose selbst → `bugfix-protocol`. |41| **Refactoring** | KEINE neuen Feature-Tests — bestehende Suite ist das Sicherheitsnetz. Vorher prüfen, ob die Suite das Verhalten wirklich abdeckt (ggf. Charakterisierungstests nachziehen). Coverage/Mutation als Lückenindikator. |42| **Legacy-Code ohne Tests** | Nicht mit Unit-Tests jeder Funktion beginnen. Erst Charakterisierungstests auf System-/API-Ebene um das Ist-Verhalten legen, dann beim Anfassen einzelner Teile Unit-Tests nachziehen. |43| **API / Microservices** | API-Tests auf Service-Ebene als Schwerpunkt (mittlere Pyramidenebene). Bei getrennten Teams/Deployments: **Contract Testing** (z. B. Pact) statt gemeinsamer Staging-Integrationstests. |44| **Release vorbereiten** | Reihenfolge: Smoke (Build stabil?) → volle Regression → nicht-funktionale Tests (Last, Security) → UAT/Abnahme → Smoke auf dem Release-Kandidaten. |45| **Performance-Sorge** | Erst messbares Ziel definieren (z. B. „P95 < 300 ms bei 1.000 Nutzern"), sonst ist kein Test auswertbar. Lasttest = Normallast, Stresstest = Bruchpunkt + Erholung. Produktionsnahe Umgebung Pflicht. |46| **Test-Pipeline aufsetzen** | CI/CD-Gates aus Abschnitt 4 implementieren; mit Unit + Lint bei jedem Commit beginnen, dann stufenweise ausbauen. |47| **Teststrategie/Testkonzept schreiben** | Struktur entlang der 3 Dimensionen + Phasen-Mapping (Abschnitt 4) + risikobasierte Priorisierung (Abschnitt 6, Punkt 10). |4849---5051## 3. Teststufen: Prüfobjekt, Ziel, Zeitpunkt5253| Stufe | Prüft | Wann | Faustregel |54|---|---|---|---|55| **Unit/Komponente** | Einzelne Funktion/Klasse isoliert (Mocks/Stubs) | Während der Implementierung, jeder Commit | Breite Basis der Pyramide; schnell (< Sekunden), deterministisch |56| **Integration** | Zusammenspiel, Schnittstellen, DB-Anbindung | Nach Unit-Tests, bei jedem Merge | Inkrementell integrieren (Top-Down/Bottom-Up), nie Big Bang bei großen Systemen |57| **System** | Gesamtsystem gegen technische Anforderungen | Sobald integrierter Build existiert | Funktional UND nicht-funktional; unabhängige Tester wertvoll |58| **Abnahme** | Geschäftserwartung, realer Einsatz | Letzte Stufe vor Go-Live | UAT durch Fachbereich; betrieblich (Backup/Deploy/Monitoring) nicht vergessen; ggf. Alpha/Beta |5960**Testpyramide** als Mengenverhältnis: viele Unit-, gezielte Integrations-/API-, wenige61E2E-Tests (Daumenregel ~70/20/10 als Startpunkt — nach tatsächlicher Fehlerherkunft62justieren). Umgedrehte Pyramide (viele UI-Tests) = langsam + flaky → vermeiden.6364---6566## 4. Phasen-Mapping: Wann prüft man was?6768### CI/CD-Gates (modernes Standard-Mapping)6970| Pipeline-Stufe | Gate |71|---|---|72| Jeder Commit | Unit-Tests, Linter, statische Analyse (Sekunden–Minuten) |73| Pull Request | Code-Review, SAST/SCA, gezielte Komponententests |74| Merge | Integrations-/API-/Contract-Tests, Smoke auf Testumgebung |75| Nightly / Pre-Release | Volle Regression, E2E, Performance-/Lasttests, DAST |76| Release-Kandidat | Smoke auf Staging, UAT, Abnahme |77| Produktion (Shift-Right) | Monitoring/Observability, Canary/Blue-Green, Feature Flags, ggf. Chaos-Experimente |7879**Zeitbudgets & Blockier-Regeln (Faustwerte aus der Praxis):**8081- **Commit-zu-Feedback < 10 Minuten** für den schnellen Pfad (Lint + Unit + kritische82 Integrationstests); Gesamtpipeline bis Staging **< 30–45 Minuten**; volle Regression83 nightly oder vor Release. Ein Regelkreis, der langsamer taktet, wird umgangen.84- **Blockierend vs. meldend:** Unit-, Integrations- und Smoke-Gates blockieren IMMER85 (bei Rot kein Merge/Deploy). Nightly-Stufen (Regression, Last, DAST) melden per86 Ticket/Fix, blockieren aber nicht jeden Commit. Nach dem Prod-Deploy: Smoke +87 Monitoring — bei Rot Rollback + Incident.88- **Übergabepunkt:** Der Commit (git push) trennt Inner Loop (lokal: TDD, Unit,89 schnelle Iteration) vom Outer Loop (geteilte Pipeline mit Gates). Was sich in den90 Inner Loop verlagern lässt, wird dort am billigsten gefangen (Shift-Left).9192### Klassisch (V-Modell): Tests beim Spezifizieren entwerfen9394Anforderungen↔Abnahmetest · Systemdesign↔Systemtest · Architektur↔Integrationstest ·95Code↔Unit-Test. Kernidee: Die Tests einer Stufe werden **beim Erstellen der zugehörigen96Spezifikation** entworfen — nicht erst am Ende. Reviews der Anforderungen/Designs97(statisches Testen) sind die früheste Fehlerfindung überhaupt.9899### Agile Testing Quadrants (Planungsraster für Sprints)100101Q1 Unit/TDD + Q2 Story-Tests/BDD laufen kontinuierlich und **verhindern** Fehler;102Q3 explorativ/Usability/UAT + Q4 Performance/Security **bewerten** das Produkt, sobald103genug Produkt existiert. Details im Katalog.104105---106107## 5. Testentwurfsverfahren wählen108109| Wenn die Testbasis … | … dann Verfahren |110|---|---|111| Eingabebereiche/Wertemengen hat | **Äquivalenzklassen** (ein Repräsentant je Klasse) + **Grenzwertanalyse** (an und direkt jenseits jeder Grenze: bei 5–50 teste 4, 5, 50, 51) — die Grundausstattung für fast jeden Unit-Test |112| komplexe Geschäftsregeln/Bedingungskombinationen hat | **Entscheidungstabellentest** |113| Zustände und Übergänge hat (Workflow, Session, Gerät) | **Zustandsübergangstest** (auch verbotene Übergänge testen) |114| Nutzerabläufe beschreibt | **Use-Case-/Szenariotest** inkl. Fehler- und Ausnahmepfaden |115| Code ist und Abdeckung gemessen werden soll | **Anweisungs-/Zweigüberdeckung** — als Lückenindikator, nicht als Ziel (100 % Coverage ≠ korrekt) |116| unklar/lückenhaft ist oder Zeit knapp | **Exploratives Testen** (zeitboxte Sessions mit Charter) + **Error Guessing** (Null, Leerstring, Sonderzeichen, Zeitzonen, Race Conditions) |117118Systematische Verfahren zuerst, erfahrungsbasierte bewusst **ergänzend** — sie finden,119was Skripte übersehen.120121---122123## 6. Best Practices (Checkliste beim Planen/Reviewen von Tests)1241251. **Shift-Left:** Reviews + statische Analyse ab der Anforderungsphase — je später ein126 Fehler gefunden wird, desto teurer (verbreitete Faustregel nach Boehm; Richtung127 unstrittig, exakte Faktoren umstritten).1282. **Testpyramide respektieren** — E2E-Tests sparsam, Unit-Basis breit.1293. **Automatisieren, was wiederholt wird** (Smoke, Regression, API, Unit) und in130 CI/CD-Gates verankern; manuelle Kapazität für explorativ + Usability reservieren.1314. **Testfälle systematisch entwerfen** (Abschnitt 5), nicht ad hoc.1325. **Nicht-funktionale Anforderungen messbar machen** — ohne Zahlenziel kein133 auswertbarer Performanz-/Lasttest.1346. **Re-Test ≠ Regression:** erst Fix bestätigen, dann Seiteneffekte. Reihenfolge135 Smoke → Sanity/Re-Test → Regression.1367. **Flaky Tests sofort behandeln** — quarantänisieren, Ursache fixen oder löschen;137 instabile Suiten zerstören das Vertrauen in die Pipeline.1388. **Testdaten/-umgebungen managen:** reproduzierbar (Container/IaC), produktionsnah,139 anonymisierte oder synthetische Daten.1409. **Testqualität selbst messen:** Coverage als Lückenindikator; **Mutation Testing**141 dort, wo Coverage-Zahlen täuschen könnten.14210. **Risikobasiert priorisieren:** Testtiefe nach Ausfallwirkung ×143 Fehlerwahrscheinlichkeit — nicht gleichverteilt.14411. **Qualität ist Teamaufgabe** (Whole-Team-Approach): Tester früh in Anforderungen145 einbinden; BDD/ATDD als gemeinsames Vehikel mit dem Fachbereich.14612. **Shift-Right nicht vergessen:** Monitoring, Canary, Feature Flags; Chaos147 Engineering erst bei reifer Observability.148149---150151## 7. Moderne Verfahren — wann zusätzlich einsetzen152153| Verfahren | Einsetzen wenn … |154|---|---|155| **Contract Testing** (Pact) | Microservices mit getrennten Deployments/Teams |156| **Mutation Testing** (Stryker, PIT, mutmut) | Güte einer bestehenden Testsuite bewertet werden soll |157| **Property-Based Testing** (Hypothesis, fast-check) | Invarianten existieren („sortiert ist idempotent") und Randfälle gefürchtet sind |158| **Fuzzing** | Parser, Deserialisierung, sicherheitskritische Eingaben |159| **Chaos Engineering** | Verteilte Systeme + reife Observability + saubere Rollbacks |160161---162163## Nachbar-Skills (nicht duplizieren)164165- **`superpowers:test-driven-development`** — die konkrete Red-Green-Refactor-Schleife166 beim Schreiben von Code.167- **`bugfix-protocol`** — 6-Phasen-Diagnose eines konkreten Bugs.168- **`bugsweep`** — systematischer Bug-Suchlauf über eine Codebasis.169- **`dev-cycle`** — 8-Phasen-Gesamtzyklus (ab dessen v1.2.0: Tests werden in den170 Phasen 1/3/5 entworfen, in Phase 6 geschrieben und in Phase 7 ausgeführt; dieser171 Skill füllt aus, WELCHE Tests wo laufen sollen).172173## Referenz174175Vollständiger Katalog (alle Teststufen, Testarten inkl. nicht-funktionaler Detailtabelle,176alle Entwurfsverfahren, Agile Quadrants, statisch/dynamisch, V-Modell, Quellen):177→ `testarten-katalog.md` (im selben Ordner)178179Visuelle Gesamtkarte — Phasen, Regelkreise, Rollen und Test-Gates als „Schaltplan180der Softwareentwicklung" (Blatt BL-5 = Test-Einhängung, BL-2 = Regelkreis-Takte):181→ `../dev-cycle/SCHALTPLAN-SOFTWAREENTWICKLUNG.html` (im Browser öffnen)182183---184185## Änderungsprotokoll186187### 1.0.1 (2026-08-22)188- Zeitbudgets & Blockier-Regeln für CI/CD-Gates ergänzt (< 10 min Fast Path,189 < 30–45 min Pipeline; blockierend vs. meldend; Rollback nach Prod-Rot) sowie190 der Commit als Übergabepunkt Inner/Outer Loop191- Verweis auf die Schaltplan-Beilage im dev-cycle-Skill; dev-cycle-Abgrenzung an192 dessen v1.2.0 (Shift-Left: entwerfen 1/3/5, schreiben 6, ausführen 7) angepasst193194### 1.0.0 (2026-08-22)195- Erstversion aus Online-Recherche (ISTQB-Systematik, Testpyramide, Agile Testing196 Quadrants, CI/CD-Gates, moderne Verfahren)
ellmos-ai