Your test execution burn-down has been flat for three days — how do you diagnose why?
answer
- One line, several different diseases
- Plot the state series underneath it
- Did the denominator move?
- Group the blocked rows by reason
- Re-forecast from measured throughput
basics
~20 sSplit the single line into its parts. If blocked is rising, execution is obstructed; if the planned total is rising, the cycle is moving but scope grew; if neither moved, throughput itself collapsed. The chart names the symptom, the state series names the cause.
solid answer
~50 sA test execution burn-down plots planned cases still unexecuted against time, so flat means the remaining count is not falling. That single line has at least four distinct causes and you cannot tell them apart from the line alone. Decompose it: plot the daily counts of passed, failed, blocked and not-run beside the planned total. Rising blocked with static not-run means an obstacle — a build that never deployed, missing data, a dependency down. A rising planned total means cases were added as fast as they were cleared, so the team is working and the baseline moved. Static everything means throughput itself stopped: people reassigned, one defect swallowing days of investigation, or a re-test queue churning the same cases. Then check the blocked reasons and their ages, compare measured daily throughput against the rate the plan assumed, and re-forecast the finish date from the measured rate rather than the original one.
go deeper
Know what the chart plots — planned cases not yet executed, over time — and that flat means the remaining count did not fall. Be ready to say that you would look at the underlying counts before offering any explanation for it.
Walk through the decomposition out loud: planned total, executed per day, blocked, not run, and what each combination implies. An interviewer at this level wants the mechanics, including re-forecasting from measured throughput rather than the planned rate.
Show that you group blocked rows by reason and lead with the one cause behind most of them, then quote the finish date both with and without the obstacle cleared. That pair of dates is what turns a chart into an escalation someone acts on.
Own whether the instrument is trustworthy at all: baseline discipline, whether re-tests are counted separately, and whether teams have quietly learned to keep the curve looking healthy. A chart nobody games is worth more than a chart with more series on it.
### What the chart actually plots A test execution burn-down plots **planned cases not yet executed** on the vertical axis against calendar or working days on the horizontal, usually with a straight reference line from the starting count to zero at the target date. It is a progress instrument, not a quality one: it says nothing about whether the executed cases passed. A flat segment means the remaining count did not fall. That is a symptom with several unrelated diseases, and the whole diagnostic skill is refusing to guess between them. ### Decompose before you interpret The first move is always the same: stop looking at one line and plot the underlying series per day. - **planned total** — the denominator. If it climbs, the baseline moved. - **executed per day** — actual throughput, the derivative that the burn-down hides. - **blocked** — the obstruction count, with reasons grouped. - **not run** — the untouched remainder. Four readings follow almost mechanically: 1. **Blocked rising, not-run falling slowly or static.** Something is stopping execution. Cases are being *attempted* and bouncing. This is the most common cause of a flat curve and the one with the shortest fix, because blocks cluster: usually one obstacle accounts for most of them. 2. **Planned total rising by roughly the number executed.** The team is executing normally; scope arrived at the same rate. The curve is flat because the target moved, not because work stopped. Reporting this as a stall would be a lie about your own team. 3. **Executed per day near zero, blocked and planned both static.** Throughput itself collapsed — people pulled to other work, a single deep investigation consuming days, or a long-running case in progress that shows in no counter until it finishes. 4. **Executed per day healthy but remaining unchanged.** Cases are being re-executed rather than newly executed: a re-test queue churning fixes. Real work, zero burn-down movement, and a strong sign the fix-and-re-test loop needs its own counter. ### A worked reading An online bookstore checkout cycle baselined 418 cases with a target of eleven working days, implying roughly 38 a day. Days one to three tracked the reference line. Days four, five and six are flat at 155 remaining. Decomposing: planned total is unchanged at 418, so no scope arrived. Executed per day fell from 41 to 6 to 4. Blocked climbed 9, then 24, then 37. Grouping the blocked reasons, 31 of the 37 share one: the seeded catalogue prices render in a locale-dependent format the checkout total refuses to parse, so every case that reaches the payment step stops there. One more block covers the performance case written against the 1,200-request-per-minute peak, whose load environment has been unavailable since day four. That is now a report someone can act on: testing has not stalled, it is dammed behind two obstacles with named owners, one of which accounts for 84 percent of the blocked set. The forecast follows from arithmetic, not optimism — at the measured post-block throughput of about 5 a day the cycle finishes in a month; at the pre-block 41 a day, in four days once unblocked. The gap between those two numbers is the value of clearing the block, and quoting it is how a status report earns attention. ### Re-forecasting honestly Once you know the cause, re-forecast from **measured** throughput, never from the rate the plan assumed. Remaining divided by recent daily throughput gives a working forecast; state the assumption alongside it, because a forecast that silently assumes the block clears today is a wish. It is also worth quoting two figures — the finish date if the obstacle clears now, and the finish date if it does not — since that pair is what makes an escalation concrete. ### Traps A burn-down is only as honest as its baseline. Teams that add cases without redrawing the reference line produce a curve that can never reach zero and eventually gets ignored. Teams that let cases sit in an in-progress state see a flat curve that hides real work. And a curve that turns *upward* is not a paradox: it means scope grew or executed cases were invalidated and returned to the queue, both of which are real events that deserve a sentence in the report rather than a smoothed line.
- The burn-down line moves upward instead of flat. What does that mean?The unexecuted count grew. Either cases were added to the plan after the baseline was drawn, or executed cases were invalidated and returned to the queue — a bad build, a wrong data set, a case found to be testing the wrong thing. Both are real events; the fix is to say which in words and redraw the baseline, not to smooth the chart.
- Why is daily executed count more useful than the burn-down line itself?The burn-down is a cumulative view, so a change in rate shows up only as a change in slope, days late. The daily count is the rate directly: it drops the moment throughput does, and it separates a team executing normally against a growing plan from a team that has stopped.
- How do you keep a re-test queue from making progress invisible?Count re-executions separately from first executions. Confirming a fix consumes real capacity but does not reduce the unexecuted remainder, so a cycle heavy on re-tests looks stalled on a burn-down while being fully occupied. Reporting the two counts side by side makes the effort visible and explains the flat line.
saying these in an interview costs you the question
- Reads a flat curve as testers being slow
- Never checks whether the planned total moved
- Leaves blocked rows ungrouped, so the shared cause stays hidden
- Re-forecasts using the rate the plan originally assumed
- Adds cases without redrawing the baseline, so the curve can never reach zero
- Smooths or restates the chart instead of explaining the flat segment