BUG

If it is not broken, don't fix it

What is a Bug?

I am not talking about creeping, crawling, flying critters. I am talking about the software bugs which are more creepy in a horrific sense. According to Wikipedia - A software bug is an error, flaw, failure or fault in a computer program or system that produces an incorrect or unexpected result, or causes it to behave in unintended ways. 

Why are they called BUG?

On the 9th of September, 1947, when the machine was experiencing problems at Harvard University, an investigation showed that there was a moth trapped between the points of Relay #70, in Panel F. 
The operators removed the moth and affixed it to the log. 
The entry reads: "First actual case of bug being found." The word went out that they had "debugged" the machine and the term "debugging a computer program" was born.
This is how the first computer bug was born (I mean died, I think).
But the term bug was in use long before the moth sacrificed itself for our careers. I do not know the whole story about its original origin. If you do, let me know!!

How to write a BUG Report?

The tester found something inconsistent and they just write up information about it. How hard can that be? It should be pretty straight forward while writing a bug report, it is not rocket science!!!
Let’s see…..

Bug name:

First and foremost the Bug needs a name to be identified by. This should be easy as pie if you follow a particular standard. The agenda for naming the bug should be for easy identification. I personally have seen my share of terrible bug names - 

1. I found a bug this morning
2. I logged in as user so and so and the uploaded a bunch of garbage and it seems like it is not acting as it should be, I have to take my daughter for her recital. keep me posted.
3. Crash
4. Bug in USA
5. Login in not working
6. Login not as expected.

Some of the above examples are good, some are bad, some are very, very ugly. But the key is to be consistent across the teams. The key is to be able to identify the issue easily. It should not be like finding a needle in a haystack.

My suggested guideline would be take the followign into consideration.

1. Application
2. Page
3. Activity
4. Account
5. A particular state of the application
6. Issue that is found.

Examples:

Application: Account: Crash (this indicates that in an application, while using a specific account only an issue occurs)

Application: Page: Activity: Error (this indicates that in an application, while on a page, performing a known activity and error is seen)

Application: Particular State: Issue is found (this indicates that in an application, when the environment is set to a particular state only the issue is found)

More Examples:

Gmail: Draft: Delete from list: does not delete the draft window.

Gmail: Draft: Delete from draft window: does not update the list immediately.

Describe the issue

2 + 2 should be 4, but 2 + 2 results in 6.

So, the tester writes up a bug saying 2 + 2 does not result in what is expected. Now, is this enough?
It may not be, because the person who is validating this bug is new to the project and does not know what the expected result is and he does not get any information about what the actual result was. Even if he did and the developer who works on it fixes it, the tester for this issue is re-assigned to verify may not be the reporter and won’t know which steps to execute and which result to expect.
One should keep in mind that the developer of the application is not always the one who is fixing the issues. Fixing the issue is not a matter of days. It could take months. A lot happens and the knowledge related to reproducing issue and re-testing the fixed bug should not be lost.

So, let’s re-wright the bug .....
Expected Result –
Answer is 4

Actual Result –
Answer is 6

Now, is this information enough?
Not enough. We also need to specify the exact steps to execute.

1. Click on button “2”
2. Click on button “+”
3. Click on button “2”
4. Click on button “=”

Expected Result –
Answer is 4

Actual Result –
Answer is 6

Now, this should be enough information, Right!!
Not quite.

1. How did the user get to the application with the buttons and all? Making sure the application was installed correctly is important to analyze the root cause.
2. Which environment was he using? A project could several databases! Making sure the application was pointing to the right back-end is important.
3. Which build was in use? A development cycle has tons of builds before the blessed build is released to the public.

We need to specify this information too –
App: 123 (the company could have several applications)
Environment: QA2 (company will have multiple environments)
Build: loki_234.1 (the project will have multiple builds)
Language: English (the application may be displayed in multiple languages)
Operating system: Linux (the project may be supported for multiple OS)
Reproducible: Yes / No (some bugs show up only once)
Pre-requisites: Application is installed and turned on 

Steps to reproduce:

1. Click on button “2”
2. Click on button “+”
3. Click on button “2”
4. Click on button “=”

Actual Result –
“6” displays in the answer field.

Expected Result –
“4” displays in the answer field.

Now, this should be enough. Right!! Well, it could be, unless we are facing a stranger situation.... (a few examples below)

 ...........If the Expected result is not defined anywhere and no one knows about what it should be what should the tester do?

The tester can specify a suggested result.
Suggested Result –
 “4” displays in the answer field. because in the real world that is how math works.

..........If the Expected result is not defined anywhere and no one knows about what the actual result should be, what should the tester do?

The tester can raise a question.
Question –
What should display in the answer field?

..........If the issue occurs or rectifies upon one or more actions, should the user specify the actions?

Absolutely, YES. The tester could add a Note.

Note –
This issue occurs only when the button “=” is clicked on for final calculation.
Or
Click anywhere on the page and “4” displays in the answer field.

How to specify Pre-Requisites?

It is a good idea to maintain a bug template with pre-filled information in a notepad. This way you can just copy paste the usual values and edit the few values that are different from usual.

Registered user, not registered, if registered, what kind of user, what is the ID, etc.
User has a valid credit card (mention CC No. etc)
User lives in a specific country.

What is ideal way to write the steps?

It is best to specify in plain English each and exact user actions. Clicked here, dragged there etc. 
It is not ideal to say things like –

• Try to add 2 and 2
• Adding 2 and 2

Because there could be many ways to execute the above functions. We need the exact user actions that caused the issue. So, be very specific. You understand the steps and the process. It is time to get the audience of the Bug report to understand too.

What Attachments are necessary?

1. It depends again upon the bug found. If it is meticulously and easily reproducible, specifying the steps would suffice.
2. If it is a UI issues, definitely log a picture. I recommend using MS-Paint for Windows and Kolour Pain for Linux.
3. If it is a UX issue, try to get a video while executing the steps. I recommend debugmode - WINK for Windows. I don't have good enough tools for capturing the screen video on Linux or for Mobile applications that are under development. (Still exploring.)
4. If it is a crash or sporadic behavior - Depending upon the application and the services the application uses, gerp files or log files and attach them to the bug. And always remember to note down the time of the bug occurrence.

Hang in there...

Once you get the hang of it, it wont seem difficult to log a bug. 

The things to remember is - As a developer's assistant you have to try to get as much information as possible to the developer to be able to fix the issue.

What is the BUG life Cycle?

Depends upon the company that produced the bug. The bug life cycle is unique to every company and every project. But the typical life cycle –

1. Bug is born (noted in a project management tool),
2. Bug is accepted or rejected
3. Rejected bug is closed
4. Accepted bug is assigned to a Developer for fixing or kept in a backlog to be fixed at a later time.
5. The fixed bug is returned to the tester for verification that is does not exist anymore.

 Sounds simple, Right!! Just like anything that sounds simple but is complicated in practice, the bug life cycle is complicated too. But don’t worry, what doesn't kill you will only make you crazier.

You found a BUG!! Now what?

A software bug is an error, flaw, failure, or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways. (Wiki)
You stumbled across something that feels like a bug. What do you do?
It could be - and unexpected issue, ugly defect, inanely inconsistency, clearly an anomaly.

Gather Information

1. As soon as you find a bug, get a screenshot, video, log file etc.
2. Pen down the user actions that caused the issue too. 
3. (Do not miss out on a chance to get information about a bug while it is staring you in the face)

Reproducible or not

1. Spend some time to reproduce the bug, 
2. You might have forgotten the exact steps. Try and try for a little bit.
3. If reproducible consistently mark it Reproducible
4. Certain bugs are not reproducible consistently. But that is ok, since you collected much information you needed to log the bug,
5. Log the bug and mark it Not Reproducible. 

Search for similar information

1. Search your bug tracking tool for similar issues. 
2. We do not want to log the same issue twice!!
3. If a similar issue or the same exact issue exists - make sure they are relevant to the current product and still belong.

If same issue exists and closed

1. Certain similar bugs could be from months ago and closed, this means the bug is a duplicate, but it still needs to be logged because the fix had somehow broken.
2. Go ahead and log it and link the new issue to the old one.
3. Do not re-open the legacy bug.

If same issue exists and open

1. If you find a similar bug logged recently for the current project - 
2. Study the bug and make sure enough information is logged
3. If the bug does not contain enough info, provide the information you just collected and update the bug as necessary. (Our intention is to make sure the bug is fixed, not who found most bugs)

If similar issue exists and open

1. If you found a bug that is similar but not an exact replica, go ahead and log the bug and link the issues as related.

No Similar issues found

1. If no prior issues are found, it is your turn to log a bug.
2. Log the bug in a ticket

You are not yet done

The more you explore, the more information you will find about the bug.

Reproduce issue on other - 

1. Browsers - Is it consistent among all browsers
2. Accounts - Is it specific to certain accounts?
3. Builds - When did this issue first show up (if unsure, the bug was a result of the current build)
4. Environments - Is it environment specific?
5. Security Roles - Are other security roles affected by it?
6. Languages - Non- English languages have a habit of displaying lopsided!!
7. Marketplaces - If applicable.

Collect this information and update the ticket. 

New Bug tickets may also be required. Log more issues and link them as necessary.

Bug Name

First and foremost every Bug needs a unique name to be identified by. 

             This should be easy as pie if you follow a particular standard. 

As soon as the developer looks at the bug, they should be able to identify where the issue occurs.

             The agenda for naming the bug should be for easy identification. 

Typical stakeholders for a bug - other QA members, QA leads, QA managers, Developers, Project Managers, Business Analysts, etc.

Terrible bug names -

1. I found a bug this morning
2. I logged in as user so and so and the uploaded a bunch of garbage and it seems like it is not acting as it should be, I have to take my daughter for her recital. keep me posted.
3. Crash
4. Bug in USA
5. Login in not working
6. Login not as expected.

Some of the above examples are bad, some are very, very ugly. 

The key is to be consistent across the teams. 

The key is to be able to identify the issue easily. 

It should not be like finding a needle in a haystack.

What should make to the Bug name

1. Application
2. Page
3. Activity
4. Account
5. A particular state of the application
6. Issue that is found.

Examples:

Application: Account: Crash - indicates that in an application, while using a specific account only an issue occurs

               Example :

                   Shopping: New Account: Add to cart: Crash

                           - Issues occurs with a certain account and action.

Application: Page: Activity: Error - indicates that in an application, while on a page, performing a known activity, an error occurs.

               Example :

                   Shopping: View Cart: Delete item: does not update the list immediately.

                           - Issues occurs on a particular page, with a certain action.

Application: Particular State: Issue is found - indicates that in an application, when the environment is set to a particular state only the issue is produced.

               Example :

                    Yahoo: language - French: char ' displays as $ 

                           - Issues occurs all over the application, not just on one page.

Advantages of having a naming convention in place for Bugs - 

1. Search for issues
2. Filter issues based on application, account, state, issue, etc.
3. Group and organize related issues
4. Link similar issues
5. Create stats for issues.
6. ETC.

Bug Description

Scenario:

             2 + 2 should be 4, but 2 + 2 results in 6.

The tester writes up a bug with description - 2 + 2 does not result in what is expected. 

Now, is this enough?

It may not be, because 

Issues

1. The person who is validating this bug may be new to the project 
2. The expected result is not known to the developer or other looking at it.
3. The developer assigned to fix the issue does not know the actual result was. 
4. A different tester is assigned to verify the issue. They may not know which steps to execute and which result to expect.

One should keep in mind that the developer of the application is not always the one who is fixing the issues. Fixing the issue is not a matter of days. It could take months. A lot happens and the knowledge related to reproducing issue and re-testing the fixed bug should not be lost.

Expecting others to just know what to expect and understand a bug is just bad standards and poor understanding of a team effort.

If it is not broken, don't fix it