Orqestria Download
← Zurück zu Website-Bauer

Skill · Version 1.0.0

Belegbare QA-Berichte

Erstellt freigaberelevante QA-Befunde mit Belegen und angemessener Trennung bestätigter Fehler, unklarer Anforderungen und Prüfgrenzen.

bug-evidence-qa-reporting

Teammitglieder mit diesem Skill

Entdecke, wie der Skill hilft

Wann ist der Skill hilfreich?

Nutze dies, wenn eine Freigabeentscheidung bestätigte Befunde statt einer pauschalen Erfolgsaussage braucht.

Wobei hilft er dir?

  • Erfasst getestete Version, Umgebung, Rollen und erfolgreich überprüfte Abläufe.
  • Beschreibt Fehler mit Reproduktionsschritten, bereinigten Belegen und Schweregrad nach Nutzerauswirkung.
  • Trennt unklare Anforderungen, ungeprüfte Bereiche und notwendige Übergaben an Fachleute.

Das könntest du fragen

Erstelle einen Checkout-Freigabebericht und unterscheide eine bestätigte Doppelbelastung von einem ungeprüften Browser. Füge Auftragskennung, bereinigte Zahlungsbelege und Reproduktionsschritte bei. Unterscheide in der Freigabeentscheidung zwischen blockierendem Fehler und fehlender Testabdeckung.

Ausführliche Dokumentation

Hier findest du die ursprüngliche Anleitung, Beispiele und Prüfschritte des Skills in ihrer Originalsprache.

Details…Weniger anzeigen

Bug Evidence & QA Reporting

A useful QA report helps the team make an immediate, confident release or fix decision. It never exaggerates severity, never invents unverified root causes, and never claims "zero bugs exist" from partial checks.

Standard QA Report Structure

Structure every QA review or test report along this six-part flow:

  1. Inspected Feature, Version & Environment: What component/commit/branch was tested, in what environment, and with which configurations or roles.
  2. Verified Workflows: Which core paths and alternative scenarios were checked and confirmed working.
  3. Proven Defects (with Evidence): Reproducible bugs backed by concrete steps, inputs, observed vs. expected output, and user impact.
  4. Requirement Clarifications Needed: Ambiguous or undocumented behaviors framed as questions for product/architecture rather than false bug accusations.
  5. Unchecked Scope & Environmental Limits: What could not be tested (e.g., unavailable external service, browser/device not present) and residual risks.
  6. Recommended Next Steps: Clear release/fix verdict and handoffs.

Rules for High-Signal Bug Findings

  1. Concrete evidence and sanitization:
    • Include exact steps, input payloads, timestamps, HTTP status codes, console/server error messages, or screenshots.
    • Strip personal data (PII), live tokens, and secrets from logs and screenshots before recording them.
    • Consolidate duplicate manifestations of the same underlying issue into a single finding.
  2. User-impact severity calibration (Cem Kaner):
    • Calibrate severity by actual impact on user task completion, data safety, and security — never inflate every minor UI glitch into a release blocker, and never downgrade data loss or unauthorized access just because a manual workaround exists.
  3. Clean specialist handoffs:
    • Hand intermittent, hard-to-reproduce defects to the bug reproduction specialist (Repro).
    • Hand confirmed defects needing deep code root-cause analysis to the debugger (Atlas).
    • Route security vulnerabilities, load/capacity bottlenecks, and accessibility barriers to their respective specialists.

Enthaltene Dateien 1

  • SKILL.md