Releasing bugs is a team effort

In modern development we have many layers of automated testing and there’s manual functional and exploratory testing. We’re shifting testing further and further left to catch things early – ideally before a line of code is written. So why do so many applications that we use day-to-day have bugs? Why aren’t we as members of the engineering team catching everything?

Of course many of the bugs that are in production software have been caught and triaged. We simply decided not to fix them. However I plan to look at how we manage to miss bugs.

It takes a real team effort for a bug to get into the wild.

I’ve been talking about bugs a bit lately and know that I am not alone in taking an escape from a feature I was involved in as a personal failure. I felt this way as a developer and I still feel that way as a test engineer. However I know that not only is it not fair to blame any one individual, it should be an opportunity to learn. From this I’ve put together the series of mistakes and failures required by the entire team in order to ship a bug.

Missed when writing the story

I don’t want to dwell here as I feel that when writing a user story you are focused on the expected behaviour that can be found through example mapping or thinking about user workflow. That isn’t to say that you shouldn’t be conscious of these sort of issues.

Missed during planning / refinement

Before a story is picked up by a developer, we would expect it to have been refined and reviewed. Multiple members of the team should have been involved in looking at it. However for an escape to happen, it is likely that it was missed during these sessions.

Way to go team – you missed it.

Missed during 3As / kick off

Regardless of your way of working, hopefully there was some conversation when the story was picked up. This is the last chance to catch a bug before development starts and often one of the most detailed discussions. As well as ensuring that we understand the acceptance criteria, we really want to be thinking about the edge cases here.

Way to go amigos – you missed it.

Missed in developer testing

Any self-respecting software engineer will be testing their own work, both manually and using automated tests.

Way to go dev – you missed it.

Missed in code review

Code reviews are more than nitpicking over names or formatting. They most important goal is to spot mistakes that the developer may have made.

Way to go reviewer – you missed it.

Missed in test phase

Whilst many people will look exclusively at this stage, it isn’t the sole responsibility of the tester of a story to find / prevent bugs. Nonetheless,

Way to go tester – you missed it.

Missed in showcase / sign off

Many workflows out there have some sort of sign off to say the story is done. If your workflow has such a state then clearly the PO has signed off on this buggy story.

Way to go PO – you missed it.

Missed in general use of the software by engineers

Unless you’ve a super fine tuned CD pipeline, there’s a likelihood that members of your team or the wider group will have used the feature.

Way to go team – you missed it.

Missed in release / sanity testing

Of course not all teams do this, depending on your workflow and deployment system but if you’re doing testing before release, it hasn’t caught it. Before you say “it was out of scope”, ask yourself why the scope doesn’t catch it and whether its even worth doing.

Way to go tester – you missed it.

Way to go all – you missed it!

Escapes can and will happen. When it does you should look to learn, not blame, and if you do really want to play the blame game, it should never be one person.