While you are testing some user stories you may find a bug that you need to report. The next step is to decide whether are you going to report the bug in the comment section in the user story and move the story back to development, or you are going to report it in a new bug ticket. You need to make the right choice to maintain efficient workflow, and to report the bug properly.
Before you decide what to do, it is important to do a couple of things.
The first step that you need to do is to determine the severity of the issue. Check how much impact it has on the product, is it a blocker, or critical issue, or it is a minor issue that does not impact the product significantly?
The next step that you need to do is to determine the scope of the issue. Is the issue related to the acceptance criteria that are described in the story, or did you find it during the testing, but is not related to the user story that you were testing?
The last step that you need to do is to check the impact of the issue on the user story that you are testing. Does that issue prevent the user story from being done, or it is a minor issue that doesn’t affect the primary functionalities?
After you have done all of these steps, you can decide how to report the issue.
When to Report the Bug in the Comment and Move the Story Back
If you see that the bug is directly related to the acceptance criteria of the user story, it should be reported in the comment section of the user story. If some of the acceptance criteria are not developed, or if some of them are not working as expected, then that is a good reason to move the story back into development.
Let’s say you have a user story where the goal is to develop a contact form with the following fields: Name, Phone, Address, Email, Subject, Message, and Send button. For example, if you can see that the Address field is missing, or the email validation is not working properly, that is directly related to the acceptance criteria of the user story.
If you are unable to complete the testing of the story because of the issue that you have found, you should also report it in the comments and move the story back. For example, you have tested a couple of acceptance criteria, and you found some issue that blocks you and you are not able to continue with testing the rest of the acceptance criteria, that is also a good reason to move the story back.
For example, you are testing a user story where the goal is to develop four forms that will guide the user to purchase a product. Those forms are Product Information, Personal Information, Delivery Information, and Payment Information. If the button on the Personal Information form remains disabled even when all the mandatory data is entered, you will not be able to test the rest of the acceptance criteria for the Delivery Information and Payment information forms.
When you are working on a story that needs to be done in the current sprint, and you can assume that the bug you have found will not take so much time to be fixed, because it is a minor bug, you can discuss it with your team and report the bug in the same story. In that way, you can keep things simple, some developer will fix it, and when the fix is ready you can retest it within the same sprint without opening new tickets. This can be done when the deadline is tight and in coordination with the team.
Let’s say you are testing the push notifications for a mobile app, which is a new feature for which you have a tight deadline. Everything works fine, except the fact that all the notification messages are shown doubled. Discuss that with the team, and if they agree, report it directly in the ticket, so the bug can be fixed immediately, without wasting any time.
When to Close the Story and Open a New Bug Ticket
If you have some issue that is not directly connected to the user story acceptance criteria, that means that the issue is not a part of the user story’s scope. In that case, if all the acceptance criteria are working as expected, move the story to ‘Done’ and open a new bug ticket.
Let’s say you are testing a story where the goal is to develop a user registration form with a couple of fields. Everything works fine, but you have noticed that the link for the Terms and Conditions at the bottom of the page is not leading to the right page. That was not part of the user story, so you can report it as a separate bug ticket.
If you found some minor bug that is related to the acceptance criteria but doesn’t impact the functionalities of the user story, you can open a new bug ticket. In that way, you will not disturb the current work, and that minor bug can be fixed in the future.
Let’s say you are testing a form that works brilliantly, but two checkbox fields are not aligned correctly. That is a minor bug that can be reported in a new bug ticket.
When you find some scenario, that is working, but there is a potential for improvement, discuss it with the team, and report it as a new ticket.
For example, you have a form where everything works as expected, but the text below the form is gray on a white background which makes it difficult to read. This can be improved, but it needs to be reported in a separate ticket.
When the story is moved to ‘Done’, and you find some bug after that, for example, while you are doing regression testing, don’t reopen the story. Open a new bug ticket and prioritize it independently.
By following these steps, you will be able to report bugs properly, keep the team updated, and ensure high-quality software while keeping the development process smooth and streamlined.
