By the time a test fails, the issue may have started much earlier. It might sit in an unclear requirement, an unchallenged assumption or an edge case missed during refinement.
At a recent Ministry of Testing London Chapter meetup, Jagrit from BBC Studios described his team’s move towards quality engineering and how they are considering quality earlier in development. Much of it reflected what I have seen in my own work with delivery teams.
Although new tools are changing how teams build software, teams still need to understand users, identify risks and agree what good looks like. AI gives them another way to examine requirements and question assumptions, provided its output is checked by people who understand the context.
Understanding what needs to be tested
A lot of the current discussion about AI in testing focuses on generating test cases or helping to write automation. Those are useful applications, although they happen after some of the most important decisions have already been made.
The refinement stage gives quality engineers an opportunity to influence the work before it becomes harder to change. As a team works through a requirement, AI can help them:
- Assess whether the requirement can be tested and where coverage may be missing
- Identify edge cases or assumptions that have not yet been considered
The response becomes another input to the refinement conversation. The team still decides which risks matter and whether the requirement is ready to move forward.
Supporting consistent engineering practice
At Hippo, I use quality coaching and work alongside developers to make testing part of day-to-day delivery. One conversation can set a direction, but teams also need ways to apply the same thinking as the work changes.
During a pull request, for example, AI can help teams:
- Summarise the changes that have been made
- Identify areas where test coverage may be missing
- Flag inconsistencies against agreed engineering standards
Engineers still need to review what it produces, decide whether each finding is relevant and choose what to do next.
Keeping people in the ATDD loop
Build the right thing and build the thing right.
Acceptance test-driven development (ATDD) starts with a conversation. Before coding begins, business stakeholders, developers and quality specialists agree what needs to be built and how they will assess whether it works as intended.
Teams can use AI at different points in that process, from examining the initial requirement and challenging acceptance criteria to identifying risks and reviewing code changes.
The people involved bring the understanding of users, constraints and consequences. They remain responsible for checking the output and deciding what good looks like.
Quality still depends on people
Quality specialists help teams keep users in view, raise risks early and address problems before they become harder to change.
AI may reduce the time spent on some repetitive work, leaving more space for investigation, discussion and decisions that need human judgement. Whether it helps depends on the questions people ask, how closely they review the response and what they do with it.
Used well, it gives teams another opportunity to consider quality while the work is still taking shape.
I explore this approach in more detail in the ShiftSync course, How to use AI in your daily SDET workflow: a practical ATDD guide.
