The Hardening Sprint and the 2.5-Day Regression Run
Atlas Retail has five developers and three testers working in two-week sprints. Regression testing is a 2.5-day manual run of 240 scripted cases executed at the end of each sprint. In the last three sprints, 30-35% of committed stories were not finished by sprint end, and the regression run has slipped into the next sprint twice. Developers merge to trunk daily, but there is no automated test suite beyond a few unit tests. The product owner has proposed a 'hardening sprint' before the next release to catch up, and has also asked the testers to skip the lower-priority regression cases to save a day. Post-release defects have risen, and two of the last five were in areas that the regression suite covers.
1. Evaluate the proposal to skip the lower-priority regression cases to save one day, and recommend what to do instead.
Read the worked answer
Skipping a fixed slice of cases is de-scoping, not risk-based testing. 'Lower priority' presumably reflects an old ranking, and the fact that two recent escapes were in covered areas shows the suite is not aligned with current risk. Cutting a day without analysis simply moves cost to production.
Instead, rank the 240 cases by risk using change impact, defect history and business criticality. Retain all high-risk cases, then use exploratory charters around changed areas to compensate for the cases you drop. Agree the residual risk explicitly with the product owner and record which cases were not run and why.
Also examine the suite itself. A 2.5-day manual run of 240 cases almost certainly contains repetitive confirmation checks that should be automated or retired. Automate a stable smoke set first so that every trunk merge gets fast feedback, then shrink the end-of-sprint manual run. This addresses the time problem without pretending that skipping tests is free.
2. Assess the 'hardening sprint' proposal and describe what should happen instead.
Read the worked answer
A hardening sprint treats a symptom. It creates a safety net that legitimises unfinished work during normal sprints and makes the next hardening sprint predictable. It also hides the real causes of 30-35% carry-over: stories too large, unclear acceptance criteria, environment contention, insufficient automation and too much work in progress.
A one-off hardening sprint can be justified only with explicit entry and exit criteria, a fixed deadline and a concurrent improvement plan. Without those, debt returns immediately after the release.
Instead, inspect the carry-over data. If stories are too large, slice them. If the definition of done is weak, strengthen it and enforce it. If manual regression consumes testers, automate the highest-value checks. Limit work in progress and forecast using historical velocity rather than hoped-for capacity. The test analyst's contribution is to make the quality debt visible with metrics - carry-over, escaped defects, regression duration - and to show the product owner the trade-off between scope and confidence.
3. Describe how you would introduce exploratory testing within the sprint without adding headcount.
Read the worked answer
Use session-based test management and fund it by retiring low-value scripted checks. Allocate roughly 10-15% of sprint testing capacity, starting small and adjusting. Write risk-based charters, for example 'Explore claim submission with interrupted network and back-button navigation', each timeboxed to 60-90 minutes.
Record coverage, defects, issues and questions during the session, then hold a short debrief with the tester and a developer. Feed the findings into the backlog and into new automated checks where the behaviour is stable.
This adds no headcount because it reallocates effort from redundant confirmation to risk discovery. It also pairs naturally with the regression problem: as stable scripted cases move to automation, the freed time funds exploratory sessions. Publish simple metrics - sessions run, defects found, areas covered - so the product owner can see the return rather than perceiving exploratory testing as unstructured time.