f94cfb41e6
- Complexity Gate: S/M/L in Phase 1, S skips QA, L needs Martin approval - Max 3 fix cycles, then pause and ask Martin - KI self-review disclaimer in Code Review - Removed Phase 7 (Deployment) entirely - Renumbered: 7 phases instead of 9 - Updated all skills with new phase numbers
95 lines
2.6 KiB
Markdown
95 lines
2.6 KiB
Markdown
---
|
||
name: gitea-test-qa
|
||
description: Test- & QA-Agent für Gitea Issues. Erstellt und führt Tests durch, sichert Qualität ab. Teil der Gitea Issue Pipeline.
|
||
---
|
||
|
||
# Test- & QA-Agent
|
||
|
||
Rolle: Phase 4 der Gitea Issue Pipeline. Stellt sicher, dass die Implementierung korrekt und robust ist.
|
||
|
||
## Wird übersprungen bei
|
||
- **Komplexität S:** Test & QA wird übersprungen, direkt nach Review (APPROVED) → Merge
|
||
|
||
## Eingang
|
||
- Feature Branch mit APPROVED Code
|
||
- Spezifikationsdokument: `memory/gitea-specs/issue-<number>.md`
|
||
- Review-Ergebnis: `memory/gitea-specs/issue-<number>-review.md`
|
||
|
||
## Aufgaben
|
||
|
||
### Unit-Tests erstellen
|
||
- Für jede neue Funktion/Methode
|
||
- Positive und Negative Cases
|
||
- Grenzwerte testen
|
||
- Mocking für externe Abhängigkeiten
|
||
|
||
### Integrationstests erstellen
|
||
- Modulgrenzen testen
|
||
- Datenbank-Integration prüfen
|
||
- API-End-to-End innerhalb des Services
|
||
- Externe API-Mocks nutzen
|
||
|
||
### E2E-Tests durchführen
|
||
- Nutzerflows durchspielen
|
||
- Kritische Pfade abdecken
|
||
- Browser-basiert wenn UI betroffen
|
||
|
||
### Regressionstests ausführen
|
||
- Bestehende Test-Suite laufen lassen
|
||
- Sicherstellen dass nichts kaputt gegangen ist
|
||
- Bei Fehlschlägen: Root Cause dokumentieren
|
||
|
||
### Testdaten generieren
|
||
- Realistische Testdaten erzeugen
|
||
- Edge Cases in Testdaten abdecken
|
||
- Keine Produktionsdaten verwenden
|
||
- Testdaten reproduzierbar (Seeds/Fixtures)
|
||
|
||
### Fehler reproduzieren
|
||
- Gemeldete Bugs nachstellen
|
||
- Minimal reproduzierbares Example erstellen
|
||
- Umgebungsdetails dokumentieren
|
||
|
||
### Edge Cases testen
|
||
- Leere Eingaben
|
||
- Ungültige Formate
|
||
- Gleichzeitige Zugriffe
|
||
- Netzwerkfehler / Timeouts
|
||
- Datenüberläufe / Grenzwerte
|
||
|
||
### API-Tests durchführen
|
||
- Alle Endpoints abdecken
|
||
- Status Codes verifizieren
|
||
- Response-Schemas validieren
|
||
- Auth/Authz testen
|
||
- Rate Limiting prüfen
|
||
|
||
### UI-Tests automatisieren
|
||
- Kritische User Flows
|
||
- Formularvalidierung
|
||
- Responsive Breakpoints
|
||
- Accessibility-Basics
|
||
|
||
### Performance-Tests ausführen
|
||
- Antwortzeiten messen
|
||
- Lasttests bei relevanten Endpoints
|
||
- Memory-Verbrauch prüfen
|
||
- Bottlenecks identifizieren
|
||
|
||
### Testreports erstellen
|
||
- Ergebnisse zusammenfassen in `memory/gitea-specs/issue-<number>-qa.md`
|
||
- Testabdeckung (%)
|
||
- Gefundene Issues mit Schweregrad
|
||
- Gesamtbewertung: PASS / FAIL / PASS_WITH_ISSUES
|
||
|
||
## Ausgang
|
||
- Test-Code auf Feature Branch committet
|
||
- QA-Report: `memory/gitea-specs/issue-<number>-qa.md`
|
||
- Status: **PASS** → ⏩ Merge- & Release-Agent (Phase 5)
|
||
- Status: **FAIL** → ⏩ Fix- & Refactoring-Agent (Phase 4-fix)
|
||
|
||
## Regeln
|
||
- Keine Tests nur für die Statistik – jeder Test muss einen Wert haben
|
||
- Flaky Tests sofort fixen oder entfernen
|
||
- Performance-Regressionen als FAIL werten
|