Quality Was Never Everyone’s Job

Requirements, traceability, and why quality engineering matters more than ever in the age of AI

What is quality assurance and quality engineering?

Quality assurance (QA) is the discipline of making sure a product does what it is supposed to do, for the people it is supposed to serve, in a way we can prove. Quality engineering (QE) is the modern evolution of that idea: instead of only checking the product at the end, it builds the practices, tooling and feedback loops that make quality measurable throughout the lifecycle.

Notice the key phrase: what it is supposed to do. Quality is always measured against something. Without a defined expectation there is nothing to verify, only opinions. That single point is the foundation of everything below.

Why it matters

Software is no longer a side tool. It runs payments, healthcare, logistics and every customer relationship we have. A defect is not just a bug on a board; it is lost revenue, lost trust, and sometimes real harm. Quality is what turns “we shipped it” into “we can stand behind it.”

The classic triangle of Quality, Cost and Time describes the trade-off every project faces. For years, the industry quietly resolved that triangle by sacrificing quality and calling it speed. That was always a false saving, and we are now paying the bill.

What happened since the Agile Manifesto

Let me be clear: Agile itself was not the villain. Its original ideas, short feedback loops, collaboration, adapting to change, were healthy. But as it spread and was reinterpreted, a few damaging habits took root.

Requirements got lost. “Working software over comprehensive documentation” was heard as “documentation is optional.” Requirements became scattered user stories, chat threads and verbal agreements. Nobody could say with confidence what the system was supposed to do.

Everyone owns quality, which meant no one did. Instead of a structured way of assigning responsibility, we got the slogan that quality is the whole team’s job. In theory that sounds beautiful. In practice, shared ownership without defined roles, skills and accountability became ownership by nobody. Quality was not murdered by one person; everyone has a bit of its blood on their hands.

The source of truth disappeared. Every team has someone who claims to hold it. But the documents are outdated, the architecture diagrams describe a system that no longer exists, and even the comments inside the code lie. When everything might be wrong, nothing can be trusted.

Old principles were rebranded. The fundamentals of quality assurance have been written down since the earliest ISTQB syllabi: test early, trace tests to requirements, assess risk, measure coverage. Over the years they were repackaged with new names, “shift left” being the most famous. The idea is sound, but it is a re-labelling of principles we already had, and the new label often arrived without the discipline behind it.

The “saved” cost was an illusion. Agile was often sold as a way to cut cost by cutting quality overhead. In reality, the time lost to unclear, untracked requirements exceeded what was gained. Teams re-discover intent, re-argue decisions and re-test things nobody remembers the reason for. And people leave. Every time someone joins or exits a team or an organization, knowledge walks out of the door, because it was never written anywhere that mattered.

Documentation became the lowest priority. In the middle of chasing deadlines, tracking and documentation are the first things dropped. For most engineers they sit at the very bottom of the list. And that is precisely the thing quality depends on.

Why AI makes this urgent

AI is now entering every phase of the software development lifecycle: generating requirements, writing code, producing tests, reviewing pull requests. Code can be produced faster than at any point in history.

That changes the triangle. Time is no longer the constraint. When generation is cheap, the scarce resource is confidence: knowing that what was generated is correct, complete and aligned with what the business actually wanted. Fast, plausible, wrong output at scale is more dangerous than slow, careful output.

And AI has the same dependency humans do: it needs a source of truth. Ask a model to generate tests or code against vague, outdated or contradictory requirements and you get vague, outdated or contradictory results, only faster. We need quality more than ever, and quality needs a ground to stand on.

The one thing that helps QE: a source of truth

The most valuable thing you can give a quality engineer is not a new tool or a new framework. It is structured, tracked, current requirements they can refer to.

With that, the daily work of QE becomes systematic instead of heroic. With every new release:

• Added requirements tell you which new test cases to write.
• Modified requirements tell you which existing test cases must be updated.
• Removed requirements tell you which test cases to delete, or at least mark as obsolete.

Without structured tracking, none of this is possible. Test suites rot, grow endlessly, or quietly stop testing what matters, and nobody can tell which.

What traceability gives you

Once requirements are structured, you can establish traceability between requirements and test cases. And from that, a lot follows:

1. Measurable coverage. Not “we have 3,000 tests,” but “these requirements are covered, and these are not.”
2. Risk-based priority. You can see which tests are bound to the most critical features of the system, and make sure those are protected first.
3. Meaningful failures. When a test fails, you know which requirement is affected and at what priority, instead of just seeing a red build.
4. Release confidence. Go/no-go decisions stop being gut feelings. They become evidence: what passed, what failed, and what that means for the business.
5. Informed defect triage. When something looks like a defect, developers and testers can open the same referenced requirement and decide together whether the code is wrong, the test is wrong, or the requirement itself has changed. The argument moves from opinion to fact.

Documentation is not a luxury

It is tempting to treat requirements documentation and tracking as bureaucracy, something nice to have when there is time. There is never time, so it never happens, and then quality quietly erodes.

But this is the point worth repeating: documenting and tracking requirements is not a luxury for producing quality software. It is the ground the whole thing is built on. Quality is a comparison between what we built and what we intended. If the intention is not written down, kept current and traceable, there is nothing to compare against, and no amount of testing, automation or AI can fix that.

If we want to ship with confidence in an AI-accelerated world, the path is not complicated. Restore a source of truth. Assign real responsibility for quality. Trace tests to requirements. Then let everyone, humans and machines, move fast on solid ground.