Entry 15

As I was talking to a friend about my beginnings as a tester I remembered my struggles on how to report bugs during my internship, as we were given challenges rather than simple solutions…


Bugs of course come in all shapes and sizes, but the right bug report is essential to enable the decision making people to make the right decision whether the bugs should be fixed or not and when (and to make further work with the bug as easy for the developers as possible).

Using the right temple is important but it is as important to understand why each element is there. I will write about the template I use (and consider it a good practice), but if you use something else or have any thoughts – let me know in the comments section.


First thing to ask should always be –  is what you have found a bug or a feature (sometimes it is easy to determine, sometimes it can be hard). If you are not sure, it is good to search in the documentation and/or ask other team members. When you know it is a bug – proceed.

name-tag-for-id-vector-9627985Who am I? – Name and Id

Bug report should have a name that will meaningful while also being short.
ID can be either given manually or generated by the bug tracking software. It will enable easy identification and search for the issue.

Where am I ? – Environment

Give as detailed information as possible as the environment is very important the same s800thing that works in one may not work in another and vice versa. Of course if you test on only one environment you would not need that, but that was never the case for me.

Is it desktop/ mobile (phone or tablet)/ wearable/ embedded kind?
What is the system version?
What is the browser version if applicable?
Is there a specific viewport ?

What do I need to occur? – Precondition

preconditionMaybe You need to be logged in to the system to be able to reproduce?
Maybe You need to have weak internet signal?
Maybe the battery must be almost depleted?
Maybe you need to set up a testing tool beforehand ?

If there is any thing that needs to be done before reproducing the steps it is better to write it down as precondition, than to make the list of steps much longer. This ensures clarity of the report.

What needs to be done to see me? – Steps to reproduce

7-steps1. Describe the steps.
2. Keep the description clear and brief.
3. Make it understandable for any person who might try to reproduce the bug or just understand what it’s all about.
4. Use lists.

What did you expect ? – Expected result

result-result-54dc53bd32ef9_exl-300x250This will tell the reader what should have happened after performing all the steps in the preset environment. It may also contain a business rule/expectation mention and the output if applicable. It has to be clear what the outcome should be. If there is more than one thing (usually that is the case) it might be a good idea to make a simple bullet list.

What happened? – Actual result

pass-fail-examThis is what went wrong – the core of the report. State clearly what was not as expected, what happened and how You saw it – e.g. error in console, something did not render etc. Sometimes bullet list is a good idea here too. I sometimes make a table were I list all the things that should happen and mark in with X and V – it is clear,  precise and gives visually nice information about what happened and what did not.

Any comments? – Comment

commento-300x190There might be something else that you want to tell the reader that did not fit in the other places – do it in the comment!
Maybe you suspect what the bug is related to?
Maybe it is connected to other bug?
Maybe you have encountered something similar before and want to offer some advice or insight?

Something else to add? – Attachment

paper-svg-1We all know the saying that the picture is worth a thousand words, but so is the short movie, screenshot, console log or any other thing that can help to decide about the bugs’ future. So if it is possible – add an attachment that shows what happened and what you are reporting. Depending on the bug reporting system you may either store it as a normal attachment to the report or give a link to the picture/log/movie that is hosted in some shared space.

There is one more thing I always add to my bug reports: information about Priority.
I did not put it on the list because in some teams Priority is given to the bug by Product Owner or Project Manager or Test Manager or Test Analyst, not the tester who found it.


Assigning the right priority to the bug requires experience and project knowledge, because you have to take into consideration, among others :

  • bug itself,
  • how it affects the part of the system where it was found,
  • how it affects User Experience (usability),
  • how is it connected to project and product risks.

Priority given to a bug would also inform the decision makers (ex. team during planning) where in their task priority list should it land.

The priorities I mostly use are (from bottom to top) are: Trivial, Minor, Major, Critical, Blocker. Some people also just use 1-5 scale, although some see 1 as the highest priority and some see 5 as such, so always remember to check the used leveling.


Remember what is the most important thing in the bug report: its’ purpose. We want to do it well, because what we need is to communicate efficiently, create common ground for the team collaboration and provide information for the decision makers.

Any thoughts? 🙂



One thought on “BuggyLand

  1. Thanks Marta for sharing this on Twitter. Here are my points: (Not in any particular order)
    1. Every bug report is context based and understanding the context helps the team to work together in a better way and be productive.
    2. Instead of saying, “Expected” Result, I love to say, “Possible” Result(s). If I say, “Expected” Result, I need to back up my statement with empirical data or the source from which I derived “Expected” Result. Or maybe I am sounding like, “Hey, this is MY expected result”.
    3. I would like to speak about “Possible Results” if I don’t have any source from where I am quoting my “Expected” Result. And also, I would like to end my “Possible Results” description with a question, “What do you think?”. This way I am making the readers think instead of blindly changing things which may go wrong. I have a personal experience where developers blindly changed things to “Expected Results” of my “Bug Report” and then “Stakeholders” / “Product Owner” / “Business Analysts” flagged the “So-called Fix” as a “Bug”. That was a learning moment in my journey as a passionate tester to set the context and keep the communication clear and clear the terminologies and see if people on the team are aware of what we mean when we say “something”.
    4. Also, “Actual Result” is reworded as “What it appears to be or looks like” in some contexts of the bug that we find. I use both ways 🙂
    5. I see that you use, “Trivial, Minor, Major, Critical, Blocker” keywords in your report. I use them too, but I make sure the readers understand what I mean when I use these. Am I weighing a particular severity keyword in terms of “Business Impact, “Technical Impact”, “Reputation Damage”, “Loss of Respect (Brand Image)”, “Loss of Data”, “Inconsistencies” and etc?
    6. My bug reports keep changing on every new project or even in the same project at different times based on various types of “Contexts” that the project may demand in order to succeed with our objectives.

    Last, but not least I liked the way you are speaking about Risks, Context, Helping Decision Makers (Stakeholders probably) and Attachments.

    A quote in the end, “If your bug reports cannot communicate the bug, then there is a bug in your bug report that needs the fix”.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s