What is a Bug, Defect, Error and Fault? What is a Defect / Bug Report?

Error, defect, bugs and fault are commonly used terms in Software Testing. People new to testing have many questions regarding the usage of these terms.

In this article we will understand the following:

  1. Error, Fault, Defect, Bug
  2. Examples for Error, Defect and Bug
  3. What Is A Defect/Bug Report? Why is it necessary?
  4. Defect Details
  5. When Do Defects Arise in Software Testing?
  6. Cost of Defects in the Software Development Life Cycle (SDLC)


Let us understand the difference between Error, Fault, Defect and Bug by studying each one separately.

Error: An error is a mistake made by the developer during the time of development or coding. An error can be technical like a syntactic error or a logical error.

An error can also occur when the actual result deviates from the expected result that is based on the software development requirement specification given by the customer.
What is Defect bug error fault

Fault: Faults occur due to an error in the program. It is the error or mistake due to which the software behaves in an unexpected or unpredictable manner which is not in line with the desired output.

Defect: An error found by the testing team during the testing phase is considered as a defect. It could be a technical issue which has nothing to do with the expected result or an issue where the actual result is not meeting the expected result.

The defects are then reported to developers via bug tracking tools like JIRA, Bugzilla, HP ALM and so on.

Bug: When a defect that has been assigned to the developer is accepted by the developer then it is considered as a bug. Depending upon the priority and severity of the bugs, developers will fix it and re-assign it to the testing team for re-testing.

Testers will re-test the bug and if the bug is fixed, will close it. If the bug still exists, then they will re-open it and assign it to the developers again. This process will continue till all the bugs are fixed and closed. We will look at the different statuses a bug can have in another article.

In day to day life, developers and testers use the terms bug and defect interchangebly. They may not distinguish them from one another. For example, the tester may say “I have logged a bug” or the developer may say “I have fixed the defect”.

It is still required for the development team to accept a bug/defect before it is fixed.

Examples for Error, Defect and Bug

Consider for example, there is requirement for an ecommerce application that says that if the total billed amount for purchases made through the website is greater than $500 but less than or equal to $800, the customer should get a discount of 5%. If the billed amount is more than $800 and less than $1000, he should get a discount of 6% and a discount of 8% should be given if the billed amount is more than $1000. A part of the code developed by the developer looks like:

 	 1. if(amt > 1000)
 	 2. {
	 3. 	finalamt = amt + (amt*0.08);
 	 4. }
 	 5. else if ( amt >800 && amt<=1000)
 	 6. {
	 7. 	finalamt = amt - (amt*0.06);
 	 8. }
 	 9. else if ( amt >500 && amt<=800)
 	10. {
	11. 	finalamt = amt - (amt*0.05);
 	12. }

Now when the tester tests the application, suppose the bill amount for the purchases made is $1500, he should get a discount of 8% and the final amount he needs to pay should ideally be $1380. However, they gets a final bill of $1620. Why is this so?

In this example, the error is the mistake made by the developer by typing “–” instead of “+” in line 3. Because of this, the application failed to run properly. When the tester executes this application, he finds that the result he expects to get is $1380 but instead, the actual result is $1680.

Tester does not have access to the code. Since the actual result differs from the expected result, the tester raises a defect. So, the defect is assigned to the developer and the error has been located. When the developer accepts the defect, we say that a bug has been logged.

What Is A Defect/Bug Report? Why is it necessary?

Defect / bug report contains the list of defects that have been found by the tester, along with the details of the defects. When a tester finds a defect they need to document the details of the defect and communicate this to the development team. This communication can take place through email or preferably by reporting the defect through a defect tracking tool like JIRA, Bugzilla etc.

Benefits of using a defect report

  • Defect report helps the development team (and testing team) to understand the defect
  • It also enables the teams to track the defect to closure
  • If the defect is not reported, it may be lost or its details forgotten, which may lead to the defect not being fixed

Details of the defect that are captured in the report, are explained below.

Defect Details

The following details are usually logged for a defect.

  • Defect Id – The unique identifier assigned to the defect / bug
  • Defect Description – A brief description of the defect
  • Steps to reproduce – The steps to be followed in order to reproduce the defect
  • Reported On – The date on which the defect was reported. This may also be called as Created Date.
  • Reported By – The name or user id of the person who reported the defect / bug. This may also be called as Created By.
  • Severity – This is the impact of the defect or bug. This can be minor, major or critical.
  • Priority – This can be low, medium or high. It is the priority or importance of the defect. We will cover the difference between severity and priority in detail in another topic.
  • Status – This is used to track the status of the defect / bug. The status can be New, Assigned, Open, Rejected, Fixed, Differed, Reopened, Verified or Closed. We will learn more about this in the defect / bug lifecycle.
  • Version – This is the version of the application in which the defect was found
  • Assigned To – The name or user id of the developer, to whom the defect was assigned
  • Closed On – The date on which was defect or bug was closed after verification

When Do Defects Arise in Software Testing?

There could be many reasons for software defects. A few of them are given below.

  • Lack of clear understanding of requirements
  • Poor knowledge of the developer
  • The Design document has errors
  • Poor quality of testing
  • Testing environment is setup in the wrong way
  • Software is not used in the right way, because of that defects occurred
  • Lack of knowledge on the part of customers (customers do not know exactly what they want from the software)

If the defects occur due to the mistake made by the development team during the implementation phase, then it is usually easy to fix them. The testers will spot these defects when they test the software, as the product is not designed according to the specification.

Developers can fix the bugs that are assigned to them and the testing team can re-test it to ensure the defects are fixed.

If the defect occurs do to error made in design phase, then you need to start the fixing process from the design stage. Requirements document may have to be checked again to locate the defects. All this makes it a little difficult to fix and can affect the overall cost and time schedule of the project.

When the defects are due to the lack of knowledge on part of the customer or due to unclear/incorrect requirements, then it becomes even more difficult to fix the defects. These defects are very costly and can make your estimation, cost and project schedule go haywire.

Cost of Defects in the Software Development Life Cycle

The cost of defects depend on two factors 1) Impact of the defect and 2) when the defect is found.

Let’s look at an example below to understand this well:

If you are in the requirement analysis phase and find that there is a bug or error in the requirement, then it is very easy to fix the issue and therefore the cost of fixing will be very low.

Similarly, if a bug in your design document is found during the design review or the coding phase, it is comparatively easy to fix and will not affect the overall cost of the software development too much.

However, assume that a defect due to incorrect requirements was missed in all the phases including testing stage and even the user acceptance testing stage. It was found only when the end users started using the software application. It not only creates a bad impression on the end user but also has a huge impact on the cost of fixing. Moreover, it is difficult to fix a defect at this stage.

These defects are costly to fix as you may need to re-do the design, development and testing. Changes to design are costly since it may affect other areas of the application and may require significant effort in subsequent phases.

Summary

You should now be able to clearly differentiate between a bug, a defect and an error. It is also important to know how to write a defect / bug report and as you have seen in this topic. We have learnt about when the defects arise and the cascading effect a defect has when found in the later stages of the Software Development Life Cycle.