Fix the thing that is causing the most important risk or waste. Not the thing that is easiest to put on a transformation slide.
A messy testing function usually has ten visible problems at once: old test cases, flaky automation, weak reporting, broken environments, inconsistent teams, poor data, supplier issues and unclear ownership. Trying to repair everything together creates an improvement programme larger than the testing problem. A messy testing function invites a transformation programme in the same way a kitchen fire invites somebody to redesign the cupboards.
If you want an outside view of what matters first, tell us what is going on. The useful answer should be a short priority list, not a new universe of workstreams.
Protect the next important decision
If a major release is imminent, start there. Make sure decision-makers have credible evidence about the risks that could seriously hurt them. Long-term process improvement can wait if the service is about to launch without tested migration.
Fix constraints before symptoms
If environments are unstable, improving test case templates will not rescue throughput. If nobody owns business rules, automating more scenarios may simply automate disagreement. If the supplier cannot retain product knowledge, another dashboard is unlikely to help.
Find the constraint that creates several other problems and attack that first.
Stop obviously low-value work
You do not need a perfect future-state strategy before stopping waste. Remove dead test cases. Stop producing reports nobody reads. Cancel duplicate meetings. Retire automation that has been ignored for a year. Do not preserve nonsense merely because it is documented.
Strengthen the thinking
A healthy test function needs people who can understand risk, design useful testing, challenge assumptions and explain evidence. If those skills are missing, no process redesign will compensate.
Do not create twelve workstreams to fix ten problems. You have just added two problems.
Equally, if the capability is strong but trapped in bad systems, give the team working environments, usable data and a route to decision-makers before blaming them for poor outcomes.
Fix enough to make the next decision better. Then reassess. Improvement is easier when you are solving observed problems rather than building a theoretical model of testing perfection.
Do not wait for perfect data before acting on obvious waste
You should use evidence, but some problems are visible enough to address immediately. If half the automation suite has been ignored for months, stop pretending it is a control. If three weekly meetings discuss the same status, combine them. If a report has no audience, stop producing it.
Quick removals create space for deeper work and signal that the recovery is allowed to simplify rather than only add.
Then measure whether the change caused an unintended gap. Improvement should be reversible where possible: stop the waste, observe the outcome and restore only what turns out to have been useful.
Three decisions before you redesign anything
Suppose a test function has flaky automation, an unstable environment and ten years of manual regression cases. It is tempting to launch three workstreams and recruit a transformation lead. Start smaller.
- Protect the next release: Confirm who decides and which critical journeys are still unproven. Assign somebody to obtain trustworthy evidence.
- Remove the biggest constraint: If the environment fails every second day, fix the deployment and data reset before rewriting test cases that cannot run.
- Stop one wasteful activity: Trial removing clearly duplicated low-risk regression cases on a controlled release, while retaining checks around the serious business risks. Measure what changed.
Use a two-week checkpoint. Did usable test time increase? Did the release owner receive clearer evidence? Did serious risk rise? If the experiments work, expand them. If you have inherited an entire programme, first establish the situation with a first-week diagnostic rather than commissioning a new organisation chart.
Choose experiments over grand redesign where possible
If you think regression can be cut, trial the reduced scope on a controlled release and compare the outcome. If a new reporting format should improve decisions, use it for one governance cycle before rebuilding every template. A target operating model is not a first-aid kit. Put the fire out before deciding where the future-state smoke detector reports.
Small experiments let the function learn without betting the programme on a target operating model designed in a workshop. Fixing a mess is easier when changes can prove their value before becoming permanent.