A Good Bug Report Format

As part of our testing, maximum time is spent around bugs, whether its writing a new bug, verifying a fix, giving more information, contesting the validity, linking similar bugs and so on. All these times we are looking at various pieces of information which are in the bug report.

My experience in testing has made me firmly believe that a good Bug Report is key to high quality software. My personal hypothesis is that if we can tackled this activity well then we are bringing in more efficiency. So lets look at a good bug report format.

Contents of a good bug report

1. Bug ID or Bug No – This is a no which has to be unique across all bugs. This is a way to refer a bug. All large organization use some kind of Bug Management Systems and even at a place like Adobe, a bug Id is always unique across all products. This is really important since sometime one would tend to believe that why its important to have this unique across groups or across business-units or larger sections of a company. An Adobe Acrobat bug will never have the same ID or no as an Adobe Photoshop Bug. This is kept so that if somehow a bug of Photoshop is to be referred by Acrobat team then there is no confusion. So if you are setting up a new system, make sure that its kept as unique.

2. State – Open and Close. This is a top level way to say whether a bug is still Open (happens in a product) or is Closed (no longer happens in a product or is not relevant)

3. Status – These vary from system to system or company to company. Here, a basic rule is that if a bug is OPEN then its Status should clarify that which team needs to act. Here is one such example but make your own depending upon how many functions you have in your organization.

3.1 ToFix (Developer to act)
3.2 ToTest (Tester to act)
3.3 ToDefer (A bug committee to act, mostly a way to flag the committe to defer this bug for next version, ship with this bug)
3.4 ToTrack (Keep it open till something happens say getting a new drop of a dll from a 3rd party company or just track it over days to see if you see this bug again)
3.5 ToBuild (Deverloper has fixed it and Build guy has to do something so that it appears in a release build)

4. Product Name (self evident)
5. Product Version
6. Build No (which build this problem has, in some places the last ChangeList or RevisionNo of last check-in of ConfigManagement is treated as Build No, at other places Date is treated as Build No, some folks use a serial no kind of thing here)
7. Severity – Usually on a scale of 1-4 with each no varying in degree. Severity is a measure of ‘impact on system’. How does a particular bug affects the system.
8. Priority – Usually on a scale of 1-4. Its a measure of impact on customer.

Let me stop here and explain these two in little more detail through an example.

Example 1 – There is a typo in the name of the product in splash screen or on first screen. It has no impact on the system and probably everything will work. If www.google.com has a typo for the name of the ‘Search’ Button then ‘Search’ will still work but it would look real bad. So this kind of bug will be low severity but high priority. These need to be fixed immediately.

Example 2 – When we open 5000 files in Microsoft Word then not only MS word crashes the system itself gets halted. Its a high severity but low priority bug because someone having this kind of scenario is real dim. So this bug would be fixed later.

Example 3 – When we delete a mail in our mailbox in any mailing system, then some records which refer to that e-mail in index tables are not deleted and hence they can be seen in ‘Search Results’. This is an example of high severity high priority bug and needs to be fixed immediately.

9. Product Area / Sub Area – A better way to orgnize.
10. Reported By
11. Assigned to Dev Engineer name
12 QE Engineer name
13 Repeatibility
14 OS
15 Language
16 Keywords
17 Related To

The above are all small values which is mostly used to organize a bug report better. Now comes the major part.

18. Title – A short description of the problem. Usually not more than 10 words.

19. Problem – Whats the problem, this is different then Title. Title will just mention what could be happening. For example in last example,

Title – Deleted Mails can be Serached.
Problem – On Delete, we are not clearing the indexes and hence when we populate Search Results……

20. Description + Step-By-Step to Reproduce
21 Whats Actual Behavior
22 Whats expected
23 Any attachments (log files, snapshots, stack dumps)

There are some more fields but above is enough.

Once a bug starts to be worked upon then there is a need to track history and more importantly a way to capture ‘comments’.

24 Comments

When a bug gets fixed, there should be a way for the developer engineer to mention that in which future the fix can be seen

25. Fixed in : This is either a revision no or date or serial no. This has to follow the same convention as whats been used for writing Build No.

Ok. so we have a big list already. Guess I will save my further thoughts on this for an other day.

If you like reading this then subscribe to it by clicking to that Red button on the right pane and do leave a comment for fellow readers.