For years, we have been talking about digital transformation, operational efficiency and process automation. And now, almost constantly, about artificial intelligence. But organisations are not just talking about these things. They are investing more and more resources in developing digital solutions faster and responding to a market that demands constant innovation.
Yet amid all these conversations, there is one question that many organisations still do not have a clear answer to:
Who makes sure that what we are building actually works as expected?
And we are not just talking about whether it works technically. We mean whether it works for the business and its users, whether it fits the organisation’s processes and whether it delivers the value that justified the investment in the first place.
Because it happens more often than we might think: an application passes every technical test and still fails to solve the problem it was created for.
The problem isn’t technology. It’s timing.
As QA professionals, we see it far too often. Projects that appear to get off to a solid start, with sufficient budget and a strong technical team, reach production with improvised validation, vague acceptance criteria and users who have not been sufficiently involved.
This does not necessarily indicate a lack of technical capability. Often, quality simply entered the conversation too late, meaning no one had enough time to validate whether what was being built was what was needed.
When QA comes in at the end, it can only check whether something works or identify what is going wrong. When QA is involved from the beginning, it can help answer much more important questions: What needs to happen for us to consider this project a success? What does the user really expect? Which risks do we need to validate before moving forward?
The difference is significant. It is not about testing better but about defining earlier what “doing it right” means. And that completely changes the value QA can deliver.
QA can’t just be about testing
For a long time, quality assurance in software development has been associated with running tests before software goes into production. That role is still essential, but it is no longer enough.
QA has historically acted as the bridge between what is being built and what is actually needed. And that role requires us to look beyond simply finding defects.
We need to establish acceptance criteria that business and IT understand in the same way. We need to maintain traceability between the original needs and the solutions being developed. This also changes the way we approach User Acceptance Testing (UAT), which needs to be properly structured rather than treated as a rushed validation exercise just before production, carried out by users who barely have enough time alongside their day-to-day responsibilities. And when something fails, as something inevitably will, we need clear mechanisms for managing findings, correcting them and learning from them.
This is much more than testing. It is about ensuring that business, technology and users work towards the same definition of success throughout the project. It is about quality governance.
Greater speed requires better judgement
And now that delivery is moving much faster, this approach to quality is even more important. AI’s ability to accelerate development can also make us move much faster in the wrong direction.
That is why, as speed increases, so must our ability to establish clear criteria, prioritise risks and decide where human intervention remains essential.
Capgemini’s World Quality Report 2025-26 reflects precisely this shift. Generative AI is gaining ground in quality engineering and offers significant potential in areas such as requirements refinement and test design. However, the report also highlights that many organisations are still struggling to turn the use of AI into sustained improvements in their quality processes.
AI can clearly help us review more information, generate more scenarios and automate certain tasks. But first, we need to know what we want to validate and why.
From running tests to building a quality capability
The natural evolution, therefore, is not to do more testing or simply to do it faster. It is to develop a permanent capability for ensuring quality.
That is precisely the approach behind QA Coach: helping organisations build their own model that integrates quality strategy, governance and culture, always tailored to their level of maturity and their specific circumstances.
This means supporting teams in building a quality culture where decisions are based on shared criteria, where AI is used where it genuinely adds value and where every delivery generates knowledge that helps improve the next one.
Quality in software development should not depend on one person or on a specific phase of a project. Nor is it simply a department. Quality is a way of working and it belongs to everyone. It belongs to the business when defining its needs, to IT when turning those needs into solutions, to users when validating that those solutions work in the real world and to those governing the project when ensuring that all these perspectives remain aligned.
That is why quality assurance can no longer be a conversation reserved for the end of a project or the exclusive responsibility of the QA team. The earlier that conversation begins, the greater the project’s chances of success.
Article by Lily Rodríguez – Quality Manager at LedaMC
