Three-Week Sprints, Day-15 Testing at ShopFast
ShopFast, an online retailer, moved from waterfall to three-week Scrum sprints eight months ago but kept its testers in a separate QA group. Testing still begins on day 15, after development is declared 'code complete'. Business analysts write acceptance criteria such as 'the checkout page must be user friendly' and 'payment must work'. The 210-case regression suite is entirely manual and takes five days, so it is run once at the end of each release and compressed to three days whenever the schedule slips. Production incidents have tripled and two of the last four releases were rolled back. The product owner wants the testers to 'just automate everything' by next quarter to fix the problem.
1. Identify where this process breaks, in terms of shift-left and test levels, and propose three concrete changes with the role responsible for each.
Read the worked answer
The break is structural: testing is still treated as a phase that starts when development ends, not as an activity running throughout the lifecycle. In a 21-day sprint, testing gets days 15–21, and rollbacks show the resulting escapes.
Changes, with owners:
- Make acceptance criteria testable (shift-left on requirements). 'User friendly' and 'payment must work' cannot be tested to a pass/fail. The BA, with a tester, rewrites them as observable conditions: 'a card declined by the issuer shows error code and no order is created'. Owner: BA + tester, in backlog refinement, before the sprint starts.
- Start testing the day work starts. Testers derive test conditions from the acceptance criteria during refinement, developers write component tests and unit tests as part of 'done', and static analysis runs in the IDE/commit hook. Owner: developers + testers.
- Re-establish the test levels with clear responsibility. Component and component-integration testing belong to developers; system and system-integration testing to the QA group, executed continuously rather than as a day-15 gate; acceptance testing to the business through the product owner. An independent test level is still valuable - as a continuous check, not a final gate. Owner: test lead + engineering manager.
2. What does the five-day manual regression suite tell you about this team's test approach, and what is actually missing?
Read the worked answer
It tells you the regression suite cannot fit inside the iteration: five days of a fifteen-day test window, compressed to three under pressure. Compression is the dangerous part - coverage is silently reduced, and nobody records what was dropped. It also means nothing written between day 15 and day 21 can be regression-checked at all before release.
What is missing:
- Automation at the right level. Automate by risk and change frequency, starting with API-level checks of the highest-risk flows (basket, payment authorisation, order creation) rather than trying to automate all 210 UI cases. 'Automate everything by next quarter' is not achievable and would lock in the current test design.
- Risk-based selection. All 210 cases are not equally valuable; select by risk of the change, not by habit.
- Continuous regression in the pipeline so regressions introduced on day 16 are caught on day 16.
- Exploratory testing for new functionality, which automated scripts will not provide.
- Non-functional testing - checkout performance and behaviour under load are untested and are exactly what rollbacks usually expose.
- Confirmation testing of fixes, tracked as a distinct activity.
3. After go-live, a hotfix changes the fee calculation used at checkout and in refunds. What maintenance testing is needed and what drives its scope?
Read the worked answer
This is a modification trigger for maintenance testing, and the scope is driven by impact analysis, not by the size of the code change.
Impact analysis should trace where the fee is used: checkout totals, order confirmation, refunds, invoices/credit notes, finance reports, and any stored values calculated with the old fee. That gives the retest set.
Testing needed:
- Confirmation testing of the hotfix itself, including boundary values of the fee rules.
- Regression testing of the changed component and of everything that consumes the fee, including interfaces to the finance system and report outputs.
- Data migration/verification testing if historical orders or open refunds store calculated fees - decide whether old values stay fixed or are recalculated, and test that decision explicitly.
- Testing in a production-like environment with realistic data volumes.
Also update the testware (cases, scripts, expected data) as part of the change - stale regression assets are a classic maintenance risk. The hotfix's urgency is an argument for a risk-based selection of regression, not for skipping it.