Ady Stokes
Freelance Consultant
He / Him
I am Open to Write, Teach, Speak, Meet at MoTaCon 2026, Podcasting
STEC Certified. MoT Ambassador, speaker, and accessibility advocate. Consulting, training, Leeds meetup host. MoT Certs curator and contributor. Testing wisdom, friendly, jokes, parody songs and poems
Achievements
Certificates
Awarded for:
Passing the exam with a score of 100%
Awarded for:
Achieving 5 or more Community Star badges
Events
Thu, 1 Oct 2026
Previously known as TestBash, MoTaCon is the new name for our annual conference. It's where quality people gather.
Harvest your testing skills at TestBash Autumn, a Ministry of Testing software testing conference happening on the 22nd and 23rd of March 2023
Wed, 20 Sep 2023
This Recruitment Fair evening event is free for everyone to attend, all you need to do is register!
Tue, 19 Sep 2023
Network with fellow community members and TestBash UK attendees at this super awesome Pre-TestBash Meetup
Join other community members in reflecting about all the topics covered at TestBash UK 2023
Contributions
I had solar panels installed this week (October 2025) and had to download an app. What was the very first thing I saw? A test for having multiple call to actions displayed. We can only guess if the...
Based on a discussion earlier in the year (2025) about all the things AI will replace. I pointed out a few things it couldn't replace or do. This image was created so I could share it and prompt so...
Cross-functional pairing is a valuable collaborative technique where two people from different roles or disciplines work together on the same task. It is a way of breaking down the common silos that can arise between teams in a software development process. It allows pairing to go beyond the usual setup of two developers or two testers and get different roles' perspectives working together.A cracking example is an analyst and a tester pairing up to review a set of requirements for a new feature. The analyst brings their deep understanding of the business needs and user goals. The tester, on the other hand, immediately starts thinking about risks, what could go wrong, and what questions need to be answered to test it properly. By collaborating from the start, they can identify ambiguities, logical bugs, and missing information long before a developer writes a single line of code.This sort of collaboration can be used in many other situations as well. You may have a tester and a product manager collaborating to define a user story and its associated acceptance criteria. You could also have a designer and a tester collaborating on a new user interface, with the tester providing early feedback on potential usability bugs or issues that might affect a user's journey. It all comes down to combining different skill sets and perspectives to build a better quality product.
Pairing is a collaborative practice where two people work together, either at a single screen or a shared one if working remotely, tackling one task together. It is a fundamental concept in agile and lean software development. The idea is simply that two heads are better than one, and you get an immediate, continuous code or test review.This practice includes many different kinds of pairings:
Pair programming is a classic example. Two developers work together on the same code. One person, the 'driver', writes the code while the other, the 'navigator', constantly reviews it, thinks ahead, and looks for potential bugs or issues. They swap roles regularly.
Pair testing is just as valuable. This can involve two testers working together, or a tester and a developer. One person actively performs the testing on the keyboard, while the other observes, takes notes, asks questions, and brainstorms new ideas to find bugs.
Cross-functional pairing extends this collaboration to different roles. A great example is an analyst and a tester pairing up to review a set of requirements. The analyst provides the business context, and the tester brings their unique perspective on potential scenarios, edge cases, and missing information, helping to identify ambiguities or problems at the outset.
Ultimately, pairing is about more than just finding bugs. It is a powerful way to share knowledge, improve communication, and ensure high-quality output by getting a second pair of eyes on a problem from the very beginning.
They say "I think therefore I am,"
You just are, there’s no exam.
For my existence, to prove my mind,
Is when I know that I can find.
A bug inside a systems frame,
So critical, it brings me ...
We will STEC you
(Ask to stomp stomp clap)
Buddy your a brand new tester look to find your way in the testing universe
You’ve knowledge to find, expand your mind.
You need to find the pat...
Celebrate the creativity and courage of testers and quality engineers as they share stories, lessons, and ideas in just 99 seconds.
Map your skills, set learning goals, and grow as a testing generalist using the Periodic Table of Testing.
The SDLC is a structured and iterative framework that outlines the entire process of building and maintaining software. It is essentially a roadmap or a plan that takes you from the initial idea for a piece of software all the way to its refinement or removal. Instead of just jumping in and hoping for the best, the SDLC provides a structured approach to ensure everything is done to the best of the team's ability.While there are different versions, most SDLCs include several key stages. It starts with planning, where you figure out the project's scope and goals. Then you move on to gathering and documenting requirements. After that, there's design, where the architecture and user interface are planned. Then you have the actual development or coding. This is followed by testing, where we try to find all the bugs. After deployment, where the software is released, we observe the product's behaviour and provide maintenance, which involves ongoing monitoring, support and updates.For testers, the SDLC is a crucial concept. It's a reminder that testing is not just something you do at the end. A modern approach involves testers interacting right from the very first planning stages to identify risks, prevent problems and catch potential bugs as early as possible. Following a clear SDLC helps teams manage complexity, reduce risk, and produce a higher-quality product in a more predictable way. It’s all about bringing order to the creative chaos of building software.
Developer Experience or DevEx describes how easily developers can go from an idea to running code in production. It focuses on identifying bottlenecks in workflows, including slow builds, failing CI/CD pipelines, unclear documentation, and flaky tests in continuous integration. By removing friction and creating faster feedback loops, developers focus on writing quality software. While it is called developer experience, any improvement should lead to a better overall team experience.Improving DevEx involves automating repetitive tasks (which frees up testers' time for deeper testing), providing clear guides for setting up environments, and integrating CI/CD pipelines that deliver real-time feedback on code health. Imagine a pipeline that flags a typo before you finish your commit or a local setup script that starts containers in seconds. Those small gains add up to shorter lead times and better morale.You can measure DevEx by tracking the time it takes to onboard new team members, even if they are not a developer, measuring build failure rates, and tracking team satisfaction. Each metric can uncover potential hidden blockers and can also show where it might be best to invest for the biggest return. As the experience improves, teams are better positioned to ship features faster, catch bugs early, and deliver higher-quality software.
Hear how the community is discovering new ways to think about quality through SLOs, accessibility, and better listening.
Celebrate the quality community’s creativity and courage as folks share lessons, ideas, and stories in just 99 seconds.