The Role Changed. The Title Didn't.

Coverage is something you measure. Confidence is something you maintain.

Welcome to The Quality Bar

Over the last few years, I've found myself having the same conversation with experienced testing leaders. The details vary depending on the organisation or programme, but the observation is remarkably consistent.

"The role feels different."

What interests me is that very few people can point to a formal change in responsibilities. Their title is often exactly the same as it was five or even ten years ago. Their teams may have grown, the technology has certainly evolved, but if you looked only at the position description, you could be forgiven for thinking very little had changed.

Yet ask someone who has spent time leading testing across modern enterprise programmes, particularly those embracing continuous delivery, DevOps or AI-enabled development, and many will tell you the same thing. The role feels more demanding, the conversations feel different and the expectations seem to have shifted in ways that are difficult to explain.

I don't think that's a coincidence.

I think the expectations of testing leadership have evolved far more quickly than the titles we've continued to give the role.

For most of my career, testing leadership followed a fairly predictable rhythm. Delivery moved towards a release. Testing gathered evidence. Risks became clearer over time, confidence gradually increased and, eventually, the organisation reached a point where it could make an informed decision about whether to proceed.

That rhythm shaped almost everything about how we worked. It influenced our governance, our reporting, the conversations we had with stakeholders and, ultimately, what organisations expected us to provide. Much of our responsibility centred on building enough evidence to support a decision at a particular point in time.

There was nothing wrong with that model. It reflected the way software was being delivered.

The challenge is that software is no longer delivered that way.

Today, many organisations release continuously. Automation performs work that once occupied entire testing teams, while AI is beginning to influence not only the systems we test but also how testing itself is designed, executed and interpreted. The cadence that defined enterprise assurance for so many years is gradually giving way to something much more fluid.

When people discuss these changes, the conversation almost always centres on speed. Faster delivery. Faster feedback. Faster automation.

Those things are certainly happening, but I've come to believe they're not the most significant change.

The more profound shift is in what organisations now expect from the people responsible for assurance.

For years, much of our value came from explaining what the testing had shown. We gathered evidence, interpreted results and communicated whether the product appeared ready for the next stage of delivery. That remains an important part of the role, but I don't believe it's the part growing in importance.

Increasingly, I've found that organisations aren't simply asking what the testing found. More often, they're asking whether they should still be confident.

At first glance, those questions sound almost interchangeable. The longer I've spent in executive forums, the more I've come to think they're ask­ing for very different things. One is really a request for evidence. The other is a request for judgement. One explains what has happened. The other helps leaders decide what should happen next.

That distinction has stayed with me because it explains why a sentence I've found myself repeating over the last few years continues to resonate.

Coverage is something you measure. Confidence is something you maintain.

Coverage remains essential. It tells us what has been exercised, what has been verified and where testing effort has been applied. Every experienced testing leader understands its value, and I don't see that changing.

Confidence, however, behaves differently. It isn't something you establish once and then assume will always be there. It shifts as systems evolve, dependencies change and organisations continue delivering software long after the original testing has finished. Looking back, I think that's where many of our conversations with senior stakeholders have quietly moved, even if they don't always describe them that way.

The questions I hear most often now aren't really about execution metrics. They're more likely to be questions like: Can we still trust this system? What's changed since we last reviewed it? How confident are we that today's controls remain effective? Where does genuine uncertainty now sit?

Those questions still depend on technical depth, certainly, but they also ask something more of us. They require interpretation. They require someone who can look beyond the testing activity itself and explain what the evidence actually means for the decision sitting in front of the organisation.

That's why I don't believe technical excellence has become less important. If anything, I think it's become even more valuable because good judgement depends upon it. What has changed is that technical capability, on its own, is no longer enough for the role organisations increasingly expect testing leaders to perform.

When I look at the leaders having the greatest impact today, they're rarely the ones producing the longest reports or the most detailed dashboards. They're the ones helping executives understand where confidence is strong, where it's beginning to weaken and, perhaps most importantly, why. They spend less time describing uncertainty and more time helping the organisation understand it.

I've noticed this becoming even more apparent as AI begins finding its way into enterprise delivery.

Much of the discussion around AI still focuses on productivity. Faster code generation. More automated testing. Less manual effort. Those are worthwhile conversations, but I don't think they're the ones that will define the next generation of testing leadership.

The questions that interest me come afterwards. How do we know the model is still behaving as we expect? What assumptions are we now relying upon? How do we explain those assumptions to executives, regulators and governance forums who ultimately carry accountability for the outcome?

Those aren't questions another execution report can answer.

They're assurance questions.

And assurance has always been as much about confidence as it has been about testing.

Looking back, I think this also explains why so many experienced testing leaders describe the role as feeling different without always being able to articulate exactly why.

The tools have changed, certainly. So has the delivery model, and technology continues to evolve at a remarkable pace. But I don't think any of those things are really the story. They've simply changed what organisations now expect from the people responsible for assurance.

Increasingly, organisations expect testing leaders not simply to verify software, but to help them understand whether confidence remains justified as that software continues to evolve. That's a broader responsibility than many of us inherited when we first stepped into leadership, and it demands a wider set of capabilities than technical expertise alone.

Judgement, communication, governance and stakeholder confidence were once viewed as complementary leadership skills. The more I reflect on where the profession is heading, the more I think they're becoming central to the role itself.

This shift became significant enough in my own work that I eventually devoted an entire module of the Stakeholder Management Masterclass for Test Leaders to assurance in AI and DevOps environments. Not because AI changes the fundamentals of testing, but because it changes the way confidence has to be established, maintained and communicated.

I don't expect the titles to change any time soon. Organisations are usually much slower to rename roles than they are to redefine what those roles are expected to deliver.

The work, however, has already changed.

The sooner we recognise that, the sooner we stop preparing ourselves for the role we inherited and begin preparing ourselves for the role organisations are quietly asking us to perform.

When I think about the testing leaders who have had the greatest influence on the organisations around them, I don't think it was simply because they knew more about testing than everyone else. Technical credibility mattered, of course, but it was only part of the picture.

What made them different was that people trusted their judgement when the answer wasn't obvious. They could explain uncertainty without amplifying it. They could give executives confidence without pretending certainty. And they understood that the real value of assurance wasn't in describing the evidence, but in helping the organisation make better decisions because of it.

Perhaps that's the role many of us are now growing into.

The title may not have changed.

But I think the work already has.