Many agile development teams will tell you that they don't have any software bugs, only user stories. If a user story under development doesn't meet the "done" criteria, it gets returned to the developer until it's truly done, at which point it shouldn't have any defects. Even if the quality assurance team discovers faulty behavior later on, the process of fixing it becomes just another user story to be prioritized, along with all the other user stories in the backlog. That's the wrong approach.
The problem is that these defect-related user stories tend to accumulate in the backlog, competing for priority along with important new features the team wants to develop. Defect-related user stories often get assigned a low priority because the issue isn't critical. Had it truly been critical, the team argues, it would have been detected earlier. So as bugs crop up, the team relegates them to the dungeons of the backlog, where they never get addressed. The problem is that while an individual defect-related user story may not be critical, taken together they lower the overall quality of the product. This kind of myopic thinking when it comes to bug remediation ultimately damages the final 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 should also do so wisely. At different points in the course of a sprint issues may occur, and it's up to you to use good judgment in deciding what to report.
The developer typically works on a user story until it's ready to move on to testing to determine whether or not it meets the acceptance criteria. If the code doesn't pass one of the acceptance tests, the developer doesn't open a defect because the sprint isn't finished, although they may move cards back from "testing" to "in progress" on the Kanban board. The developer then goes back and does more work on the user story.
Once the code passes all acceptance tests, it moves on to the development testing phase for more rigorous testing. The development tester has a broader view of the user story, and so runs the code in different environments using different browsers and may run the tests for longer time periods and with heavier loads. Testers are also mindful of interactions with other user stories that the developer may not have seen.
Think before you report
When development testers spot a quality issue, they have several options. If the issue is critical and there's still time in the current sprint, they can move the card on the Kanban board back to "in progress" and have the user story go back to the developer for more work. But if the issue is not critical enough to warrant immediate action, the development tester may open an official 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 detect, 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 defects never 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 overall workflow without affecting application quality.
Software bugs may also be detected once a user story is officially "done." For example, a development tester working on one user story may discover a defect in a different "done" user story— an "escaped defect." Every organization at one time or another has dealt with bugs in production because the sheer scale and variety of experiences in live systems can't be matched by QA systems. In such situations, each defect must be entered into the system and prioritized along with other defects and user stories.
Open bugs, but stay focused
So yes, when working in an agile environment, QA development testers absolutely should be opening new bugs. Just 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 your product's quality. You have fewer high-, medium-, and low-priority bugs to manage, and you'll be able to ensure quality while keeping up with the rest of the agile team.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
