Do not start by rewriting the test strategy.
When you inherit a failing testing programme, there will be pressure to demonstrate control quickly. That usually produces new governance, new templates and a large plan explaining how the programme will become excellent. Meanwhile the environment is still broken and nobody knows what is safe to release. Inherited programmes are full of ancient rituals nobody can explain because the last person who knew left during Release 14.
If you need help working out the first moves, we can review the programme and tell you where we would start before you accidentally launch a transformation of the paperwork.
Stabilise the immediate risk
Find the next important release and establish what is genuinely known about it. Identify critical journeys, serious defects, major untested areas, environment limitations and decisions that cannot wait.
You may need temporary controls while the wider programme is repaired. That is fine. Do not pretend the long-term model will be fixed before the next deadline if it will not.
Find the biggest constraints
Look for the things making everything else worse: unstable environments, poor data, no build control, huge regression packs, unclear ownership, weak automation, supplier churn or a release process that turns every change into a major event.
Fixing one real constraint can produce more improvement than redesigning ten processes around it.
Understand what the team is actually capable of
Do not assume the existing testers are the problem. Speak to them. Watch the work. You may discover a capable team buried under poor systems and impossible expectations. You may also discover weak testing hidden by lots of activity.
Keep good people. Be clear where capability needs strengthening. Do not replace experienced product knowledge simply because a new operating model looks cleaner on a slide.
Do not delete everything labelled ‘legacy’. Some of it is holding the roof up. Nobody knows which bit yet.
Create a small number of priorities
The first plan should be understandable. Stabilise release evidence. Fix the worst constraint. Clarify ownership. Improve the most important coverage. Stop low-value work. Then reassess.
A failing programme does not need to become ‘world class’ in twelve weeks. It needs to become trustworthy enough to make the next good decision, then the next one after that.
Do not erase history before learning from it
New leaders often want a clean break from the old programme. Before deleting everything, understand why the current controls exist. Some ugly processes are workarounds for real historical failures. Remove the cause first or the failure may return with a more modern template.
Review incident history, audit findings, previous release problems and supplier changes. Ask long-serving staff what repeatedly goes wrong and which fixes were attempted before.
Then keep what still protects something useful and discard the rest. Transformation should not require organisational amnesia.
A first-week plan when you inherit the problem
- Day 1: Meet the release owner and ask which decisions are imminent. Get the current scope, build and serious-risk picture. Do not announce a new operating model.
- Days 2–3: Sit with testers, engineers, operations and the supplier. Sample failed and blocked journeys. Find out whether the evidence is real and what is stopping work.
- Day 4: Pick no more than three immediate constraints, with named owners. Examples: unusable test data, a blocked payment integration and unclear release authority.
- Day 5: Give leadership a one-page account of what is known, what is still unproven and what needs a decision this week. Agree the next two weeks of action.
A first week cannot repair a failed function. It can prevent management making the next decision on fictional confidence. For a longer programme of capability recovery, see how to turn a failing test function around.
Create one credible source of release truth
Failing programmes often have several versions of status: supplier reports, test dashboards, programme packs and private spreadsheets maintained because nobody believes the other three. That makes recovery harder. Your first target is not a target operating model. It is understanding which current decisions are being made with fictional confidence.
Agree a small set of evidence that everyone uses for major release decisions. It does not need to replace every operational tool, but the programme should know which facts are authoritative when it matters.