Honoring #IconsOfQuality: Richard Bradshaw

To celebrate the relentless passion and invaluable contributions of leaders in software quality, BrowserStack is proud to honour some of the icons in the testing space. These are the visionaries who not only push the industry forward with their expertise but also enrich the entire testing community by generously sharing their knowledge and thought leadership.

Richard Bradshaw, widely known across the community as FriendlyTester, is a true driving force in the software testing domain. Currently a Senior Architect in Quality Engineering at Slalom Build and the former CEO of the Ministry of Testing, Richard's work has impacted thousands of professionals globally. Whether he's co-hosting The Vernon Richard Show, strategizing, or co-creating the "Automation in Testing" (AiT) namespace, Richard advocates for human-centric automation that adds immediate value without disrupting existing efforts. With a deep focus on a whole-team approach to quality, he champions the idea that testing must adapt to its context, allowing teams to move efficiently and confidently.

We spoke with Richard about the probabilistic nature of AI agents, why problem-solving is at the heart of engineering, and how testing is ultimately about gathering information to make informed decisions.

---

It will always be solving complex problems. Whether that's building the solution, testing the solution, or focusing more broadly on how we solve a problem. Problem solving, for me, is at the heart of software engineering, and the messier and more chaotic the problem, the better.

It has to be AI agents. A well-designed agent can provide a huge amount of value and give an engineer superpowers. A badly designed agent can give you an endless list of problems to focus on. The probabilistic nature of them lures me in.

For years, testing has often been framed around expected inputs and outputs: does X produce Y? AI systems have completely disrupted that model. Now we’re dealing with probabilistic behaviour, subjective quality, multiple acceptable answers, and systems where defining "correct" or even "good enough" can be incredibly difficult.

That means we need much richer ways of thinking about quality: evals, telemetry, LLM-as-a-judge, human evaluation, statistical measures, production feedback and continuous experimentation. Being able to explain your heuristics and oracles is a superpower when working with AI. Or, put another way, a hybrid of QA, QE, Testing and Engineering.

AI is going to replace many testers, because it's going to do a lot more of the testing work. If your value is primarily writing test cases, converting requirements into scripts, generating automation code or executing predictable checks, AI is going to do an increasing amount of that work.

But those people need to realise that the real value they provided was never the artefacts. It was their ability to apply critical thinking, solve problems, identify risks, design experiments, question assumptions and make judgement calls.

Those skills are in more demand than ever. I just don't think they'll necessarily map to a role called "tester" in the future. I think we're moving towards something much more hybrid: part developer, part tester, part quality engineer, and probably a few things we haven't named yet.

Don’t become too attached to the word "tester". Become someone who is exceptionally good at understanding how software might fail, why that matters, and how we can learn about it quickly.

Learn programming. Learn how systems are built. Understand APIs and system architecture. Focus on observability, telemetry and monitoring. Learn how to use all that data to answer your testing and quality questions. Get comfortable using AI. Understand its strengths and its pitfalls, and continually adapt how you use it.

But don’t lose the curiosity and critical thinking that brought you into testing in the first place. Tools and job titles will change repeatedly during your career, but your ability to ask good questions will remain valuable no matter the role.

Increasingly, I don’t try to. There’s simply too much happening now, particularly with AI. Trying to follow every new tool, framework and model is exhausting and feels impossible. Instead, I try to understand the underlying ideas and core concepts.

I build things. I experiment. I try things. I read what interesting people are doing. I talk to practitioners. And when something looks genuinely useful, I get hands-on with it. In my opinion, there is no substitute for actually getting hands-on.

That last part is important. I’ve always learned far more by trying to solve a problem myself than by reading twenty posts about how other people solved it and which tools they used.

Being part of communities and networks has also been hugely important throughout my career. Some of my best learning has come from conversations, conferences, workshops, and people challenging the way I think. They also give you a centralised place to go to when you have the time to explore new things.

That testing isn’t really about finding bugs or passing tests. It's about information: gathering knowledge, challenging and validating that knowledge, and then using it to help the business make informed decisions.

I spent a lot of my early career thinking about test cases, automation, coverage and techniques. They’re useful, but eventually you realise the difficult questions are things like:

• What are we actually worried about?
• Who could this affect?
• What don't we know?
• What evidence would make us comfortable releasing this?
• And perhaps most importantly: what does good enough look like?

I also wish I’d understood earlier that automation is about rapid feedback, not replacing humans. I’ve spent a good chunk of my career teaching automation, and the longer I’ve done it, the less interested I’ve become in how many automated tests someone has and the more interested I’ve become in whether those tests are actually helping people make better decisions — and make them at pace.

I love building things and DIY. I've recently landscaped a large part of my garden, and I have a habit of starting a project with "how hard can this be?" and then finding myself learning about drainage, retaining walls, electrics, woodworking or whatever else the project unexpectedly requires.

I think what I enjoy is starting with something I don't completely know how to do, figuring it out, making mistakes, solving the problems as they appear, and eventually having something physical to show for it.

So apparently even my hobbies involve problem solving. I may have a problem.

(Responses may have been edited for clarity.)

---

Richard’s journey highlights that at its core, software testing is about curiosity, critical thinking, and relentless problem-solving. He exemplifies a modern quality leader, one who embraces shifting landscapes while staying grounded in the fundamental goal of delivering valuable information to teams.