Ady Stokes
Ady Stokes
IT and Accessibility Consultant
He / Him
I am Open to Write, Teach, Speak
Speaker, teacher and MoT Ambassador. I offer consulting services as well as running the Leeds MoT meetup. I teach, coach, and give training. Essentials Certificate Curator and contributor.

Achievements

Career Champion
Club Explorer
Bio Builder
Avid Reader
TestBash Trailblazer
Article Maven
Testing Scholar
MoT Community Certificate
Scholarship Hero
Trend Spotter Bronze
TestBash Speaker
99 Second Speaker
The Testing Planet Contributor
Meetup Organiser
MoT Streak
Unlimited Member
In the Loop
MoT Ambassador
MoT Inked
Bug Finder
Collection Curator
Glossary Contributor
Meme Maker
Photo Historian
TestBash Brighton 2025 Attendee
TestBash Brighton 2024 Attendee
Cert Shaper

Contributions

The one page test plan image
  • Claire Reckless's profile
  • Ady Stokes's profile
Create concise test plans that get read and understood by busy people
Hello, my name is Ady Stokes  image
  • Ady Stokes's profile
  • Scott Kenyon's profile
About Me: I’m coming from: near Leeds in West Yorkshire, UK My role is: freelance IT and accessibility consultant I’d love to meet others who are into: accessibility, quality engineering, teach...
Requirements traceability image
  • Ady Stokes's profile
Requirements Traceability, or just traceability, is all about establishing and maintaining a documented link between a requirement or a specific feature and its journey through the software development process. Think of it as creating an audit trail or a connected thread for each requirement, from its initial idea right through to the code that implements it and then the tests that verify it. The point of the exercise is to answer some potentially crucial questions. For instance, if a bug pops up, can you quickly see which requirement it impacts? If a requirement changes, what code needs to be updated, and which tests need to be re-run or adjusted? It looks to ensure that every part of the system can be traced back to a specific requirement, and equally, that every requirement is actually being addressed somewhere in the software. Think of it as knowing your coverage. This process can involve linking requirements to design specifications, to individual code components, to test cases, and even to the bugs we find along the way. When it is done well, it gives us a clear picture of coverage, helps us manage changes effectively, and makes root cause analysis of bugs a potentially much easier job. It is about understanding the "why" and the "what" behind every piece of the software puzzle, giving everyone on the team, especially us testers, the clarity we need. It can, however, take a lot of time and cost to maintain, so using requirements traceability, or just traceability, will be very context-dependent.
European Accessibility Act (EAA): Article 32, and why it sucks! image
Artcile 32 of the EAA is a get out of jail card, for up to 5 years, for companies who want to 'avoid' their responsibilites to their users. And yes, it sucks!
Kanban board image
  • Ady Stokes's profile
A Kanban Board can be a powerful tool. Its origins come from Lean principles, and are designed to visualise your workflow. At its heart, it is a visual representation of your process, typically using columns to represent different stages of work (like; "To Do," "In Progress," "Waiting for Review," and "Done"). Cards represent individual work items or tasks. The core idea is to see where everything stands at a glance. You might hear talk of "visual boards" or "task boards," and while a Kanban Board is certainly both of those, it has some crucial distinctions. Visual Board: Think of a visual board as the umbrella term. Any board, be it physical or digital, that helps you see things visually could be called a visual board. A mood board is a visual board. A holiday countdown chart is a visual board. A Kanban Board is a visual board, but it has a specific purpose and principles that make it more than just a picture.  Task Board: A task board is generally for tracking individual tasks, often very simply. You might have your typical "To Do - Doing - Done" columns. You move tasks along as they progress. While a Kanban Board certainly tracks tasks, its key difference lies in its adherence to specific Kanban principles.  What makes a Kanban Board a 'real' Kanban Board is the application of those principles. The most important one is limiting Work In Progress (WIP). This means you deliberately put a cap on how many items can be in a particular column at any one time. This is not just a suggestion; it is a fundamental rule that helps prevent bottlenecks, encourages collaboration, and ensures work is finished before too much new work is started. It focuses on flow. Other principles include explicitly outlining the policies for moving work, much like definitions of done, but for columns, continually improving the process, and managing the flow of work items through the system. So, while a sticky-note covered whiteboard might be a visual board or even a simple task board, it only becomes a Kanban Board when you start applying those specific principles, particularly the WIP limits, to truly optimise your workflow. It is about actively managing the flow and spotting where things get stuck, helping teams deliver value more smoothly.
How to get unstuck: A guide for testers or anyone else who feels stumped  image
  • Ady Stokes's profile
Learn about some of the reasons we get stuck and some top tips for getting unstuck
Chaos theory image
  • Ady Stokes's profile
Chaos theory is a technique used in software testing and development to evaluate the resilience of a system or to carry out random tasks and actions. It can also be described as using small changes to understand their outcomes. Related to the butterfly effect, which says a butterfly’s wings when flying could cause storms across the world. Chaos theory looks at the possibility that a minor config file change could bring a system down. Remember the huge Crowdstrike incident in July 2024? A small change resulted in a global IT outage.
Decision fatigue image
  • Ady Stokes's profile
Decision Fatigue is a state of mental exhaustion that creeps in when you have had to make too many choices, big or small, over a prolonged period. Our brains have a finite capacity for making good decisions each day. Every choice, from what to test next to whether that tiny bit of weirdness is a genuine bug or not, slowly saps that energy. In software testing, we are bombarded with decisions constantly. Think about it. What test paths or customer journeys to explore. How to best report and explain a bug report. Deciding on severity. Figuring out all the steps to reproduce. Choosing which tool to use for a particular check, or even just prioritising our own workload. They all add up to drain our energy and, at varying levels, wear us down. You may have heard of executive dysfunction, which refers to being unable to make decisions like planning, organising, and initiating tasks. Decision fatigue is not exactly the same as executive dysfunction, but it can certainly mimic it or even make it worse. When your brain is worn out from decision-making, you find it harder to get things done. Your prioritisation skills dip, and just getting started on a task can feel like wading through treacle. It is a genuine cognitive drain that affects everyone at every level. The impact? You might find yourself making poorer choices, procrastinating more, becoming more irritable, or simply feeling overwhelmed by tasks that would normally seem straightforward. Recognising decision fatigue is the first step, so we can then think about how to reduce that mental load and keep our minds sharp for the important decisions. It is about protecting our mental capacity to do our best work.
MoT Leeds meetup May - Accessibility Testing live image
  • Ady Stokes's profile
  • Scott Kenyon's profile
Hosted by Accenture the latest Leeds event was accessibility themed to support GAAD, Global Accessibility Awareness Day which was on the 15th. Ady Stokes worked through simple tests every teste...
Quality Blether - Ady Stokes Accessiblity  image
  • Ady Stokes's profile
  • Bryan Jones's profile
Ady Stoke chats to Bryan Jones on the Quality Blether podcast
Login or sign up to create your own MoT page.
Subscribe to our newsletter
We'll keep you up to date on all the testing trends.