Wie Tester ohne Anforderungen arbeiten: Bewährte Strategien
Vermeide offene Fragen wie »Wohin geht ein Beitrag nach der Erstellung?« – sie führen zu ausufernden Erklärungen. Nutze stattdessen geschlossene Formulierungen: »Erscheint der Beitrag im eigenen Feed, im Community-Feed, in beiden oder in keinem?«
Das beschleunigt die Kommunikation – Antworten sind schnell (Ja/Nein) oder Auswahl aus festgelegten Optionen. Wende dies auf spezifische Szenarien an: Zustände, Rollen, Grenzfälle.
Regel 2: Zustandsübergänge visualisieren
Zeig, was du meinst. Zeichne Zustandsübergangstabellen für komplexe Abläufe. Beispiel: Eine Bestellung über 500 €, automatischer Beitrag, 20 Beschwerden. Was passiert? Wird der Beitrag entfernt? Was, wenn keine Beschwerden vorliegen?
Diese Tabellen erfassen wahrscheinliche und seltene Ereignisse. Sie generieren wiederkehrende Fragen und bündeln sie in einer klaren Abfrage – spart Zeit für alle Beteiligten.
Beispiel-Tabelle für einen lärmenden Gast (Rechnung unter 200 €):
| Ereignis | Aktion |
|---------|--------|
| Lärm durch Gast mit Rechnung < 200 € | Warnung | Ignorieren |
| Beschwerden > 5 | Warnung | Evakuierung |
Regel 3: CRUD-Matrizen für vollständige Abdeckung
Bei Backend-Arbeit erstelle CRUD-Operationen-Matrizen nach Rolle und Bedingungen. Entwickler kümmern sich um Kernflüsse (z. B. Sperrung des Löschens fremder Inhalte, Schutz vor SQL-Injection), aber Sonderfälle sind Aufgabe der QA.
Diese Matrizen helfen nicht nur beim Testen – auch bei der Codequalität. Teile sie mit dem Backend-Team vor Sprint-Start: »Ist das abgedeckt, oder müssen wir ergänzen?«
Beispiel-CRUD-Matrix für Beiträge:
| Rolle | Erstellen | Lesen | Bearbeiten | Löschen | Bedingungen |
|-------|----------|------|------------|--------|-------------|
| Benutzer | 200 - eigene<br>400 - andere | 200 - eigene<br>200 - andere | 200 - eigene<br>400 - andere | 200 - eigene<br>400 - andere | Nur eigene Beiträge |
| Moderator | 403 | 200 | 200 | 200 | Falls Beschwerden vorliegen |
| Admin | 200 | 200 | 200 | 200 | Keine Einschränkungen |
- Erstellen: Überprüfe rollenbasierten Zugriff, Limits.
- Lesen: Prüfe Filter, Pagination, Caching.
- Bearbeiten/Löschen: Stelle Atomarität, kaskadierende Effekte sicher.
Nach 2–3 Iterationen beginnen Backend-Teams selbst nach diesen Checklisten zu fragen, wenn sie Aufgaben planen.
Wichtige Erkenntnisse
- Geschlossene Fragen reduzieren Rauschen und fokussieren auf entscheidende Details.
- Zustandsübergangstabellen und CRUD-Matrizen machen 80 % der impliziten Anforderungen visuell sichtbar.
- Checklisten mit Entwicklern teilen beschleunigt den Zyklus – von Aufgabe zum Test.
- Implizite Anforderungen sind normal; ihre Erfassung gehört zum Job eines QA-Engineers.
- Änderungen an Anforderungen an Analysten delegieren – sie tragen die Feature-Kontextverantwortung.
Fazit: Die Änderungen delegieren
Fehlende Anforderungen sind kein Problem – sie sind die Regel. Diese drei Regeln verwandeln Chaos in Struktur. Letzte Regel: Schreibe keine Anforderungen selbst. Übergib sie an Analysten. Sie verwalten die Feature-Eigentümerschaft und bleiben im Kontext. So bleibt das Team synchron und effizient.
— Editorial Team
Noch keine Kommentare.