What are a Bug and Bug Report in testing?

What is a bug?

In short, a bug is a slang term for a software error. In turn, a software error is an error in a program or system that causes unexpected behavior of a program and, consequently, the result that does not match the plan. That is, a bug is discrepancy between expected and actual results. 

Bug's birthday 

The birthday of the first computer bug is September 9, 1945. It's a very entertaining story. The point is that a developer found a bug in a computer, which led to incorrect operation of the latter. 

Some humor 

"The glass is half full," says an optimist.  

"The glass is half empty," says a pessimist.  

"The glass is half empty and full at the same time because there is a hole in the glass that meets the specification," says a tester. 

All is clear with bugs now, but what is a bug report?  

A bug report is a document that describes and prioritizes a detected bug and helps to eliminate it. 

Bug Report Objectives 

1. To provide information about a problem. 

2. To prioritize it. 

3. To help fix the problem. 

One of the performance metrics of a tester is the number of bug reports that helped a development team fix bugs in a program. In other words, such errors that did have a negative impact on the work of users and were corrected by developers. 

A tester has no task to flood the team with countless bug reports. He is faced with the task of writing those that are really important for business and will help improve software being released. 

A very important point: a tester does NOT need to write one thousand useless bug reports, but it is necessary to make a report that will enable effective correction of errors. 

Why is this important?  

The amount of resources that we can spend on a project is invariable and does not depend in any way on how many bug reports we register. If a developer is constantly distracted by fixing bugs that do not affect the business (project) in any way, then he will have less time to implement the useful functionality of an application. 

Bug report logic   

The logic is quite simple:  

1. What have you done? (Steps to reproduce).  

2. What have you got? (The actual result).  

3. What was expected? (The expected result). 

Let's make it clear with an example  

I`ve turned on hot water, but it does not run, although it should.  

"What have you done?" – You`ve turned on hot water.  

"What have you got?" - Water does not run from the tap.  

"What did you expect to get?" - Water must run. 

Advantages of this logic  

1. Transparency. That is, you can`t deviate into the narrative style and write something superfluous in the report.  
2. It is easy to check a defect. This is because we clearly understand what had been done before we got the result.  
3. Even before playback, you can see if the described issue is a bug. Since we clearly know what the requirements are, and we will always be able to determine whether the described issue is an error.  
4. Getting rid of unnecessary communication. Since it can save time for higher priorities. 

Bug report life cycle  

We will examine the simplest life cycle, consisting of the following steps:  

• Open. The detected bug is registered in the bug tracking system.  
• In progress. Work has been started on the problem.  
• Fixed. The bug is fixed.  
• Verified. Confirmation that the bug is fixed.  
• Closed. The bug is closed. 

Tips to create a good bug report   

1. Create bug report titles that are understandable to all team members.  
2. Use search. Perhaps your colleague has already made the same bug report. And why do the project and the customer need several identical bug reports?  
3. Use formatting for the readability of a bug report.  
4. After you have registered a bug report, be sure to inform the entire team about it and separately - the person who is responsible for fixing the bug.