Replace timing sleeps in the checkout happy path
Checkout passes locally but fails in CI after a fixed 500 ms sleep. Wait for user-visible readiness and assert the final receipt against the fixture.
- Focused work estimate
- 1h 15m + prerequisites
- Priority in the scenario
- Medium
- Engineering practice
- Browser testing · Accessibility selectors · Synchronization
Estimated field mix
- Quality engineering100%
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 small commerce team has happy-path browser tests but still ships rounding and retry defects. Model a fictional shop using synthetic products, a local payment double, and explicit cart rules before adding regression coverage.
Setup prerequisites
- Create or provide a local checkout fixture application.
- Model products, tax rules, inventory, and a payment-provider double using synthetic data.
Preceding work
Complete these dependencies, or supply their agreed outputs before taking this ticket.
Acceptance criteria
- The happy path contains no arbitrary timing sleeps.
- Selectors use accessible roles and names where the interface exposes them.
- The receipt order reference and charged amount match the created order.
Implementation constraints
- Wait on observable state transitions, not broad network-idle heuristics.
Verification to include
- Run with the payment double delayed by several deterministic values.
- Keep the submit button disabled and verify the test times out at an actionable readiness assertion.
Deliverables
- Stable checkout browser test and selector rationale
Rollout and recovery
Run beside the existing happy path for comparison, then remove the redundant sleep-based version.
Value of the work
For the engineer: Practice risk-based test selection, stable browser automation, and diagnosis of intermittent failures.
For the team: Review whether a test suite catches business regressions and explains failures without creating noisy release gates.
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.