Testplan für Feature vorschlagen

Skill: Testplan für Feature vorschlagen

Zweck

Erstellen eines Testplans, der Anforderungen und Einschränkungen systematisch auf konkrete Tests abbildet. So wird sichergestellt, dass jede Anforderung verifiziert ist und die Testimplementierung geleitet wird.

Verwendung

• Entwurfsdokument mit kritischen Einschränkungen (Critical Constraints) liegt vor
• Bereit, den Testansatz vor der Implementierung zu planen
• Notwendig zu dokumentieren, welche Tests welche Anforderungen verifizieren

Voraussetzungen

• Feature-Konzept existiert in ./docs/features/NNNN-feature-name/concept.md
• Anforderungen existieren in ./docs/features/NNNN-feature-name/requirements.md
• Entwurf existiert in ./docs/features/NNNN-feature-name/design.md (enthält Critical Constraints)

Vorgehen

1. Voraussetzungen prüfen

ls ./docs/features/NNNN-feature-name/concept.md
ls ./docs/features/NNNN-feature-name/requirements.md
ls ./docs/features/NNNN-feature-name/design.md

Falls etwas fehlt, zuerst diese Schritte ausführen.

2. Anforderungen und Einschränkungen extrahieren

requirements.md nach allen REQ--Kennungen durchsuchen. design.md nach allen CC--Critical Constraints durchsuchen.

3. Testplandatei erstellen

Datei ./docs/features/NNNN-feature-name/test-plan.md mit folgender Struktur anlegen:

# Testplan: Feature-Name

## Überblick

Kurze Beschreibung des Testansatzes.

## Testarten

- **Unit**: Testet interne Logik isoliert, Mocks erlaubt
- **Integration**: Nutzt echte externe Ressourcen (Dateisystem, Netzwerk), KEINE Mocks
- **Nicht testbar**: Kann nicht durch automatisierten Test verifiziert werden (Begründung)
- **Außerhalb des Rahmens**: Erfordert externe Authentifizierung – dokumentieren, aber nicht implementieren

## Abdeckung der Anforderungen

| Anforderungs-ID | Testart | Testname | Beschreibung |
|-----------------|---------|----------|--------------|
| REQ-1  | unit      | test_xxx  | Was verifiziert wird |
| REQ-2  | integration | test_yyy | Was verifiziert wird |
| REQ-3  | nicht-testbar | - | Warum nicht testbar |
| REQ-4  | außerhalb des Rahmens | - | Warum außerhalb des Rahmens |

## Verifikation kritischer Einschränkungen

| CC-ID | Verifikationsansatz | Testname(n) |
|-------|---------------------|-------------|
| CC-1  | Wie die Einschränkung verifiziert wird | test_xxx |

## Anforderungen an Integrationstests

Bei CLI-Programmen MÜSSEN Integrationstests:
- Das tatsächliche CLI-Binary/die tatsächlichen Befehle der Benutzer ausführen
- NICHT interne APIs direkt testen
- Das tun, was der Benutzer/Kunde tatsächlich tun wird

## Hinweise zur Testimplementierung

Spezifische Anleitungen zur Implementierung dieser Tests.

4. Jede Anforderung zuordnen

Für jede REQ-* in requirements.md:

1. Testart bestimmen:

   • Unit: Interne Logik, Algorithmen, Datentransformationen
   • Integration: Datei-I/O, Netzwerkaufrufe, CLI-Befehle, externe Prozesse
   • Nicht testbar: Nicht automatisierbar (z. B. subjektive Qualität, erfordert menschliches Urteilsvermögen, Einrichtung nicht praktikabel)
   • Außerhalb des Rahmens: Erfordert Authentifizierung gegenüber externen Systemen (Cloud-APIs, Registrierungen mit Authentifizierung)

2. Testnamen beschreibend wählen (z. B. test_parses_valid_config)

3. Kurze Beschreibung schreiben, was verifiziert wird

5. Jede kritische Einschränkung zuordnen

Für jede CC-* in design.md:

1. Beschreiben, wie die Einschränkung verifiziert wird
2. Auf den/die spezifischen Testnamen verlinken, der/die sie erzwingt
3. Hinweis, ob die Einschränkung eine Code-Review anstelle eines automatisierten Tests erfordert

6. CLI-Testansatz dokumentieren

Falls das Feature CLI-Befehle enthält:

• Integrationstests führen das tatsächliche Binary aus
• stdout/stderr zur Verifikation erfassen
• Echte Benutzer-Workflows Ende-zu-Ende testen
• Die CLI-Ebene NICHT mocken

7. Tests außerhalb des Rahmens markieren

Für Tests, die eine externe Authentifizierung erfordern:

1. Dokumentieren, WAS getestet würde
2. Erklären, warum es außerhalb des Rahmens liegt
3. Manuelle Verifikationsschritte notieren

Validierung

# Prüfen, ob Datei existiert
ls ./docs/features/NNNN-feature-name/test-plan.md

# Prüfen, ob alle Anforderungen abgedeckt sind
grep -c "REQ-" ./docs/features/NNNN-feature-name/test-plan.md
grep -c "REQ-" ./docs/features/NNNN-feature-name/requirements.md
# Die Zählungen sollten vergleichbar sein

# Prüfen, ob alle Einschränkungen abgedeckt sind
grep -c "CC-" ./docs/features/NNNN-feature-name/test-plan.md
grep -c "CC-" ./docs/features/NNNN-feature-name/design.md
# Die Zählungen sollten vergleichbar sein

Häufige Probleme

Fehlende Abdeckung: Jede REQ-* und CC-* muss im Testplan vorkommen. Die Validierungs-grep-Befehle zur Überprüfung verwenden.

Falsche Testart: Unit-Tests sollten das Dateisystem/Netzwerk nicht berühren. Integrationstests sollten keine Mocks verwenden.

Testen von Interna statt Verhalten: Bei CLI-Werkzeugen die CLI-Befehle testen, die Benutzer ausführen, nicht interne Funktionen.

Vage Beschreibungen: Testbeschreibungen sollten angeben, welches spezifische Verhalten verifiziert wird.

Nächste Schritte

Nach Erstellung des Testplans:

1. Abdeckung mit Stakeholdern überprüfen
2. Mit der Skill implementierungsplan-vorschlagen fortfahren, um die Implementierung zu planen
3. Der Implementierungsplan sollte auf test-plan.md für die Testanforderungen verweisen