Effective Bug Reporting

What is a bug tracking system

● a process used by quality assurance personnel and

programmers to keep track of software problems and
resolutions
● enables users to enter bug reports directly into a system that
logs and tracks them
● includes a database, which keeps track of facts related to
each bug
Most used bug-trackers
Bug reports

● A good bug report should allow anyone to understand the bug and
take action on it without having to talk to the person who wrote it.

● Bug reports can be an excellent means of assessing how well you've

tested a bug.

● Good bug reports indicate good testing.

● The aim of bug report is to narrow down the root cause of an issue to
a set of steps, that will help the developer to debug the code.
Severity and Priority?
Severity represents “how bad” a bug is. For example, a bug
that causes the program to crash would be considered high
severity, while a small spelling error might be low severity.

Priority represents the importance of fixing a bug and reflects

a business decision as to how soon that bug should be fixed:
all priority 1 bugs should be fixed before priority 2 bugs, etc.
Examples of how to set Severity and Priority
Bug report template
 Bug report template
The title
➢ Should describe the problem as best as possible.
➢ It must be short, but clear and specific.
➢ Remember that the title is read more often than any other part of the bug report.
➢ A good title will help anyone find the report by searching, looking at a titles list, and also observe
other related reports and/or duplicates.
➢ Sometimes the title may start with a tag, written between “[“ and “]”, as agreed with the team (for
example, the OS where the bug appears - e.g. [Windows], the test environment where it was found -
e.g. [Stage], the large feature that the bug is related to - e.g. [Login]

Poor title: “Notes don't display correctly”

This title is not specific enough for someone to look at it a month from now, and remember what the bug report is referring to.

Good title: “Stems too short for 32nd and 64th notes”
This title is an improvement over the previous title, because it specifies the type of notes that are affected and identifies the display problem.
 Bug report template
Classification
Severity:
This describes the impact of the bug.
While it can be summed up in one word, severity is a very integral part of the overall bug report. Get it right and the development team can allocate
the appropriate amount of time and effort to each issue. Get it wrong and you risk slowing down the development life cycle.

Types of Severity:
Blocker: No further testing work can be done.
Critical: Application crash, loss of data.
Major: Major loss of function.
Minor: Minor loss of function.
Trivial: Some UI enhancements.
Enhancement: Request for new feature or some enhancement in existing one.

- Depending on the client, the issues severities may differ. For example, a client could consider the UI part the most important. This would make the
UI issues to be considered criticals or even blockers. But this kind of decisions will always be discussed in the team and with the client, usually at the
beginning of the project.
- There is also the case where the Severity and/or Priority of an issue are set by the Project Manager or Product Owner, the reporter is just leaving
these fields with the default values. These are particular details that are different from a project (team) to another.

Priority:
When bug should be fixed? Priority is generally set from P1 to P5. P1 as “fix the bug with highest priority” and P5 as ” Fix when time permits”.
 Bug report template
Date:
➢ The date field represents the date when the bug was reported
➢ Usually, the date field is automatically added by using the reported date. If not, you must fill it with
today's date (e.g. 3/24/2017 - US style date)

Reported by:
➢ The reported by field represents the Reporter’s name or username
➢ Usually, the reported by field is automatically added by using the Reporter’s name or username. If
not, you must fill in your name (e.g. John Smith)

Email:
➢ The email field represents the Reporter’s email address
➢ Usually, the email field is automatically added by using the Reporter’s account email. If not, you
must fill in your email address (e.g. [email protected])
 Bug report template
Product: In which product you found this bug.

Version: The product version (if any).

Component: These are the major sub-modules of the product.

Platform: Mention the hardware platform where you found this bug.
Example: PC, MAC, HP, Sun etc.

Operating system: Mention all the operating systems where the bug is reproducible.
Example: Windows, Linux, Unix, SunOS, Mac OS. Mention the different OS versions also if applicable like Windows NT, Windows 2000, Windows XP etc.
 Bug report template
Description should contain full details of the issue, giving as much detail as possible:
➢ Prerequisites: Any pre-condition required to reproduce the issue / test the fix.

Example: Make sure to have Chrome browser, version 56 installed.

➢ Steps to Reproduce: Minimized, easy-to-follow steps that will trigger the described problem.

Example:

1. Go to https://en.wikipedia.org with Internet Explorer version 10.0;

2. Make sure you are logged in;

3. Select "My Preferences" menu;

4. Go to "Gender" and select female gender from box list;

5. Click "Save" button.

 Bug report template

➢ Expected Results: What the application should have done, if there was no bug.

Example: My gender should be shown in front of my user name.

➢ Actual Results: What the application actually did after performing the above steps.

Example: There is no female gender in front of my user name.

➢ Workaround / notes: Describe the workaround this issue, so it won’t be a blocker until fixed (if there is any). Also add any other
helpful notes.

Example:

Workaround: The gender is correctly displayed after refreshing the page.

Notes: The issue is not reproducible when using Firefox browser or older versions of Chrome.
 Bug report template
Other information
➢ Links or differences between platforms, to one or more pages where you encountered the bug
➢ Mention whether the problem appears every time, only occasionally, only on certain pages, or
only in specific circumstances
Example:
- This issue is 100% reproducible on Windows and not reproducible on MacOS.
- This is reproducible in 8 out of 10 tries.

➢ If you can supplement your bug report with an image, audio, or crash log that helps others
reproduce the issue, attach these files.
➢ There might be also specific details that are required on the project/team you’re working, and the
tracker might be (or might not be) configured to display those fields as mandatory. These are
particular details of every team’s process and they’ll be discussed with the team when required.
Example:
- Label (a tag that is added to easily find more bug reports related to a certain feature).
- Color (for example, all “open” bugs are grey, all “ready for testing” are green, “reopened” ones are red, a standard that was agreed by the
team).
 Hints and tips for an effective bug report

1. Give away the show stoppers (the blockers)

2. Be specific

3. Trace the steps

4. Report the first error

5. Attach relevant files

6. Don’t get it personal...

7. ...but don’t “trust” the developer

 Hints and tips for an effective bug report

1. Give away the show stoppers (the blockers)

If a critical bug is blocking the testing process, let every member of the team know immediately!

➢ File a bug report: Investigate the issue and file a bug report once you have all the details to do that.
➢ Let everyone know: Even though filing a bug report is the first step when finding a blocker, this is not
enough. If the entire team is located in the same office, you just tell them what you have found, give them
all the details and provide the bug report ID. However, there are teams that are not in the same office
(sometimes not even in the same time zone). In this case, you have to announce this by the usual agreed
channels: Skype group, email, phone.
➢ Follow up on this problem: Solving this will become a high (if not even the highest) priority task for any
member of the team. Once it’s fixed, make sure to resume your work.

For example, when the Login feature is not working and - because of that - the rest of the application cannot be tested, this is a blocker (or
“show stopper”).
Also, there are cases when you are close to a release and you discover a blocker issue. In these cases it’s sometimes better to let everyone
know first (especially the team), and decide with the team if the blocker should be reported or not, quickly fixed or not, depending on the
blocker's impact on the product.
 Hints and tips for an effective bug report

2. Be specific

➢ Use the exact same words as the application.

➢ If you see something, write it as is.
➢ If you click something, write it’s exact name, using quotation marks (“ ”).

For example, instead of writing <<Access the registration page>>, you could use <<Press the “Sign up” button from the top-right corner of
the page>>. This way, is clear for anyone reading the report how to reach the registration page.
 Hints and tips for an effective bug report

3. Trace the steps

➢ Usually, a bug is at the end of a workflow. To reproduce it, someone needs to replicate the entire flow.
➢ Do not assume it’s obvious. It might be less obvious for someone else, sometimes even for you, in case you
have to revisit it after a few days.

For example, it is not enough to say that <<the “Play” button is not working>> if this only happens after performing some other actions too.
If you write the scenario as a single step:
Steps to reproduce:
Press the “Play” button.
Expected results:
The video should start playing.
Actual results:
The “Play” button is not working.
the assigned developer will press “Play”, notice that the video starts playing, and will immediately close the ticket
with “Not reproducible” status. You’ll then have to re-investigate, reopen the ticket, add more details, and all these actions
take time (lost time).

Write all the steps that are required to reproduce the issue, from the very start. This way, both you and the
developer will save time (and no one will become frustrated). See the example below:
Steps to reproduce:
1. Launch the video player and start playing a video from a playlist.
2. Pause the playback and press the “Next” button to get to the next video in the playlist.
3. Press the “Play” button.
 Hints and tips for an effective bug report

4. Report the first error you see

➢ People often get used to seeing an error that they become tuned to ignoring it.
➢ If a part of a system has failed, the next error may be a result of the first failure and not a real error in itself.

For example, if you see a 404 “Not Found” error in the browser console each time you open a web page, and it doesn’t appear to affect
anything on the website (the page is displayed correctly), you will start to get used to it and ignore it. However, at some point, you may
notice for example an image that is not loaded on some other page, and this issue might be in fact the same issue with the console error
that was ignored. This is why the console error must have been reported in the first place.
 Hints and tips for an effective bug report

5. Attach relevant files

➢ Attach as many relevant screenshots (and other related files) as you can.
➢ More is better! The more information available, the more likely the report will be clear for anyone who reads
it, the issue will be reproducible and will be fixed.

Example of files that can be attached (not all of them will apply each time you report an issue):
- Images that are highlighting the actual issue: trace an arrow, circle in red, highlight text, whatever works and applies
- Error logs that are saved by the application.
- Details from the browser console or any other tools that were used for testing (e.g. “404 error. Not found” displayed in Firebug).
- The set of requirements that the issue contradicts with (e.g. it says here that the button should be this shade of blue, but instead, it
is green).
- Charts, reports (e.g. the loading/response time of the web site is increasing exponentially after new images were added - make a
chart that visually shows that issue).
- Automated test results.
 Hints and tips for an effective bug report

6. Don’t get it personal...

➢ You are reporting a bug, not discussing the developer’s ability or the quality of the software.
➢ A developer closing your ticket as “cannot reproduce”, doesn’t mean war. Provide any additional
information that might help the developer and/or the team to retrace the steps to reproduce the reported
issue.
➢ The testers and the developers are in the same team, working on the same side, communicating with each
other, to deliver a high quality product.
 Hints and tips for an effective bug report

7. ...but don’t “trust” the developer

➢ You might find yourself in the position where you are certain that some behaviour of the tested product is
an issue, but the developer insists that it is actually working exactly as it is supposed to be (“trust me, I
know better” - the developer might say).

Take some time to think about what to do, how to react in a similar situation, and let’s discuss this on our Facebook Group, or debate it in
our next meeting.
Useful links
● Software bug
● Severity & Priority in testing
● 15 Most popular bug tracking software
● Quality bug reports