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.
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:
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:
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.
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”