Was ist eine QA-Testcheckliste?
Eine QA-Testcheckliste macht den Testdurchlauf zu abhakbaren Schritten auf dem Arbeitselement: Umgebung bereit, funktionale Abdeckung, Edge Cases, Browser, Security-Checks und Sign-off. Die Form der Liste ist für jeden Bug oder jede Story gleich; nur die Haken und die Evidenz ändern sich.
Der Durchlauf sitzt neben den Acceptance Criteria: diese Zeilen beschreiben das zugesagte Verhalten, und die QA-Testliste hält fest, wie Sie es bewiesen haben. Definition of Done kann verlangen, dass diese Liste vollständig ist, bevor die Story ausgeliefert wird.
Warum Teams QA-Tests auf dem Vorgang halten
Ein Testdurchlauf in einer Tabelle, einer Confluence-Seite oder einem Slack-Thread geht leicht verloren, wenn die nächste Person das Ticket öffnet. Eine Checkliste auf dem Arbeitselement hält Setup, Abdeckung und Evidenz dort, wo die Arbeit schon lebt — Tester setzen Item-Status wie In Progress und Blocked, setzen ein @mention auf einen Owner einer hängenden Zeile, und das Board zeigt die Restarbeit.
Derselbe Durchlauf gilt, ob Sie einen Bugfix oder eine Story verifizieren: Sie öffnen den Vorgang, sehen, was offen ist, hängen Screenshots oder Logs bei Fehlern an und schreiben das Ergebnis auf das Ticket. Risikoarme Textänderungen können Security- und Plattformzeilen streichen; bei hohem Risiko bleiben sie.
Wann anwenden
Nutzen Sie eine QA-Testcheckliste auf Bugs, auf Stories, die vor Done einen strukturierten Durchlauf brauchen, oder wenn der Status Ready for test wird. Wenden Sie sie per Vorgangstyp für Bugs automatisch an, oder bei diesem Statuswechsel, damit Tester immer dasselbe Gerüst bekommen. Streichen Sie Zeilen bei geringem Risiko; behalten Sie Security- und Regressionsabdeckung, wenn die Änderung Auth, Payments oder einen gemeinsamen Pfad berührt.
QA-Tests vs. Acceptance Criteria vs. Definition of Done
Acceptance Criteria beschreiben, was diese Story liefern soll — die Beispiele, die Sie demoen. Die QA-Testcheckliste ist, wie Sie diese Beispiele beweisen: Daten, Browser, Regressionen und Notizen. Definition of Done ist die gemeinsame Exit-Leiste, die jede Story am Ende schuldet — Tests, Review und Release-Bereitschaft. Halten Sie alle drei als getrennte Checklisten auf dem Arbeitselement, damit Verhalten, Testdurchlauf und Ship-Qualität klar getrennt bleiben.
QA-Tests — ein Beispiel zum Start
Um Ihre erste QA-Testcheckliste aufzubauen, starten Sie mit dem Beispiel unten. Kopieren Sie die Liste und fügen Sie sie in das Eingabefeld von Checklist for Jira auf einem Bug oder einer Story ein. Ideal: als Vorlage speichern und automatisch anwenden, wenn Bugs erstellt werden oder Arbeit nach Ready for test wechselt — so haben Tester ein konsistentes Gerüst und dieselben Überschriften jedes Mal. Streichen Sie Zeilen, die Ihr Team überspringt; ergänzen Sie, was Ihr Prozess braucht.
QA-Testdurchlauf
- Setup
- Testumgebung, Build und Feature Flags entsprechen dem Arbeitselement
- Testdaten und Accounts sind bereit, einschließlich Berechtigungs-Randfällen
- Bekannte Bugs, die außerhalb dieses Durchlaufs liegen, sind auf dem Vorgang verlinkt
- Funktionale Abdeckung
- Der Happy Path entspricht den Acceptance Criteria auf diesem Arbeitselement
- Validierung, Leerzustände und offensichtliche Fehlerpfade sind durchgespielt
- Berechtigungen und Rollenunterschiede sind geprüft, wenn Zugriff zählt
- Edge Cases
- Grenzwerte, leere Collections und parallele Edits sind abgedeckt, wenn sie gelten
- Unterbrochene Flows setzen sauber fort oder scheitern klar — Timeouts, Retries und abgebrochene Requests
- Regression und Plattformen
- Angrenzende Flows, die denselben Codepfad teilen, funktionieren noch
- Primäre Browser oder Geräte, die das Team vereinbart hat, sind abgedeckt
- Accessibility-Smoke: Tastaturpfad und sichtbarer Fokus auf neuen Controls
- Security
- Autorisierung hält: ein User sieht oder ändert keine Daten eines anderen Tenants
- Sensible Werte bleiben aus URLs, Logs und Fehlermeldungen draußen
- Evidenz und Sign-off
- Screenshots, Aufnahmen oder Log-Links sind bei Fehlern angehängt
- Neue Defekte sind angelegt und verlinkt, mit gesetzter Severity
- QA-Ergebnis steht auf dem Arbeitselement: pass, fail oder blocked mit Owner
Dieses Gerüst gehört auf jeden Bug und auf Stories, die einen strukturierten Durchlauf brauchen. In Checklist for Jira fügen Sie Punkte im Issue-Panel hinzu oder haken sie ab, speichern die Überschriften als Projekt- oder globale Vorlage und wenden sie automatisch an, wenn Bugs erstellt werden oder der Status Ready for test wird — oder manuell über Add → Add from template, wenn Sie sie brauchen.
Bringen Sie die Checkliste dorthin, wo das Team arbeitet
Checklist for Jira legt Vorlagen, Automatisierung und Workflow-Prüfungen direkt auf den Vorgang. Kostenlos für Teams mit bis zu 10 Benutzern — ohne extra Subtasks.
Starter speichern, den Durchlauf automatisieren
- Checklist for Jira fügt ein Checklist-Panel in der Vorgangsansicht hinzu. Fügen Sie das Beispiel oben auf einem Bug oder einer Story ein, passen Sie Zeilen an Ihren Prozess an und speichern Sie die Form als Projekt- oder globale Vorlage in den Checklist settings.
- Markieren Sie die Vorlage als Protected, wenn die Schrittliste gesperrt bleiben soll, während Tester Punkte abhaken und Status wie In Progress und Blocked setzen.
- Nutzen Sie Automatisierung pro Vorlage, um das QA-Testgerüst anzuhängen, wenn ein Bug erstellt wird oder der Status Ready for test wird. Diese Automatisierungen sind in Checklist for Jira eingebaut und laufen ohne Jira-Automation-Credits.
- Wenn Ihr Team eine Erinnerung vor Done will, setzen Sie einen Completion-Validator auf diesen Übergang, begrenzt auf diese Vorlage, damit das Arbeitselement offen bleibt, bis der Durchlauf fertig ist.
- Kombinieren Sie mit Acceptance Criteria für die Beispiele, die der Durchlauf beweist, Definition of Done am Ende und der Release-Checkliste, wenn die Änderung ausgeliefert werden soll — siehe Automatisierungsleitfaden.
Mit dem Rest des Delivery-Sets kombinieren
Halten Sie Acceptance Criteria auf demselben Vorgang für das zugesagte Verhalten. Hängen Sie Definition of Done an, wenn Arbeit in den Sprint geht, damit die Ship-Leiste vom ersten Tag an sichtbar ist. Nutzen Sie Definition of Ready in der Refinement, wenn Intake-Qualität Ihrem Team hilft. Weiter geht es mit der Release-Checkliste, wenn die Änderung ausgeliefert werden soll. Das volle Set finden Sie im Vorlagen-Hub.
Häufige Fragen
Sollte jeder Testfall eine Unteraufgabe sein?
Öffnen Sie eine Unteraufgabe, wenn ein Fall eigenen Assignee, Schätzung und Workflow braucht. Eine strukturierte QA-Testcheckliste auf dem Parent ist der leichtere Weg für einen Standarddurchlauf.
Wie unterscheiden sich QA-Tests von Acceptance Criteria?
Acceptance Criteria sind die Beispiele, die Sie demoen — wie „korrekt“ aussieht. Die QA-Testcheckliste ist, wie Sie sie bewiesen haben: Umgebung, Fälle, Evidenz und Sign-off auf demselben Arbeitselement.
Können wir über unvollständige QA-Listen berichten?
Checklist for Jira zeigt Fortschritt am Vorgang, auf Boards und in JQL, sodass unvollständige QA-Arbeit filterbar ist.
Sollen Bugs und Stories dieselbe QA-Liste nutzen?
Starten Sie mit einer Vorlage und kürzen Sie. Bugs behalten oft den vollen Durchlauf. Stories können Security- oder Plattformzeilen streichen, wenn die Änderung geringes Risiko hat. Speichern Sie eine zweite Vorlage pro Vorgangstyp, wenn die beiden Listen unterschiedlich bleiben.
Bringen Sie die Checkliste dorthin, wo das Team arbeitet
Checklist for Jira legt Vorlagen, Automatisierung und Workflow-Prüfungen direkt auf den Vorgang. Kostenlos für Teams mit bis zu 10 Benutzern — ohne extra Subtasks.