You turn around a failing software testing function by making it useful again, not by announcing a quality transformation.
The function is there to help delivery understand software risk and find important problems early enough to act. If it cannot do that, work backwards from why. Renaming QA as Quality Engineering is free, fast and occasionally the only part of the transformation delivered on time.
For a failing function, we can review the actual work, people, suppliers and constraints and give you a practical recovery view rather than starting with a maturity score.
Diagnose before reorganising
Do not redraw reporting lines until you understand the failure. Is testing technically weak? Too late? Under-resourced? Buried in manual regression? Blocked by environments? Controlled by a supplier? Producing evidence nobody understands?
Different causes require different fixes. Reorganising everyone into a Quality Engineering function does not repair a broken test environment, although it does generate impressive new job titles.
Get immediate risk under control
For live programmes, stabilise the next releases. Identify critical risks, improve evidence, make serious gaps visible and create clear release ownership. Recovery cannot wait for the perfect target operating model.
Build capability where it matters
Keep experienced people who understand the product and can challenge delivery. Coach weak areas. Bring in specialists where the gap is genuinely specialist. Improve testability and automation where they shorten useful feedback.
Do not assume everyone needs another certification. Qualifications can help foundations. Real improvement comes from better judgement and better working conditions.
Remove structural waste
Shrink regression that no longer earns its cost. Fix flaky automation rather than rerunning it. Remove duplicate assurance. Improve data and environments. Stop reports that describe activity without risk.
If the turnaround has 86% of actions complete but releases are still terrifying, congratulations on the actions.
Make leadership tell the truth
The test function needs permission to deliver bad news without becoming the problem. Leaders must distinguish testing evidence from release decisions and stop rewarding green dashboards over accurate ones.
A successful turnaround is not a new process library. It is when teams get faster, evidence becomes more trustworthy, important defects are found earlier and management can make decisions without asking for another slide to explain what the last slide meant.
Know what recovery looks like before declaring victory
Define a small set of outcomes that would show the function is healthier: important feedback arrives earlier, release evidence is clearer, environment downtime falls, serious escapes reduce, automation is trusted, and teams can explain risk without translating it through five layers of reporting.
Those outcomes are harder to manipulate than a transformation plan showing 86 per cent of actions complete.
Once the function reliably supports delivery decisions, stop transforming it for a while. Continuous improvement is useful; permanent transformation often means the organisation has forgotten how to operate normally.
A realistic 90-day turnaround outline
- Days 1–15: Contain and diagnose. Protect the next release, follow evidence back to real tests, identify major waiting and rework, and listen to the people who do the work. Publish a small risk-led priority list.
- Days 16–45: Repair the biggest constraints. Fix unstable environments or data, challenge the weakest coverage, remove obviously wasteful reporting and agree what senior management actually needs to decide.
- Days 46–75: Build repeatable capability. Coach test leadership, improve automation where it pays back, clarify ownership across teams and suppliers and put production incidents back into test design.
- Days 76–90: Check results and transfer ownership. Compare release evidence quality, wasted time and significant escaped defects against the starting point. Keep only changes that show useful improvement and identify accountable internal owners.
That timetable is a planning example, not a promise that every organisation can be fixed in three months. A structural environment or contract problem may take much longer. The early goal is reliable decisions; the later goal is a team that can spot and correct its own weaknesses. For the immediate starting point, see what to fix first in a messy testing function.
Leave behind a function that can challenge itself
A turnaround is fragile if it works only while a strong external leader or consultant is present. Build internal people who can question test scope, challenge metrics, review incidents and remove low-value activity themselves. A recovered function should eventually stop needing recovery consultants. Otherwise the recovery has accidentally become a business model.
The healthiest end state is not dependence on the turnaround team. It is a testing function capable of noticing when its own process has become nonsense and changing it before somebody commissions another transformation.