Election-map styling is tested by one clerk on a laptop the night before go-live. What quality-for-flow approach should the Scrum Master/Team Coach want instead?
Select an answer to reveal the explanation.
Short Explanation
One clerk on a laptop the night before election maps go live is a hero, not a quality system. Spread exploratory and automated checks through the work. Two clerks at midnight is still the same late bet.
Full Explanation
Late hero testing is not quality-for-flow. Election-map styling tested by one clerk on a laptop the night before go-live concentrates risk when residents need trustworthy maps. The Scrum Master/Team Coach should want exploratory and automated checks earlier throughout the work so defects surface while change is cheap, not in a sleepless civic go-live ritual.
Keeping the night-before clerk test and adding a second clerk the same night fails by concept: more last-minute heroes still learn too late. Skipping testing if the map rendered once in development fails by concept by mistaking a happy-path glance for validation. Moving the clerk test to after residents have already used the map fails by concept by discovering defects in production on the public.
Exam caveat: SAFe quality practices emphasize continuous testing and early feedback; end-stage hero tests are a smell that built-in quality is missing. Automation and exploratory testing complement each other—neither alone replaces a disciplined flow of checks on election-facing visuals.
Operational check: add automated visual/regression checks for map styling during the iteration, schedule short exploratory sessions with clerks earlier than go-live week, and retire the night-before single-laptop gate as the primary safety net.