From functional tester to Test Practice Manager

The usual way to lose a good tester is to promote them. They become a test lead, the calendar fills with meetings about quality, and within a few months they hold opinions about the product with no recent evidence behind any of them. The team notices before they do.

I made that move over four years on a global facilities-management programme, from functional QA to Test Practice Manager. I started as the person who executed cases and logged defects, and that is still the spine of the job. What changed was scope: from “did I test my slice?” to “does the practice produce trustworthy evidence for every slice?”

The path from tester to test lead

I have worked in QA since 2012. I started by testing mobile games, then led QA for the games stream of a large betting platform. After that came consulting on mobile banking and on a business-process platform for banks, three years on digital-experience programmes for banking and industrial brands, and three years on a multi-tenant smart-city parking platform with native iOS and Android apps, web, a back office, APIs and a CMS. Alongside the parking work I had a part-time engagement on an ERP front end. A short spell in a mobile games studio followed, and then the facilities programme.

What that gave me was range. Players, bank customers, drivers paying for parking and facilities teams have very different ideas of what a serious defect is, and a tester who has seen only one product tends to treat its conventions as rules.

The early phase on the facilities programme was depth: learning the domain, pairing with developers, and writing defects Product could act on. Credibility came from finding real user friction, never from being the loudest voice in refinement. The order matters. Nobody takes a strategy seriously from someone whose defects they did not trust.

What a Test Practice Manager does

Titles vary, so here is what the role meant for me. A test lead answers for the testing of one team or one release. A practice manager answers for how testing is done across teams: the standards, the tooling, the people and the evidence leadership sees.

In practice I rebuilt the test strategy from scratch, wrote test-case guidelines, built dashboards in JIRA and Azure DevOps, interviewed and mentored QA engineers, and took ownership of a defect backlog that had gone stale. I also introduced a Quality Maturity Matrix, so that leadership had a view of quality they could use in planning.

What changed when I moved into test leadership

The unit of work changed. For a tester, a good day is a defect that spares a user something. For a practice lead, a good day is a change that improves everyone’s defects. The work that has paid back most for me is of that kind: a defect template that cut developer returns by about 40%, automated JIRA reporting that cut report effort by about 70%, and end-to-end documentation that cut the team’s effort by about 30%.

The stale backlog was the clearest case. A backlog full of duplicates and tickets nobody believes costs every triage meeting something, and owning it made the defect conversation roughly 40–50% more efficient. I describe the method in Defect backlog hygiene beats writing more cases.

Practice management also meant covering gaps. When delivery needed continuity I stood in for Product Owners and Scrum Masters. Sitting in those chairs shows you what a release looks like to the person who has to say yes, which is worth having, provided you hand the chair back. The Azure DevOps views I built were for the same people: if they can see the state of the work, nobody has to perform it in a status meeting.

And it meant mentoring, so that teams did not wait on one person to move. That has its own piece: Mentoring QA without cloning yourself. None of this replaces functional judgement. It multiplies it.

What goes wrong when a tester becomes a manager

• The process cop. You hold a standard now, and it is tempting to enforce it. Templates and guidelines exist to make good work easier. Once people route around them they have failed, however well written.
• Vanity dashboards. Counts of cases written and executed are easy to build and say nothing about risk. A dashboard should show what is open against a release, how old it is and who owns it.
• The meeting-only lead. If your week has no time in the product, your judgement is running on memory.
• The permanent stand-in. Covering for a Product Owner or Scrum Master is continuity. Keeping the seat means two jobs done badly.
• The single point of approval. If every severity and every sign-off passes through you, you have scaled yourself and nothing else.

The first is the one I watch hardest. The role exists to make quality visible without slowing delivery, and a lead who is felt mainly as a checkpoint has it backwards.

What stays the same for a test lead

The user. Every artefact I produced as practice manager was an attempt to make the user’s case easier for someone else to see: a developer reading a defect, a Product Owner reading a readiness note, a Head of Engineering reading one row of a matrix. That was the job when I was logging defects on my own slice, and the title did not change it.

So my advice to anyone making this step is to protect time on journeys. Keep one area of the product that you still test yourself, end to end, every release. It keeps your evidence current, and it keeps you honest about what your own guidelines are like to follow. The moment you only attend meetings about quality, you stop producing the evidence that made people trust you.

I work as a B2B consultant now, embedded in teams again, most recently on native iOS and Android apps with wearables. The practice habits travel in a smaller form: a short strategy, a backlog cleaned before new cases are written, dashboards that show risk. Most of the week still goes inside the build, because that is where the authority to do the rest comes from.