Quality in software development is no longer the job of a single test phase. It belongs to the whole team and takes shape when product owners, developers and testers agree on what quality means for their product. Testing AI systems makes the gap visible: the classic quality criteria fall short, and the question “What is quality, actually?” often goes unanswered.
Key Takeaways
- Agile development pulled software quality out of its niche: where regression testing used to happen every few months, two-week sprints demand continuous quality work from the whole team.
- Quality is now a shared task. Product owners, business analysts, UX designers and developers think it through together, not just the testers.
- AI-based testing tools help with reviewing requirements and deriving test ideas, but they need a level of organizational maturity that many teams haven’t reached yet.
- Testing AI systems raises a basic question that should have been settled long ago: what does quality mean for this product, and when is it good enough?
How Quality in Software Development Came Up from the Basement
For years, software quality was a side topic, tucked away in windowless test rooms full of retired PCs. Today, quality in software development sits on every team’s desk, every day. That shift over the past 20-odd years has changed the profession from the ground up.
In the classic model, testing waited for development to finish. You wrote a handful of test cases in advance, ran them, reported the defects back and then had weeks of quiet. Quality was a step at the end of the line, not something the team did together.
Those days are gone, and for a concrete reason: software is everywhere now, including the business applications that used to count as mere tools. People expect software to work, across the board. When a Windows update ships without proper testing, it takes no time at all to see how much depends on it.
Why Agile Gave Testing a Boost
Agile development moved quality and testing to the front because the old habit of waiting simply stopped working. Iterations, sprints and constant regression testing forced teams to organize quality in a new way.
What used to be checked every few months suddenly had to run every two weeks. For testers and QA people, that was a hard change. The first reflex was the mini-waterfall: two days of hurried testing at the end of the sprint, and a single bug could wreck the whole iteration.
Out of that pain came a better practice. Teams now look at quality as a whole instead of treating it as one role’s specialty. In refinement and planning, everyone thinks it through together. Where could we test what? Which test level makes sense for which check?
One big gain: you stop testing everything twice. Instead of repeating each case from unit and integration tests all the way up to acceptance tests, you know which tests run at which level. The business side moves closer and builds trust in what’s happening.
As early as 2003, one claim was that agile means quality. The pushback was fierce, because many people confused agile with “we don’t have to document anything anymore.” Practice proved the opposite.
“If I don’t pay attention to quality, everything blows up in my face by the third sprint.”
(Richard Seidl)
Behind the supposedly laid-back style of agile development there’s a lot of structure and discipline. That’s exactly what makes quality work in the first place.
Agile Isn’t Over, It’s Only Now Being Understood
The idea that agile is dead rests on a misunderstanding. At its core, agile means a team shapes its own process. It doesn’t mean working through a particular framework.
Which framework a team uses matters less. It can borrow from Scrum, Kanban, Design Thinking, Working Out Loud, retrospectives or scaled models like SAFe and LeSS. What counts is picking the building blocks that fit your own process.
The idea behind it stays: pursue shared values and a vision as a team, and build a process from them that’s enjoyable, efficient and gets better over time.
The hard part is ownership. If you come from a traditional environment and suddenly have to design your own process, that’s an exhausting change. There’s no way around that effort, though, if you want to handle complex requirements. Teams are only now starting to understand what agile really means.
Better Tools Have Taken the Edge off the Maintenance Nightmare
Testing tools have improved noticeably and take real work off your plate. On the developer side, scripts, open source tools, frameworks and automated security checks all support quality.
Test automation tools keep getting smarter. Keyword-driven and data-driven testing are established, and object recognition is increasingly reliable. Every decision still takes some brainpower, though: what do you automate at all, and where does it pay off?
The old reflex of automating everything through the UI often ended in heavy maintenance. Today, teams deliberately place tests at the right level, usually below the UI. Developers and others on the team help put each test where it belongs. That’s how you shrink a bloated UI test suite that runs for hours.
AI Is No Cure-All for Testing Problems
AI helps in testing only where the actual problem is an AI problem. In workshop after workshop, the most pressing issues turn out to lie elsewhere, and AI can’t solve them.
The risk is treating AI as a cure-all and throwing it at problems you don’t even have. The budgets exist, the funds are there, and that’s exactly what tempts teams into knee-jerk activity.
There are sensible uses, though: reviewing requirements, deriving test ideas and supporting test automation. The prerequisite is a certain maturity in the team. Without it, the effort goes nowhere.
The Basic Question: What Is Quality?
AI sends testing back to a basic question that should have been answered long ago. The classic quality criteria are deterministic and clear: functionality, efficiency, usability, security. For testing AI systems, they don’t go very far.
So the question is on the table: what does quality actually mean? Ask it in a team and the room goes quiet. Hardly anyone has given it serious thought beyond a paragraph in the test plan.
The pattern isn’t new. A performance requirement like “this thing has to be fast” has always sent testers looking for someone to define what “fast” means. Often nobody could, and the numbers were simply made up.
Today the problem is getting worse. Software brings together many business perspectives and serves many stakeholders. The hard question is what quality is, who answers it and when there’s enough of it.
These questions are still open, and it’s honest to say so. AI isn’t going away, even if not everything is an LLM. The system as a whole still has to work. How the idea of quality will be shaped for that, and how test organizations will change, hasn’t been decided yet.
Frequently Asked Questions
Who Is Responsible for Software Quality in an Agile Team?
Quality is a collaborative effort, not the responsibility of a single role. Product owners, business analysts, UX designers, developers, and testers work together to define what quality specifically means for their product. In the past, testing waited until development was complete, performed downstream checks, and reported bugs. This model no longer works with short iterations.
Why doesn’t downstream testing at the end of development work anymore?
Because testing cycles that used to last several months have become two-week cycles. The initial reaction of many teams was to adopt “mini-waterfalls”: they would rush through testing on the last two days of the sprint, and a single bug would ruin all their work. It was only through this painful experience that the practice of organizing quality throughout the entire sprint emerged.
Does agile development mean less documentation and less discipline?
No. This assumption was already a misunderstanding back in 2003, when the claim that “agility means quality” sparked fierce reactions. Behind the supposedly laid-back approach of agile development lies a great deal of structure and discipline. If you don’t pay constant attention to quality, everything will come crashing down on you by the third sprint at the latest.
Which agile framework should a team choose?
The framework is secondary. Teams draw from Scrum, Kanban, Design Thinking, Working Out Loud, retrospectives, or larger models like SAFe and LeSS, and select the building blocks that fit their own process. The core of agile work is for a team to build its own process based on shared values. The difficult part is taking personal responsibility.
Should test automation be built around the user interface?
Usually not. The former tendency to automate everything via the UI led to high maintenance costs and a bloated UI test suite that runs for hours on end. It makes more sense to consciously place tests at the appropriate level, often below the UI. Developers and other team members help with this classification.
Where does AI really help with testing?
AI helps where the actual problem is also an AI problem. Useful areas of application include verifying requirements, deriving test ideas, and providing support for automation. A prerequisite is a certain level of organizational maturity within the team. Without it, the effort will come to nothing. Existing budgets can lead to knee-jerk reactions to problems that don’t even exist.
Why Are Traditional Quality Criteria Insufficient for AI System Testing?
Criteria such as functionality, efficiency, usability, and security are deterministic and clearly defined. With AI systems, they don’t go very far. This brings us back to a question that many teams have never answered: What does quality specifically mean for this product, who decides that, and when has sufficient quality been achieved? The test plan often contains only a single paragraph on this topic.
