Software testing is a process to investigate the developed software and identify the flaws or errors in it. This process aims not only at find faults in the software but also to improve the software in terms of efficiency, accuracy and usability. Identifying bugs early could save much product cost and it provides an error free product.

Before we delve into the life cycle of a defect, let’s get familiar with the term bug. Being an informal term for defect bugs are nothing but a fault in the software. If the developed software does not meet the requirement provided by the customer then we call it a bug or defect.

Different types of bugs encountered in a software

• Functional Errors - If the software’s functionality does not behave as per expectation, then these are considered functional defects.
• Missing commands - Sometimes it happens that you cannot close a pop-up window without performing some unwanted actions. This is a missing command error, that can be not only the absence of button but also the absence of a logical option.
• Run time Errors - A program crash is the most noticeable type of runtime error, since the program unexpectedly quits while running. Crashes can be caused by memory leaks or other programming errors.
• Communication problems - Communication errors occur when there is a breakdown in communication between the software and the end user, which causes usability issues. If the software comes with undocumented features, then communication errors are bound to occur during its use.
• Logical errors - Logical error is a mistake in a program’s source code that results in incorrect or unexpected behaviour.
• Inappropriate error handling - Errors can occur while using a software, and these need to be handled properly. Failing to do so leads to information leakage and render the system vulnerable to security threats. It is also important to include in error messages, the steps users have to take in order to resolve the issue.
• Calculation issues - This type of problem can be caused by a lot of reasons, e.g., wrong algorithm, data type mismatch or just coding errors.

How to record a defect?

It is crucial that the identified defects are accurately recorded and passed on to the developer to be actioned upon. Hence the defect log comes into play, which enables storage and tracking of defects. This is generally done using a defect tracking tool, nevertheless a defect tracking spreadsheet can also be used based on your team’s preference. Let’s take a look at the attributes constituting a defect log.

Defect Summary: Summarize in brief the identified issue.

Defect Description: Describe the bug clearly to the developer for better understanding.

Steps to reproduce: List each and every step to be followed to recreate the defect.

Expected Result: Specify how the software should behave as per requirement.

Actual Result: Define how the software actually behaves while testing.

Build No: Mention the software build no. or the version.

Assigned To: Assign to any developer who is working on the software creation.

Reported By: State the name of the tester who records the defect.

Reported On: The bug creation date.

Status: New/Open/Active (Depends on the Defect tracking tool you use).

Environment: Environment in which the test is performed.

Severity: The degree of impact a defect has on the development or operation of a component. Higher effect on the system functionality will lead to the assignment of higher severity to the bug. In Software Testing, Defect severity can be categorized as below:

• Critical: This defect implicates complete shut-down of the process, nothing can proceed further.
• Major: It is a highly severe defect and collapses the system. However, certain parts of the system remain functional.
• Medium: It causes some undesirable behaviour, but the system is still functional.
• Low: It won't cause any major break-down of the system.

Priority: Priority is defined as the order in which a defect should be fixed. Higher the priority, sooner the defect should be resolved. Defects that leave the software system unusable are given higher priority over defects that cause a small functionality of the software to fail. Defect priority can be categorized as below:

• Low: The defect is an irritant but repair can be done once the more serious defects are fixed.
• Medium: During the normal course of development activities defect should be resolved. It can wait until a new version is created.
• High: The defect must be resolved as soon as possible as it affects the system severely and cannot be used until it is fixed.

Note: It is best practice to include a screenshot or video of the defect while creating it. If it is a mobile application it's good to include the tested device details and OS version of the tested device.

Life Cycle of a defect

A Defect life cycle, also known as a Bug life cycle covers the various states a bug goes through. This starts as soon as a new defect is found by the tester and comes to an end when the tester closes that defect assuring it cannot be reproduced again.

New: The first state of the Defect Life Cycle. When a new defect is found, it falls in a ‘New’ state. Testing and validations are performed on this defect in the later stages of the Defect Life Cycle.

Assigned: The newly created defect is assigned to the development team to be worked on.

Open/In Progress: The developer starts the process of analyzing the defect and works on fixing it, if required. If the developer feels that the defect is not valid then it may get transferred to any of the below four states namely Duplicate, Deferred, Rejected, or Not a Bug-based upon the specific reason.

Fixed: When the code is fixed by the developer the defect can be marked as ‘Fixed’.

Ready for QA: After fixing the defect, the developer assigns the defect to the tester for retesting the defect at their end.

Retest: At this point, the tester starts the task of retesting the defect to verify if the defect is fixed accurately by the developer as per the requirements.

Reopen: If the issue persists then it will be reassigned to the developer for verification and the status of the defect is changed to ‘Reopen’.

QA Test Passed: If the tester feels that the defect has been fixed accurately then the defect status becomes QA test passed.

Closed: When the defect does not exist any longer, the tester changes the status of the defect to ‘Closed’.

Duplicate: If the defect is repeated twice or corresponds to an existing defect, the status is changed to "duplicate."

Rejected: If the developer feels it is not a valid defect the status is changed to "rejected".

Deferred: If the present bug is not of a prime priority and if it is expected to be fixed in the next release, "Deferred" status is assigned to such bugs.

Not a bug: If it does not affect the functionality of the application then the status assigned to a bug is "Not a bug".

Now that we know what a bug is and how to record it, bring it all together and you can create a well-planned bug report. It is always good to have a peer review while generating a new bug report. “Uncover more bugs and upgrade your software quality”