ForconfirmedBugs, perform root cause localization, impact analysis, and regression recommendations.
- Input: Bug report (symptoms + reproduction steps + evidence), code repository, (optional) requirements model / test cases; in batch execution scenarios, Category A entries may come from the failure triage table (
../core/triage.mdoutput; the G/S signal summary and evidence fields attached to the entry are the starting point for reproduction) - Output (persisted): Bug entry (structure see below),appended to the test report（
../core/report-template.md§3's five extended fields—root cause analysis / impact scope / Severity basis / fix recommendation / regression recommendation—are the filling scope of this skill) - Boundary: The input is aconfirmedBug (the user or execution result has already determined "this is a defect");suspecteddefects found in review (pending verification) go to
test-case-writing's Cx records; regressionscope selectiongoes toregression-testing
When to Use
- The Bug has already been confirmed as a defect and the root cause needs to be located (read to
文件:行's branch point) - The Bug's impact surface needs to be assessed (other paths with the same root cause / dirty data / affected users)
- After the fix, regression test case recommendations are needed (fix verification + related regression)
When NOT to Use
- Not yet determined ("Is this a Bug or a feature?") → first go through user adjudication (Bug determination checkpoint, see
qa); evidence collection stage →automated-e2e-testingworkflow two /api-testing - Suspected defects found in code review (not reproduced, not determined) →
test-case-writing's Cx defect records (pending actual-test confirmation) - A regression checklist is needed (which test cases to run) →
regression-testing(this skill produces regression test caserecommendations） - End-to-end pipeline →
qaorchestration (this skill is its stage 6)
Bug entry structure (appended to the test report)
Entry fields and filling templateWith ../core/report-template.md §3 as the sole source(loaded at this point), this skill only supplements the filling semantics:
- Filling scope of this skill: the five extended fields—root cause analysis / impact scope / Severity basis / fix recommendation / regression recommendation (in report §3, the 8 basic fields other than "re-verification round"—severity / status (initially "new", subsequently updated with regression results, see
../core/report-template.mdusage convention 6) / discovery method / reproduction steps / expected behavior / actual behavior / evidence / environment—are already filled by the discoverer and are not rewritten) - Root cause analysismust be annotated with status:Inference(inferred from reading code, not verified by running) or Verified(verified through reproduction/minimal experiment, E3)—do not disguise inference as fact (for status semantics see
../core/evidence.mdSection 3) - Impact scope / Severity basisgive the source for each item; the evidence chain is annotated with evidence level (E0–E4 +
文件:行）
Workflow
1. Reproduce (obtain stable evidence first)
- Reproduce following the bug report steps; if it cannot be reproduced → do not force analysis, distinguish "environment differences / data dependencies / probabilistic", and ask the user for environment and data clues
- Collect evidence during reproduction: raw request/response, logs, screenshots (E3 runtime evidence)
- Probabilistic bug tactics: for low-frequency reproductions, do not just wait—① Baseline quantification: first run enough samples to establish a reproduction frequency baseline (N≥10 runs recording trigger count, e.g. "N≥10 triggered 2 times"), and after the fix re-verify under the same conditions for comparison, to avoid misjudging a single pass as fixed; ② Targeted frequency increasethree types: for concurrency type, increase concurrency / shorten operation intervals and rerun; for time type, concentrate triggering at timezone / cross-day / cross-second boundary moments; for environment type, switch device / data / network conditions to compare and isolate trigger factors
2. Read the code to locate the root cause
- Trace downward from the symptom entry point (page/API): entry → call chain → data read/write, locating thespecific divergence point between actual behavior and expectation（
文件:行） - Check common root cause categories: missing boundary protection / missing null fallback / state race / incomplete transaction / cache inconsistency / missed permission check / concurrent overwrite / configuration drift
- Mark the root cause conclusion with status:Inference(code inference, not verified by running) or Verified(verified through reproduction/minimal experiment, E3)—do not disguise inference as fact
3. Impact analysis (five dimensions)
- Functional dimension: which entries/paths the same root cause affects (grep other call sites with the same pattern)
- Data dimension: whether dirty data has already been produced, and the scope of impact on existing data
- User dimension: affected roles and operation paths
- Security dimension: whether the defect constitutes anexploitable window(privilege escalation reachable / sensitive data exposure / injection surface)—if hit, Severity is raised by one level (S2→S1, S1→S0, capped at S0). Note the division of labor with the severity rating rules in step 4: the security dimension is used for raisingpotential windows; foractual security consequencesalready constituted (data loss / financial loss / actual privilege escalation achieved), direct S0 applies, and the raising criterion does not apply
- Fix blast radius: which code / configuration / data the expected fix approach will change—the behavior changed by the fix itself is the direct input for regression recommendations (connecting to step 5)
4. Severity rating and fix recommendations
- Severity is graded by consequence (the S series is separate from the use case priority P series): data loss/financial loss/actual security consequences already constituted(such as data exposure from actual privilege escalation achieved) → S0; core functionmain pathunavailable → S0, core functionbypass pathunavailable → S1; partial degradation → S1; experience issue → S2. Security issues that only constitute apotential exploitable windoware not raised to S0, but are raised by one level according to the security dimension in step 3 (the two criteria corroborate each other, preventing double application of rules for the same trigger)
- Fix recommendations give adirection(e.g. "add the same validation to the import path as the create path"), without overstepping to write patches for developers
5. Regression recommendations (connecting to regression-testing)
- Fix verification cases: cases that directly reproduce the Bug (if none, suggest adding new ones; give TC number suggestions); for suggested new cases, follow the
../core/case-format.mdformat and../core/executability.mdexecutability criteria, so that they are executable as soon as they are placed into the case file - Related regression: other paths with the same root-cause pattern + anchor cases for this feature
- Bidirectional cross-linking: write this entry's number into the "Related Bug" row of the corresponding regression checklist, and backfill the TC numbers of the fix verification cases in the checklist into this entry's "Regression Suggestions" — Bug list ↔ regression checklist are traceable in both directions (for the checklist-side template, see regression-testing)
- Regressionscope selection(which existing cases to run, and grading) is handed over to
regression-testing
6. Persist to disk
For standalone single-stage use: append Bug entries to the corresponding entries in the test report (supplementing the five extended fields such as root cause analysis); if there is no report, a new report file may be created (according to ../core/report-template.md). When run as the Bug analysis stage of the pipeline: do not create or rewrite the final test report — entries are uniformly written to {项目}/Bug条目_{日期}.md intermediate files, to be assembled by the orchestration wrap-up stage, avoiding dual data sources caused by writing twice to a file with the same name as the wrap-up report.
- Knowledge deposition determination(mandatory at wrap-up): if this root cause + fix method passes
qa-memory's write criteria ("a new session retesting three months later can save one rediscovery"), deposit it according to its process as a defect entry in the project.qa/knowledge base (evidence points to this Bug entry), for direct reuse by subsequent sessions
Common Mistakes
| Error | Consequence | Correct practice |
|---|---|---|
| Starting analysis before reproducing | Root cause is built on imagination | Reproduce first to obtain E3 evidence; if it cannot be reproduced, first ask for clues |
| Treating root cause speculation as fact | False conclusions spread | Mark status as Inference/Verified (../core/evidence.md） |
| Treating the symptom as the root cause ("API timed out, root cause: API timed out") | Analysis spins in place | Trace to the 文件:行 |
| Looking at impact scope as only a single point | Other paths with the same root cause are missed in fixing and testing | grep the same pattern; analyze the five dimensions of feature/data/user/security/fix ripple effects |
| Writing patch code beyond boundaries | Overstepping responsibilities, interfering with development | Provide fix direction and verification suggestions |
| Also doing regression scope selection | Overlaps with regression-testing responsibilities | This skill produces regressionsuggestions, scope selection is handed over to |
| Suspected defects (not yet classified) go directly into this process | Confused with Cx recording responsibilities | Input must be a confirmed Bug; if not yet classified, first go through adjudication |