Drowning in a Testing Backlog? Your Problem Isn’t AI, It’s Culture

Reading Time: 3 minutes

 

AI is making writing code faster, but it’s not always making software production faster. I’ve spoken to several people over the last months who have told me this using different words. Developers are churning out more merge requests and sending more tickets for testing quicker than ever before, and usage of the word “bottleneck” is increasing with them. I’ve heard from testers that they’re drowning in testing backlogs, unable to test tickets at the same rate they’re coming through. From a product owner whose team’s “ready for deployment” column is full of tickets, just waiting for other tickets to be ready too before they can progress. These people have asked me how they can use AI to solve these problems. But it’s not AI causing these problems, it’s culture. AI just makes the pain worse, and more visible.

 

 

The Testing Bottleneck

 

My job is split in two. I spend half my time embedded on a product team, and half my time on the company’s AI enablement team. At 50% capacity, I have no issues keeping up with the product team’s testing activities. Not because the developers aren’t using AI or implementing features quickly, but because the developers are testing too. Sure, there are busier times, especially around holidays or competing priorities, but I’m not facing the same struggles that many others are.

 

Even before AI came into the picture, I worked closely with the people on my team to create a culture of quality and shared responsibility for building it in. I paired with and coached them, to get them more comfortable with testing and help to improve their testing skills. I set up our test automation framework and showed them how to work with it. I’m always on hand to support, but testing and quality are not only my responsibility.

 

We don’t throw tickets over any wall for testing. Devs always test their own tickets before asking anyone else to look at them. Usually, that means another dev, but they now have enough experience to know when a ticket might have higher risk or deserve a more thorough review, and that’s when they’ll ask me to take a look as well. Devs also maintain the test automation as part of feature implementation – not as a separate piece of work – and I’m there to provide guidance and review the code as needed.

 

If developers don’t test, don’t write automation, and don’t understand risk, testers will inevitably drown in a testing backlog. It’s absolutely possible to use AI in testing too, and maybe help to bring that backlog down. But that’s just treating the symptoms. Better to treat the cause – the culture.

 

 

The Dependency Bottleneck

 

To the dependency bottleneck, I say the answer is in the problem statement. Ready tickets are waiting for dependencies to be ready too before they can be released, but they’re stuck in review and testing. Sure, you can use feature flags while you wait and release together, but that’s another symptom suppressor. The real problem is in the way tickets are split.

 

Whether tickets are being split and / or written by humans or AI, if you build a dependency into the split – knowingly or not – it will be there when you want to deploy and release too. We mustn’t get swept up in the speed of things, and should still slow down at times to think about dependencies and consequences. That means having proper discovery and refinement processes, and keeping up good communication with other teams. Whether dependencies are internal to the team or external, we still need to coordinate and plan to minimise the waiting time, for the development teams and the stakeholders / users. Using more AI won’t help with this, but you can use AI to help identify the dependencies and suggest a split and / or timeline based on them.

 

Another thing to remember is that each ticket should be able to deliver some value on its own, independent of any other ticket. If you can’t release ticket A without waiting for ticket B (which is not properly handled as a prerequisite), you might want to question whether that criterion is met.

 

 

Conclusion

 

In short, AI is making our aches and pains more visible, but many of them already existed. For a sustainable solution, focus on addressing the cause of those pains, and perhaps use AI to address those causes, but don’t just mask the symptoms.

 

What challenges are you noticing more with the increase in AI use? How are you addressing them? Let us know in the comments.