27 lines
1.3 KiB
Markdown
27 lines
1.3 KiB
Markdown
# Defect Classification
|
|
|
|
Date: 2026-03-27
|
|
Owner: QA Engineer
|
|
|
|
## Severity
|
|
|
|
| Severity | Definition | Release Impact |
|
|
| --- | --- | --- |
|
|
| S0 | Data loss, irreversible destructive action without confirmation, security exposure, or app cannot launch on a supported platform | Ship blocker |
|
|
| S1 | Core workflow broken: cannot connect, browse keys, search, edit values, manage TTL, or execute documented console flow | Ship blocker unless scope is formally descoped |
|
|
| S2 | Important workflow degraded with workaround, repeatable crash in non-core flow, major UI corruption, or packaging issue with workaround | Fix before release candidate or explicitly waive |
|
|
| S3 | Minor UI issue, copy issue, low-impact inconsistency, or edge-case defect with narrow reach | Can ship with tracking |
|
|
|
|
## Priority Guidance
|
|
|
|
- `critical`: active release blocker or broad regression.
|
|
- `high`: should be fixed in current milestone.
|
|
- `medium`: should be fixed after core acceptance path is stable.
|
|
- `low`: backlog candidate.
|
|
|
|
## QA Reporting Rules
|
|
|
|
- Every defect report should include environment, build id, exact steps, expected result, actual result, and evidence.
|
|
- If a defect is not reproducible, state attempts and why the result is inconclusive.
|
|
- If a defect is blocked by missing product implementation, report it as a gap, not as a functional failure.
|