db82c851b5
- gitea-analyse-architektur (Phase 1) - gitea-implementierung (Phase 2) - gitea-code-review (Phase 3) - gitea-test-qa (Phase 4) - gitea-fix-refactoring (Phase 5, on demand) - gitea-merge-release (Phase 6) - gitea-deployment (Phase 7) - gitea-abnahme-validierung (Phase 8) - gitea-dokumentation-closing (Phase 9) - gitea-issue-resolver updated as pipeline orchestrator - Only issues tagged KI + ReadyForDev are processed
92 lines
2.5 KiB
Markdown
92 lines
2.5 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: Vierte Phase der Gitea Issue Pipeline. Stellt sicher, dass die Implementierung korrekt und robust ist.
|
||
|
||
## 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
|
||
- Status: **FAIL** → ⏩ Fix- & Refactoring-Agent
|
||
|
||
## 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
|