Leeds Testing Atelier 2025

This one's a little late but life has been ridiculously hectic over the last while. It's been about 3 months since I last managed to post anything on here. Will hopefully be posting more soon. Onto the content!

The Leeds Testing Atelier is one of the highlights of my professional calendar. The event has been held at Wharf Chambers for many years and had a very punk, DIY feel, but this year it moved over to The Tetley, which is a well-known, iconic venue in Leeds city centre. It attracts folks from all over the software engineering spectrum with a diverse lineup featuring many well-respected names talking on a variety of subjects. I managed to attend 7 talks in total, covering a broad variety of topics, and left with some valuable learnings I can integrate into my daily development practices.

Talk 1: Subcutaneous Testing - Costa Giannakopoulos

Costa's talk takes us through the idea of subcutaneous testing, first described by Martin Fowler back in 2011 here: https://martinfowler.com/bliki/SubcutaneousTest.html

We all know that UI-based tests have their drawbacks - they can be slow, flaky and expensive. The idea is that end-to-end testing via the frontend can be difficult, and suggests that using the backend directly is the way to go, getting "just under the skin" of the application, following user journeys and flows as closely as you can. However, Costa warns us "Don't get too bogged down with the internals", reminding us that these tests are still black-box tests, and want to focus on behaviours, not implementation details. One of my favourite points he makes is that he emphasises designing your tests thoughtfully through all levels to reduce duplication.

To demonstrate the value of these tests and get buy-in, he went through the PoC process with a proven example - taking a UI test which took over 3 minutes to run in Playwright and converting it to a subcutaneous test which took 21 seconds to run, a huge improvement! His tool of choice was PactumJS, a versatile API testing tool which supports different levels of testing, like E2E/component/contract.

This test philosophy is actually something we've been exploring in our team, where I've been building up an API test regression pack using the existing Postman tests as a jump off point. It left me excited to build out that test project to cover more complete end-to-end journeys. 

Talk 2: The Good, The Right, And The Fitting: Moral Philosophy In Software Testing - Chris Briggs

Chris walked us through several moral frameworks and how they might help us think more intentionally about the work we do in the quality space. 

Three such models are as follows:

• Utilitarian Ethics: "If you can't do good, at least do less wrong"
• Kantian Ethics: principle-based, focusing on rules and rights rather than outcomes
• Virtue Ethics: based in character and conscience, offering more flexibility and humanity in decision making

This wasn’t just abstract navel-gazing either, as Chris described practical ways we can integrate ethical thinking into our ways of working. He encouraged us to define values and set ethical intentions early on, like during a pre-mortem in the design phase or by embedding ethical considerations into our team’s Definition of Ready/Done. I came away thinking a lot about the invisible trade-offs we make in delivery and the impact of these decisions on each other, our stakeholders and our customers.

Talk 3: Psychological safety: The link between speaking up, complexity and high performing teams - Jit Gosai

Jit spoke about psychological safety in teams, and how it creates the conditions for people to take risks, speak up, and ultimately do better work.

He shared a great story about a NASA engineer who owned up to a mistake in a post-mortem session following an incident. Instead of being punished, they were thanked and sent a bottle of champagne. That kind of culture, where honesty is rewarded rather than punished, is what psychological safety is all about.

Jit broke down the idea that psychological safety means people feel safe taking interpersonal risks - things that could potentially make you look incompetent, disruptive or ignorant. This could be anything from speaking up, admitting you don’t know something or challenging a plan. These uncomfortable actions can cause friction, but are necessary for teams to produce their best output. 

He pointed out that leadership is the biggest factor in creating (or damaging) psychological safety, but reminded us that leadership doesn’t just mean a job title. We can all take steps to create that kind of culture, by showing empathy, admitting mistakes, and supporting others when they do the same. His closing point stuck with me: higher-performing teams tend to be the ones taking more risks, and that only happens when it feels safe to try.

Talk 4: Testing In The Dark: Life As A Research Software Engineer - Sorrel Harriett

Sorrel introduced us to the life of a Research Software Engineer - someone who combines professional software expertise with an understanding of research and can bridge the gap between academia and business. The role sits somewhere between developer, consultant, and support desk, often helping researchers bring their ideas to life (or, more realistically, helping them wrangle inherited codebases into something vaguely functional).

One example she gave was equal parts funny and horrifying. A PhD student on a project called BOG-105 (fitting, because it was about bacteria found in the 🚽) submitted a ticket with a copy-pasted Python script they inherited from their supervisor, asking if it could be made "faster." The script was incomprehensible, had no version control, no tests, and no documentation. When faced with this situation, it can be tempting to want to rewrite the whole thing from scratch. But Sorrel found that the found that the better approach was to meet people where they are, offer support, and improve things gradually. 

She talked about recognising the zones people work in (comfort, struggle, and panic) and how important it is not to shove someone into panic when you’re trying to help them learn. She left us with some solid reminders: talk to people, try not to reinvent the wheel, and resist the urge to rewrite everything just because it doesn’t meet your own personal standards. Sometimes your job is just to get it over the line without breaking anything (or anyone!)

Talk 5: From Gatekeepers to Coaches: Evolving the QA Role in Agile Teams - Kat Obring 

This talk took us on a journey through the tester identity crisis that many Quality Engineers have lived through. It started with the classic gatekeeper of quality mindset, being the trusted line of defense against bugs reaching customers. But as Agile rolled in, that model started to fall apart. The same gatekeepers were now causing frustration, bottlenecks in delivery and reduced collaboration.

The heart of the talk was about moving from that defensive posture into something more collaborative and empowering. Instead of guarding quality alone, testers can become coaches, helping the whole team own it together. Kat laid out some practical ways to do this, like:

• Running short pair testing sessions where you narrate your thought process and testing instincts out loud
• Facilitating test planning workshops that prioritise risk areas and business impact 
• Holding retros that focus on quality issues, using tools like “5 Whys” to dig into root causes without blaming individuals

There was also a brief dig into meaningful metrics, suggesting that we track things like reduced late-stage bugs or improved collaboration, rather than just arbitrary code coverage. One of my favourite takeaways was that small changes can be just as meaningful. Start small. Help one person think differently about quality. Shift the culture one conversation at a time.

Talk 6: Why Testers are the True Rock Stars of IT - Bryan Jones

This one had actual guitar riffs. It was a fun, high-energy talk that leaned into the rockstar metaphor to celebrate the unique skillset testers bring to the table. Testers aren’t the lead guitarists, he told us, they’re the bassists. They might not always be front and centre and are frequently undervalued, but a good tester supports the whole team and holds everything together. 

The talk touched on the many useful skills testers bring to the table:

• Critical thinking
• Curiosity
• Systems thinking
• Modelling
• Communication and negotiation
• Technical fluency

The core message of the talk was that testers don’t have to be flashy to be essential and that they have many skills which might get overlooked. It was fun to be reminded of this while he shredded away at a guitar solo! 

Talk 7: Practical Prompting: Using AI To Support Testing And Quality Engineering - Steve Mellor

Steve’s talk was a solid, pragmatic dive into how AI tools like LLMs can actually help people perform testing tasks, free from marketing spiel. He focused on giving practical advice on how to write better prompts and get useful results.

He walked us through a few helpful frameworks for structuring prompts, including:

• Chain of Thought: walk the model through your reasoning with intermediate steps
• Role, Task and Format: good for framing the output in a specific way
• Context, Action, Result, Expectation: great for test scenarios
• Role, Input, Steps and Expectation: good for framing from a specific perspective

The biggest takeaway for me was that good prompting is a skill like anything else. The more context you give, such as preconditions, constraints and example outputs, the more useful and consistent the results. He pointed out that you should avoid negative statements in prompts (e.g. “don’t do X”) as models can misinterpret or ignore them.

Steve also touched on real use cases where AI can shine:

• Analysing user stories
• Generating test cases
• Creating sample data
• Identifying UI elements
• Generating boilerplate code

Tools like LM Studio and Continue.dev came up as ways to work with local models or integrate LLMs into your workflow safely. Used correctly, these tools can amplify productivity and help us take on more complex challenges with the time we save not doing menial tasks. 

Concluding thoughts

As someone with a background in QA engineering, it’s important to me to remain connected to the testing community, and this event certainly delivered. Once again, I came away from the Testing Atelier excited to see what the future holds for the discipline. Massive thanks to the organisers, speakers, and everyone who made the day feel so welcoming. I’m already looking forward to next year.