One thing I’ve noticed over the past few weeks is how often conversations about quality eventually come back to definitions.
If two people mean different things when they say “quality”, they’ll build different systems, measure different outcomes and optimise for different behaviours.
This week’s links explore quality operating systems, quality contracts, AI-assisted testing and why agreeing on what we mean by quality may be one of the most valuable engineering conversations we can have.
Latest post from the QE Newsletter
Changeability as a quality attribute of software systems doesn’t get enough attention. It’s usually bundled in with maintainability, but I think it deserves to be called out in its own right.
Changeability isn’t about how easy a change is to make. It’s about how much uncertainty a change creates and how quickly you can reduce that uncertainty. Because it’s in that uncertainty where the risk lives.
A Quality Operating System
Dan Ashby argues that quality is distributed throughout the SDLC and needs a new operating system to manage it.
A simple model for the new quality operating system.
I find it useful to think about this as five layers, mostly because it gives you and your team a shared language for where a given problem actually sits.
What comes in - PRs, stories, behaviours, production signals, AI-generated insights. The raw material.
What connects it - The layer, increasingly AI-driven, that links your tools, agents, and workflows together and turns scattered noise into something that looks like a signal.
What runs it - Your actual test execution, environments, CI/CD, agentic QA workflows doing the work.
What it tells you - Risk clustering, structured testing notes, flaky test detection, coverage intelligence, the compliance evidence you’ll eventually need to produce anyway.
What comes back - Feedback into your PRs, your stories, your dashboards, and ultimately the decisions you’re making as a leader.
For me, this is what quality engineering is all about. Understanding how quality is created, maintained and lost, then deliberately designing systems that help build it in rather than inspect it afterwards.
The five layers Dan describes provide a useful way of thinking about where quality lives inside an engineering organisation. They’re also good places to look when trying to understand why quality is improving, stagnating or slowly drifting away. Via Quality Isn’t an Activity... It’s a System!
The next few articles all tackle the same question from different angles. They aren’t really about testing. They’re asking what quality actually is, and how that answer changes the systems we build around it.
Quality Contracts
Michela shares a story of how a third-party script added to a web page increased load times, eventually causing a 3% drop in bookings. It wasn’t spotted for weeks because nothing had obviously broken.
She describes quality as a contract
A quality contract runs through four stages regardless of what you’re producing.
👉 Intent — define what “good” means before work starts.
👉 Build — create something sound.
👉 Verify — prove it holds under real conditions.
👉 Impact — move something that matters to the customer or the business.
[...] the failure didn’t happen at Impact. It happened at Intent, where nobody defined performance as a success criterion before the script was approved [...]
By the time Impact revealed the problem, the cost of fixing it was orders of magnitude higher than catching it at the start.
The Intent stage really stood out to me because it gets to why defining the quality attributes you care about matters. It gives everyone a shared understanding of what “good” looks like before work begins.
Thinking about quality attributes as a contract changes how I see them. They’re no longer nice-to-haves but commitments the team has made to the business. Like any contract, there are consequences when they’re broken, even if those consequences aren’t immediately obvious. Via Quality is a Contract, Not a Process | Michela Federico
I’m speaking at Hustef in Budapest this October. Check out the lineup, as it looks really good this year.
Help Katja build a new QE foundation
If you believe quality is a testing output, you hire testers and build QA gates. If you believe it is a property of the whole system, you redesign your feedback loops instead.
This feels like an important conversation for our profession.
We still use the same words to describe very different ideas. Until we become clearer about what quality engineering actually is, it’s difficult to build consistent practices around it.
Katja is looking to build those foundations in the open. If that interests you, I’d encourage you to register your interest and join the discussion - I am! Via Should the tester role even exist?
What does quality mean to you?
Hat tip to Katja for linking to this article.
I’ve learned that once I name what a thing is, everything around it tends to get a lot clearer. If you believe quality is a testing output, you hire testers, you build QA gates, and you measure defect escape rates. If you believe quality is a systemic property, you redesign feedback loops, you rethink how teams are structured, and you start measuring deployment confidence and flow instead. Same word, completely different application.
Philosophical clarity sharpens how you think, and it changes what you build.
If there’s one thing I’ve found myself doing over the last 12 years, it’s asking what words actually mean.
People often assume everyone understands terms like quality, testing, risk or engineering in the same way. It’s only once you start digging into those assumptions that you discover people have been talking past each other all along.
As quality engineers, part of our role is making those assumptions visible. Agreeing what we mean by quality is one of the best places to begin. Via Why You Believe What You Believe
Ford replaced engineers with AI... well, not quite
The AI angle is being bolted onto an ordinary restructuring story.
Strip the AI noise away and what’s left is an age-old repeating failure pattern - a company cut costs, the experienced people left, their knowledge left with them, quality suffered, and it paid a premium to rebuild what it had shed.
One thing I’ve become cautious of is headlines claiming companies are replacing engineers with AI.
When you dig into the stories, there’s often a much more familiar explanation. Cost reduction. Restructuring. Capital reallocation. Poor business performance.
As Rob Bowley points out, the Ford story looks much more like an organisation losing experienced people, losing the knowledge they held, then paying the price to rebuild that capability.
It’s a useful reminder to look beyond the headline before drawing conclusions. Sometimes the AI story says more about the narrative than what’s actually happening. Via Ford replaced engineers with AI? Well thats not quite true... | Rob Bowley
Using AI to perform exploratory testing
We can automate exploratory testing, but this only works as well as the structure: charter, risk appetite and heuristics you give the AI. That’s where a skilled quality professional comes in; you need to decide what’s worth exploring, what “good enough” looks like through context and heuristics make for good testing and when to stop. The needs of testing have moved away from using your skills and intuition whilst doing the testing and more towards using them when framing the exploration that needs to happen.
Callum has written a great guide showing how he’s used Claude to automate exploratory testing of websites.
What stood out to me wasn’t that AI can perform exploratory testing. It was that the quality of the exploration still depends on the charter, heuristics, context and risk appetite provided by a human.
That makes me wonder whether we eventually end up with one or two people supporting an entire product area by building and maintaining exploratory testing agents that engineering teams can use during development.
So testing hasn’t disappeared it’s appears to be shifting who actually does it.
Instead of performing the exploration ourselves, we’re increasingly designing the exploration that AI carries out. That changes the skills we need, but not the need for judgement.
Interestingly, you still need someone with domain knowledge and testing expertise to build and improve those agents. The question is whether that person necessarily needs to be called a tester. Via Mastering AI-Driven Exploratory Testing for Quality Engineering
Past Linky
Linky #34: The system around the output
This week’s links are mostly about the system around the output.
Linky #33: The stewardship problem
This week’s links made me think less about whether AI can help us create more software, and more about what happens after that software exists.
Linky #32 - The practice is not the principle
This week’s links had me thinking about something that is foundational to a lot of quality engineering work:
