Many agile development teams will tell you that they don’t have software bugs, only user stories. If a user story in development does not meet the “completed” criteria, it is returned to the developer until it is truly complete, at which point it should have no more defects. Even if the quality assurance team discovers faulty behavior later, the remediation process becomes just another user story to prioritize, along with all the other user stories in the backlog. This is the wrong approach.
The problem is that these defect-related user stories tend to pile up in the backlog, competing for priority with important new features the team wants to develop. Defect-related user stories are often assigned a low priority because the issue is not critical. If he had really been critical, according to the team, he would have been detected earlier. So when bugs pop up, the team relegates them to the dungeons of the backlog, where they are never addressed. The problem is that while an individual defect-related user story may not be critical, taken together it diminishes the overall quality of the product. This type of short-sighted thinking when it comes to bug fixing ends up damaging the end product.
If it’s a bug, call it a bug
The solution is to report defects in the bug tracking system and clearly identify them as such. But you must also do it wisely. At different times during a sprint, issues can arise, and it’s up to you to use your judgment in deciding what to report.
The developer typically works on a user story until it is ready to go through 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 defect because the sprint is not complete, although he can move the cards from “testing” to “in progress” on the Kanban board. The developer then comes back and works more on the user story.
Once the code passes all acceptance testing, it moves into the development testing phase to more rigorous testing. The development tester has a broader view of the user story, and therefore runs code in different environments using different browsers and can run 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 reporting
When development testers spot a quality issue, they have several options. If the issue is critical and there is time left in the current sprint, they can move the card back on the Kanban board to “in progress” and send the user story back to the developer for more work. But if the issue isn’t critical enough to warrant immediate action, the development tester can open a formal defect, which then goes into the backlog to be prioritized in the next sprint. If the issue 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 defects for every little issue they find, the backlog will be flooded with minor defects and the team will waste time managing defects rather than improving quality. The argument here is this: many minor flaws never attract 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 overall workflow without affecting application quality.
Software bugs can also be detected once a user story is officially “done”. For example, a development tester working on one user story might discover a defect in another “completed” user story – an “escaped defect”. Every organization at one time or another has had to deal with bugs in production because the breadth and variety of experiences in live systems cannot be matched by quality assurance systems. In such situations, each defect should be entered into the system and prioritized with other defects and user stories.
Open bugs, but stay focused
So yes, when working in an agile environment, QA development testers absolutely must open new bugs. Don’t overdo it. Have a clear process in place 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 keeping up with the rest of the agile team.