Honoring #IconsOfQuality: Ash Winter

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.

Ash Winter is a community-focused tester and coach who currently serves as a Senior Quality Engineer at the John Lewis Partnership. With a rich background operating at the Principal level for companies like Yepic and Sky Betting & Gaming, Ash is dedicated to raising the profile of testing and helping development teams deliver software with known quality at speed. Co-author of the influential Team Guide to Software Testability and co-organiser of the Leeds Testing Atelier, Ash actively fosters collaboration within the testing community. As an expert exploratory tester and an AI enthusiast, he leverages modern tooling—from automation pipelines to LLMs—to enhance a tester's capabilities. Through his training, writing, and international speaking engagements, Ash leads by example, proving that testing is ultimately a highly collaborative team effort.

We spoke with Ash about democratizing testability, using AI to extend a tester's senses, and why becoming technically aware is the best career move you can make.

---

One of the reasons I’ve been a tester for a long time is the variety of the work. Performance, security, accessibility, exploratory testing and so much more, you can keep the work fresh and learn so much. I think I would split this question into two:

• The Classics - exploring a system, finding a great bug, being part of a story kick off, designing tests with a developer, being part of a development team, meeting other testers who are passionate about the craft. They are the core of being a great tester, think very carefully before using an LLM in these activities. Keep yourself sharp, as I think you need to love these classics to have a fruitful career in testing, especially in the long term.
• The Unknowns - I'm old enough to remember when agile first came along and test teams were broken up and we found ourselves alone on development teams. Or DevOps, when test environments, build automation and monitoring changed how and where we can test forever. There was pain and upheaval, but significant positives too. The community that testers naturally form became even stronger and we could test early and often, both as the code was being developed, enhanced by better knowledge of our production environments. AI in testing will follow a similar path of change, but I’m comfortable with not knowing exactly where we will end up, but that’s the exciting part!

I’ve spent quite a lot of my career advocating for developers to make the systems I test easier to test. When it’s easier to test, more people want to get involved in testing and you’re a long way towards the team testing culture that you want.

Coding assistants have democratised this even further. Just today, I used CoPilot to create a docker-compose which stood up a local environment with one command, a webhook which allowed me to post messages to a queue and much more. If I have an idea of how to make something more testable, I can act on it, build a prototype quickly, then share it with the team and get their feedback.

I want to enable as many team members as I can to take part in the testing effort and I think LLMs have the potential to make this mission possible.

AI in testing is talked about way too broadly. Like with all very broad topics, if you don’t know what you want, it will overwhelm you.

I know what I want. I want AI to extend my senses as a tester. An agent that can dip into the logs, tell me how a database has changed, what messages were added to a queue, what metrics did the system generate, all while I test, or when automated tests are running. How to achieve that? I’m working on it.

Using AI in testing is a vast statement, you need to get more specific with what you want. Otherwise you will just drown in the amount of tools, frameworks and content out there. Choose a starting point (anything, say, Evals) and go from there. As you research, the foundational knowledge will come.

On the subject of Evals, I was reading about them the other day and I thought, ‘you’ve just invented testing’ again. It made me laugh a little to be honest, but it also shows that testers have a lot to offer in testing AI based systems.

I have so many, I always find it so hard to choose. Don’t be ashamed to do your ISTQB Foundation, it's got loads of test techniques that you need to know. Setting up your first browser automation test is cool and you are cool too for doing it!

However, if I had to settle on one piece of advice, it would be to become more technically aware. I would split this into three parts:

• Look Behind the Interface - pick a tool to explore HTTP APIs with and become proficient in it. Postman, Bruno, whatever it is, doesn’t matter. You need to explore behind the interface, it will open up lots of options. A mocking tool isn’t a bad idea either, WireMock has always been a favourite of mine.
• Learn Source Control - learn how to use Git, from the command line or within a client. This inevitably brings you closer to the systems you test and how they are developed and deployed. And of course, the developers that work on them.
• Review Architectures - look at your architecture diagram and note down what you don’t understand, areas where it might fail, dependencies that other teams control. Practice this skill, offer to do it for other systems. The list of things you don’t understand will be long at first but even asking to see the architecture will make you some friends!

I think it’s important to get your news from a diverse range of sources, so I try and keep an eye on a few, but not too many that I feel overwhelmed:

• Ministry of Testing is an obvious choice for curated testing news and has been a go-to of mine for many years. It also evolves and experiments with how to provide engaging content from a wide range of people, just gets better and better for me.
• I’m also on the Association for Software Testing mailing list as well, after speaking at CAST a few years ago. They are especially generous towards the peer conference community which has always been close to my heart.
• I think you should also keep a little bit of room for testing adjacent sources as well, tailored somewhat to my interests. The first is the ThoughtWorks Tech Radar, which gives a wide view of new technology including testing tools and practices. The other is the InfoQ weekly digest, which covers AI and Architecture, as well as organisational culture and methods.

From this range if a new trend or tool catches my attention, I’ll dive deeper from there.

So much! There are certain truths that only become obvious over time, even if you had told me, I would have needed to experience them to truly understand.

My first testing job involved a system of some complexity, in truth more than I could handle but I was looking to prove myself. I found loads of bugs, tons and tons of them. However, I didn’t find the most important ones. The quantity of testing I did was high, but the quality of it was poor. I should have consulted more widely than I did with people who knew more than me about the domain, but I thought I could do it on my own. This was a mistake and a hard lesson to learn. Don’t test alone, by its nature, testing is a team effort.

Some more I would add:

• Have a good enough relationship with a developer that they will give you an early look at what they are building.
• Don’t say you’ve tested something when you haven’t. Just tell one person if it’s embarrassing.
• Try not to automate what the system already does but test for what it needs to do.
• All decisions are made based on the best information and judgement available at the time. Even if it looks ludicrous in hindsight.

The last one really did take me a long time to learn and quite a lot of stress. Things are the way they are because they got that way. Everyone did their best.

I love to run, I’ve run more races than I can count, all the way up to mountain marathons. I’m a member of our local running club and even helped out with modernising their website this year. As soon as I let slip that I worked in software development, I felt compelled to volunteer. It was a great experience though, having direct access to my customers was a welcome change.

The thing I love most about running though, is being able to spend time outdoors, especially while working remotely. Time to think (or not), ponder ideas or just to get away from the desk for a while, all helps to keep me grounded. While also helping to keep me healthy. Apart from when I get carried away and injure myself! I see more and more of my physiotherapist as I get older…

(Responses may have been edited for clarity.)

---

Ash’s insights underline a profound truth in quality engineering: testing is intrinsically a team sport. By advocating for testability and leveraging modern tools to extend a tester's senses, he exemplifies a modern quality leader who bridges the gap between development and testing. His commitment to coaching and community ensures the craft continues to evolve and thrive.