Task library BRELEASE Quality engineering · Phased project Risk-based release acceptance A fictional retailer is changing delivery options. Its regression suite is large, but no one can explain whether inventory, totals, or recovery behavior is covered.
Practice brief · Version 5
Project scope 10 tickets / 3 phases
Total focused work estimate 28h + setup
Suggested stack TypeScript · Playwright · PostgreSQL Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included.
Choose a bounded subset for an assessment or practice session. Prerequisites and remaining project work must be agreed separately.
Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.
Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned.
Recommended next step Start with BRELEASE-101 Open the first ticket for its prerequisites, acceptance criteria, verification plan, and an editable task draft.
What the engineer takes away Practice risk analysis, exploratory testing, and evidence-based release decisions.
What the team gains Provide a reviewable release assessment tied to customer-impacting invariants.
Before you start Build a minimal local checkout fixture with synthetic prices, inventory, and a mock delivery provider. Delivery agreement Deliver the acceptance suite, exploratory notes, and a local release rehearsal; no live transactions.
AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior.
Delivery phases PHASE 1 Translate the change into observable business invariants.
PHASE 2 Test changed behavior and failure recovery.
PHASE 3 Report uncertainty and make rollback conditions explicit.
Scope release risk Translate the change into observable business invariants.
BRELEASE-101 Entry ticket; project setup still required BRELEASE-102 Depends on BRELEASE-101 Exercise critical paths Test changed behavior and failure recovery.
BRELEASE-103 Depends on BRELEASE-102 Estimated field mix
Quality engineering 60% Frontend 40% BRELEASE-104 Depends on BRELEASE-101 Estimated field mix
Quality engineering 60% Backend 40% BRELEASE-105 Depends on BRELEASE-102 Estimated field mix
Accessibility 50% Quality engineering 50% BRELEASE-106 Depends on BRELEASE-103, BRELEASE-104 Estimated field mix
Quality engineering 50% Distributed systems 30% Integrations 20% BRELEASE-107 Depends on BRELEASE-105, BRELEASE-106 Estimated field mix
Quality engineering 80% Frontend 20% Prepare release review Report uncertainty and make rollback conditions explicit.
BRELEASE-108 Depends on BRELEASE-101, BRELEASE-107 BRELEASE-109 Depends on BRELEASE-108 Estimated field mix
Quality engineering 80% Developer tooling 20% BRELEASE-110 Depends on BRELEASE-106, BRELEASE-109 Estimated field mix
Quality engineering 40% Platform engineering 30% Database engineering 30% Use this project CSV keeps grouping and dependency keys as descriptive fields. Import mapping depends on your tracker configuration.