Yes, you should be opening software bugs in Agile Stores. Here’s why.

Many agile development teams will tell you that they have no software bugs, only user stories. If a user story under development does not meet the criteria of “done”, it is returned to the developer until it is truly complete, in which case it should be free from defects. Even if the QA team finds faulty behavior later, the remediation process becomes just another user story to prioritize, with all the other user stories in the backlog. This is the wrong approach.

The problem is, these defect-related user stories tend to pile up in the backlog, competing for priority with the important new features the team wants to develop. User stories related to defects are often given a low priority because the issue is not critical. If this had really been critical, the team argues, it would have been detected earlier. So, as bugs arise, the team relegates them to backlog dungeons, where they are never resolved. The problem is that while an individual user story linked to a defect may not be critical, taken together it reduces the overall quality of the product. This kind of myopic thinking about fixing bugs ultimately damages the end product.

If it’s a bug, call it a bug

The solution is to report faults in the bug tracking system and clearly identify them as such. But you should also do it wisely. At different times during a sprint, issues can arise, and it’s up to you to use common sense in deciding what to report.

The developer typically works on a user story until it is ready for testing to determine whether or not it meets the acceptance criteria. If the code does not pass one of the acceptance tests, the developer does not open a fault because the sprint is not complete, although he can move the cards from “test” to “in progress” on the Kanban board. The developer then comes back and works more on the user story.

After the code passes all acceptance tests, it moves to the development testing phase for more rigorous testing. The development tester has a larger view of the user’s history and therefore runs the code in different environments using different browsers and can run the tests for longer periods of time and with heavier loads. Testers also pay attention to interactions with other user stories that the developer may not have seen.

Think before you report

When development testers detect a quality issue, they have several options. If the issue is critical and there is still time in the current sprint, they can put the card back on the Kanban board as “in progress” and send the user story back to the developer for further work. But if the issue isn’t critical enough to warrant immediate action, the development tester can open an official fault, which then goes into the backlog to be prioritized in the next sprint. If the problem is minor, the tester can choose to ignore it or make a minor adjustment to one of the acceptance criteria.

This approach makes sense. If development testers open up flaws for every little issue they find, the backlog will be inundated with minor flaws and the team will waste time dealing with flaws rather than improving quality. The argument here is this: a lot of minor flaws don’t get any attention anyway, so why bother opening them in the first place? By giving development testers the authority and responsibility to make these decisions, the organization can improve the overall workflow without affecting the quality of the application.

Software bugs can also be detected once a user story is officially “done”. For example, a development tester working on a user story may discover a defect in another “completed” user story, a “escaped defect”. Every organization at one time or another has dealt with bugs in production because the scale and variety of experiences in live systems cannot be matched by quality assurance systems. In such situations, each fault should be entered into the system and prioritized with other faults and user stories.

Open up bugs, but stay focused

So yes, when working in an agile environment, QA development testers should definitely open new bugs. Don’t overdo it. Have a clear process for handling defects and think carefully before reporting an issue as a defect. Leaving out the masses of low priority bugs will give you a much better overall picture of the quality of your product. You have fewer high, medium, and low priority bugs to deal with, and you’ll be able to ensure quality while staying in touch with the rest of the agile team.

Keep learning