So you been around the company block enough times to recognize the seasons of the place.
Summer, Crunch, Performance-review, Financial Year.
You have probably seen P-1 incidents and P-I planning come and go in the calendar.
And configured things mortals wouldn't believe.
And the attack ships on fire off the shoulder of Orion.
But what is next for you, you wonder, as classic test cases work is under yet another pressure to be handed over to machines. Standing still doesn’t seem like an option (again). My current reading of the landscape, is that there are still options. That there are still paths for the experienced individual testing/QE person, but it does require you to step up. To raise your head up – and out of your usual comfortable testing realm.
In Danish this would be to either “See beyond your own nose” or “get out of the local duck pond”. The later is more classic and probably more than 150 years old, where every village had their own pond, around which the world centered. Another analogy you need to consider, is which of the below roles you prefer:
- Being the explorer, always on the hunt for the new tool or trend
- Being the villager, turning the tools and trends into something maintainable
- Being the town-planner, carefully crafting the town plans for consistency and efficiency
We can’t be all the three types all the time, and some even prefer one one type of work. That’s ok. A good organization requires all three components – as they build on each other. (Originally the Pioneers-Settlers-Town Planners). As all explorers race along with the newest AI-model hype, where does that leave the rest of the gang and how do they position themselves and hook into the ever-evolving landscape? Let me focus on two pragmatic themes.
Tell me who you are following to learn – that tells me both if you are even listening – and who you listen to.
In the Delivery (Town Planner’s Challenge)
Being part of a team tinkering on the same solution year after year is nice and all. But it’s also the safe bet. Tough times comes around and you can seem to have no influence over the in-take of tasks or even if the delivery team will exist in a few years. Perhaps the whole solution is replaced, outsourced or even handed over to a competitor. You could jump to the next team over, but the chase will never end. How are you catching up and being more effective in consistently delivering features, that the company earns money from. Alternatively you could help the company save money by applying your testing skills to all things not feature-factory.
- Test automation and AI-orchestration: Embrace the test tooling and sit in the IDE all days to tinker with skills-files and prompts to generate test cases. Shift left even further left!
- Critical thinking specialist: Dig into everything not yet automate-able. Dig into exploratory testing the application and doing all the non-obvious or challenging critical thinking only skilled people can do.
With both of these you can stay embedded in the delivery team. My hunch is that as a tester in a delivery team you have to do both of the above. To reframe: “Responding to change, while focusing on maintaining stable activities“. Which is really an evergreen IT challenge, and has been for the last 10+ years. The quote is from the The DevOps Handbook of 2016 and originally addresses the challenge of a system owner. It also applies to you, as you are the decision maker of your career.

What is clear is, that given the current tooling, the classical tester role of jockeying test cases is over. Test cases are no longer carefully crafted and unique, they are generated.
Test cases are no longer an atomic unit of measure (if it ever was). Given source code, system specs or even a one-liner, test scripts can be generated – in vast numbers both positive and negative.
Testing, Quality Engineering and Quality Assurance as such is not off the table. On the contrary – with more output, a quality mindset is even more required. It’s the way we perform the work that is under pressure. I’m currently reading a tender for (yet another) two-digit million dollar deal, test cases are an afterthought. The requirement from the customer is test automation first. So you either figure out how that works or play around it.
Supporting the delivery (Villagers Gambit)
Another growth option for the experienced quality role is to move out of the delivery assembly line and focus on supporting the delivery. When you are an experienced quality specialist you have opportunity to become an individual contributor on a higher level.
- Quality and testing coach: Take your skills and apply it across multiple teams, be their coach. Setup sharing sessions, drive organizational change or technology shifts. Yet have the mindset that you are there to enable and build, not become part of the ship
- Owning the staff-level/principal level title:this requires a mindset change. It’s no longer about you, but about the people and the organization. It’s about building the next generation, and owning your ego.
In both cases the gambit is to help a Delivery team to overcome obstacles. Also detects missing capabilities. It’s primarily about working together for a defined period of time to discover new things (APIs, practices, technologies, etc.). Be the muscle that helps the team scale – is my usual pitch. ‘
The thinking, theory and research being this is the Team Topologies Enablement-team. Be the quality person that helps the team scale and grow. But basically stop hoarding.

3 responses to “What is next after an experienced quality role? ”
as mentioned in Issue #223 : Software Testing Notes
https://softwaretestingnotes.substack.com/p/issue-223-software-testing-notes
Ma µNewsletter de la semaine #30-2026 sur l’Automatisation et la Qualité Logicielle
https://www.linkedin.com/feed/update/urn:li:activity:7485212313252311041/
as mentioned in the Software Testing Weekly #320
https://softwaretestingweekly.com/issues/320/