Rules of bug engagement

In my first ever blogpost, I’m going to write about the most important task of a tester, generating bug reports. Like every tester, I love it when I find that critical bug in the application. After we found an issue, we should create a good bug report. In this blog I’m going to tell you about the rules I apply for creating a good bug report.

Rules to created Bug reports

As a tester your job is to find bugs. When you find these you need to create a bug report. Creating a structured and detailed bug report, will help Development reproduce the issue faster. Reproducing the issue faster, shall reduce the time they need to fix the bug. Underneath is an example on how I create a script for development to reproduce the issue:

  1. Login to the application
  2. Go to page User Administration
  3. Press the New button
  4. We don’t get a dialog to create a new user, instead we get an error dialog

Together with the script, I attach screenshots and logfiles. The screenshots will give the developer an idea about the reaction of the application. Where the logfiles could contain stacktraces about the issue.

Next to this information, The title needs to give the developer an idea about the issue.

  • vague title: User could not be created
  • clear title: When creating a new user we will get an error dialog

Now we have a clear script and title, it’s key to set the priority. This will give the developer an idea of the importance of the issue. Next to the clear plus for developers, the Project Manager will have an overview of the amount of issues in the application. But also about how critical these are. He will also be able to plan ahead and communicate to the stakeholders of the projects about timing and releases.

Best practice for a test team is to set the priority level on project start. Every priority level should be clearly stated what it represents. This should be documented and approved by the complete project team. Giving every member of the project a clear idea on which issues have priority on others. The following levels are an example of priority levels:

  • Blocker: The application breaks or could not function
  • Major: There is an issue but there is a workaround
  • Minor: A Button is out of place for example
  • Trivial: A button has a wrong color

Bad practice for a tester is the mark every bug as a blocker. While you are eager to let the developers fix all the issues immediately, this is not possible. Testers that keep creating bugs prioritized as blocker, will walk into trouble sooner or later. The developers will no longer work on your bugs, because they are all blockers, even if it’s just a color change of a button for example.

With these rules in mind you can tackle already the most important issue testing teams have. Giving the developers a good overview of the task at hand and helping the Project Manager manage the project resources.

Please follow and like us:

Add a Comment

Your email address will not be published. Required fields are marked *