Separate product defects from environmental test failures
An unavailable local dependency and an incorrect application response currently look identical.
- Focused work estimate
- 3h + prerequisites
- Priority in the scenario
- High
- Engineering practice
- Failure analysis · Quality engineering
Estimated field mix
- Quality engineering70%
- Site reliability30%
Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.
Review it, then add it to your workspace.
The board opens an editable draft; nothing is saved until you confirm it. Sign-in and workspace permissions apply, and Demo boards remain ephemeral.
Project context
A fictional web team reruns red builds until they pass. Shared clocks, leaked state, and unawaited work make failures hard to trust.
Setup prerequisites
- Create a small local application with three deliberately flaky tests using synthetic data and local endpoints.
Preceding work
Complete these dependencies, or supply their agreed outputs before taking this ticket.
- BTEST-101 · Record first-attempt results separately from rerun results
- BTEST-102 · Reproduce order-dependent failures with a saved shuffle seed
- BTEST-103 · Trace leaked database rows between test cases
- BTEST-104 · Replace wall-clock races with explicit clock control
- BTEST-106 · Find async work that escapes test teardown
Acceptance criteria
- Define explicit failure categories with supporting observations.
- Keep unknown causes marked unknown.
- Prevent infrastructure classification from silently turning failures green.
Implementation constraints
- Classification rules must be auditable and versioned.
Verification to include
- Classify a refused connection and an assertion mismatch.
- Verify ambiguous evidence remains unclassified.
Deliverables
- Failure triage rules.
Rollout and recovery
Use categories for routing; retain the underlying failed status.
Value of the work
For the engineer: Practice controlled diagnosis, isolation, and test reliability measurement.
For the team: Recover useful failure signals and reduce blind reruns without hiding product defects.
Evidence boundaries
Outcome Evidence: Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs.
Ownership Evidence: Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence.