Testing Flashcards (Updated)

For a few years now I have been posting quality flashcards on LinkedIn, usually one at a time and usually because something had come up in my way that I thought was useful to share with others. Here they all are in one place, rebuilt and updated for 2026 using my latest branding and sorted into four packs covering risk, AI, the craft of quality engineering and the people part of the job.

Feel free to download the cards to use as training material with your team or stick them somewhere you will actually see them as a reminder of the topics that matter. On most of the cards the left hand column is what we want to avoid… the right hand column is what I would do instead.

01. Quality Risk

Ten cards on finding, sizing and owning risk to quality. Where do the risks actually come from, who gets to decide how much risk is acceptable and what can a piece of testing honestly tell you about any of it?

Further reading

Start with the risks, not the method | Why did testing miss this… Because you didn’t set a risk appetite | 100% Tested is not 100% Covered | Not having an Approach causes Problems in Your Testing | Testing Doesn’t Just Happen at the End | Is it really an edge case?


02. AI Hygiene

Seven cards on getting useful work out of AI so that it helps you build better rather than just faster. Prompting deeply enough to be understood, keeping your context fresh, setting the boundaries before an agent starts work and knowing which quality signals are worth watching once delivery picks up pace (I was a sceptic about all this, the old posts are still up to prove it).

Further reading

I was an AI sceptic (and I’ve got the old blog posts to prove it) | Yes you can run exploratory testing with AI | AI readiness radar: Framework for engineering teams | Change Failure Rate and AI Adoption: What Your DORA Dashboard Misses | Quality Engineering with AI | Creating a Playwright framework with AI | Using AI to help teams shift testing left


03. Quality Engineering

Nine cards on the craft itself. What does being technical really mean for a quality specialist, how do we decide what is worth testing and where is the line between confirming what we already know and going to find out what we do not?

Further reading

14 Ways testers can be technical without writing code | Why adhoc testing is not exploratory testing | Setting your own Testing Scope to Work With Uncertainty | In testing context is important | You’re not ready for Quality Engineering | You don’t need so many E2E tests (or do you?) | A Beginners Guide to API Testing


04. Influence

Nine cards on the people part of the job, which is the bit nobody really trains us for. Getting quality owned by a whole team rather than one person, having an opinion that teams actually want to hear and building influence that reaches further than your own squad.

Further reading

Want to be a better Quality Engineer: Lose the Ego | Testers have to be the ones to advocate for quality | Being a good senior tester means having an opinion | Hiring a first QA into a startup: Why you need a senior | How to identify the right senior tester for your new Team / Company | How to Involve Developers in Exploratory Testing | Slow burn: Changing things takes time | Quality Coaching Scenario: No testing happening

Thanks for reading. If this resonated (or if you think that I’ve got it wrong) there’s more to read on the blog… or get in touch via LinkedIn. I’ll talk quality to anyone who wants to listen!

Discover more from Callum Akehurst-Ryan's Testing Blog

Subscribe now to keep reading and get access to the full archive.

Continue reading