Orqestria Letöltés
← Weboldal építők adatlapja

Skill · 1.0.0 verzió

Bizonyítékokra épülő tesztjelentés

Bizonyítékkal és megfelelő súlyossággal választja szét az igazolt hibát, bizonytalan követelményt és lefedettségi korlátot.

bug-evidence-qa-reporting

Ezt a skillt használó csapattagok

Nézd meg, miben segít

Mikor hasznos?

Akkor használd, ha a kiadási döntéshez igazolt megállapításokra van szükséged általános sikerállítás helyett.

Miben segít neked?

  • Rögzíti a tesztelt verziót, környezetet, szerepköröket és sikeresen ellenőrzött folyamatokat.
  • Reprodukciós lépésekkel, megtisztított bizonyítékokkal és felhasználói hatás szerinti súlyossággal írja le a hibákat.
  • Külön kezeli a bizonytalan követelményt, nem vizsgált részt és szükséges szakértői átadást.

Például ezt kérheted

Készíts kiadási jelentést a pénztárról, elkülönítve az igazolt dupla terhelést a nem tesztelt böngészőtől. Mellékeld a rendelésazonosítót, megtisztított fizetési bizonyítékot és reprodukciós lépéseket. A kiadási döntés különböztesse meg a blokkoló hibát a tesztelési hiánytól.

Részletes dokumentáció

Itt a skill eredeti útmutatóját, példáit és ellenőrzési szempontjait olvashatod az eredeti nyelven.

Részletek…Összecsukás

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.

Csomagban lévő fájlok 1

  • SKILL.md