Stop arguing about whether the status should be green, amber or red. The colour is not the problem. The fact nobody trusts what sits underneath it is.
Close to go-live, you do not have time for a test transformation. You need a rapid reconstruction of what is known, what is not known and which gaps could actually hurt you. When nobody trusts the test status two weeks before go-live, the wrong response is usually a new RAG definition.
If the launch is close and the reporting has become political, we can provide an independent release view without pretending there is time to redesign your entire operating model.
Rebuild the evidence from the bottom
Identify the critical journeys and failure modes. For each one, establish the latest trustworthy evidence: what was tested, against which build, with what data, in which environment and with what result.
Ignore summary percentages until you understand the underlying facts. A dashboard can be 96 per cent green because everyone agreed not to count the tests that could not run.
Separate missing evidence from known defects
A failed test tells you something. An unrun test tells you less. A blocked test may be more worrying than either if the reason it is blocked also exists in production.
Make those categories explicit. Do not hide uncertainty inside a completion percentage.
Focus remaining time on consequence
Do not attempt to recover the original plan line by line. That time has gone. Use the remaining window on things that can materially change the release decision: money, data, access, core journeys, migration, resilience, integrations and anything difficult to recover after launch.
Low-risk cosmetic checks can wait. The objective is not to complete the plan. It is to reduce the biggest unknowns.
Changing amber to ‘amber-green’ is not risk reduction. It is graphic design under pressure.
Put the decision back where it belongs
Testing should explain the evidence. Management should decide whether the residual risk is acceptable. The report must make the evidence behind the go/no-go decision impossible to miss. If the business chooses to launch with gaps, record them clearly. If it chooses to delay, record why.
Do not force the test lead to become the human no-go gate because everyone else wants plausible deniability. A release decision is a management decision informed by testing, not delegated to it.
Do not waste the last week making the plan look complete
Close to go-live, teams often start moving scope around so the dashboard can show completion. Tests are descoped, defects are reclassified and blocked items are moved into future phases. Sometimes that is legitimate reprioritisation. Sometimes it is cosmetic surgery on the status.
Every change in scope should answer a simple question: what risk are we consciously choosing not to reduce before launch, and why is that acceptable?
If nobody can explain that, the plan is being managed rather than the release. Protect the remaining time from work whose main purpose is making the report easier to present.
Plan the first hours of production as part of the decision
When evidence is imperfect, strong monitoring, support, rollback and feature control can materially change the risk. Ask what will be watched after launch, who can act, how quickly rollback works and which failures would trigger it. If the answer is still unclear, say unclear. ‘Green subject to multiple critical dependencies’ is just red wearing office clothes.
This does not excuse weak testing. It recognises that release risk depends on both pre-release confidence and the organisation’s ability to detect and recover when reality disagrees with the plan.