Orqestria Download
← Back to Bug fix

Skill · Version 1.0.0

Evidence-based QA reports

Produces release-relevant QA findings that separate verified defects, uncertain requirements and coverage limitations with evidence and appropriate severity.

bug-evidence-qa-reporting

Workflow agents using this skill

See how it helps

When is it useful?

Use when a release decision needs verified findings rather than an unqualified claim that everything works.

What does it help you do?

  • Records the tested version, environment, roles and successfully checked workflows.
  • Describes defects with reproduction steps, sanitized evidence and severity based on user impact.
  • Separates unclear requirements, untested areas and the specialist handoff each finding needs.

Try asking this

Prepare a release report for checkout, distinguishing a confirmed duplicate charge from an untested browser. Attach the order identifier, sanitized payment evidence and reproduction steps. The release decision should distinguish a blocking defect from a coverage gap.

Detailed documentation

Read the skill’s original instructions, examples and checks in their authored language.

Details…Show less

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.

Included files 1

  • SKILL.md