Updated June 9, 2023

Introduction to Defect Life Cycle in Software Testing

As you might be aware by now, that test execution is the phase where the tester executes the test scripts. The process of execution of test scripts varies from company to company and might be different in different projects within the same company as well. Tools are available for test execution, like – Quality Center, Microsoft visual studio, etc. The actual execution process of performing each step to compare actual and expected results remains the same for the functional tester, irrespective of the tools used. This article will see about the defect life cycle in software testing.

What if actual behavior is not equal to the expected behavior?

A defect is logged when a tester finds that the actual testing result is not equal to the expected result.

How to log a defect?

Many tools are available nowadays. Some defect logging tools are ClearQuest from IBM, HP’s Quality Center, open-source tools like the defect life cycle in JIRA, and so on.

Some mandatory fields are common across the various defect logging tools. These fields are –

Defect life cycle Description
Defect life cycle Summary
Defect logged by
Defect Assigned to
Defect Severity
Defect Priority
Additional Snapshots
Release number/Name

Defect Life cycle

The Defect Life cycle starts with logging a new defect. Whenever a fault is logged, it goes into the “New” state.

Tester – New Defect

Whom to assign a new defect?

A Tester may assign a defect to a developer or a development lead. This decision of defect assignment varies from project to project. At some workplaces, there is a defect life cycle process to assign it directly to a respective developer, and at some places, the defect is first given to a dev lead, and the dev lead, in turn, assigns it to a developer.

Defect Assignment (New) – Defect Life Cycle Developer

Defect Assignment (New) – Dev Leadà Developer

Defect Analysis

The developer will analyze the defect to check if it is reproducible. Here the most important contribution from the tester is to include all the necessary details in the defect. Defect Summary and detailed defect description are the fields that help the stakeholders to understand the defect in one go. A Defect Summary should always have only high-level information about the defect. At the same time, it should have sufficient information to describe the overview of a defect in one line.

Defect description is where a tester is expected to include all the necessary information like Environment, Scenario, Test data used, Expected Result, Actual Result, Reference to files/data, and reference to snapshot.

Here is a short overview of various elements of the Defect Detailed Description –

Environment

Test environment where there is a defect. Often projects have multiple test environments where the test team performs testing. For example – AT (Assembly testing environment), PT (Product Testing environment), UAT (User Acceptance Testing environment), and so on. Having various backgrounds provides flexibility within the development and test team to deploy the code on any available environments to start the testing on time.

Sometimes, the Product test (also called the system test) and UAT testing overlap. Hence having multiple environments is a must to continue testing in parallel.

There are cases when the development team needs a different environment to debug the issues reported by the testing team. Also, the development team has a dedicated background for unit testing tasks.

Hence, with multiple environments, it is a must to mention in the defect a particular environment where the issue was found.

Scenario

A well-documented scenario has easy-to-read, easy-to-understand, and precise steps to be followed to replicate the defect. The scenario is the set of steps by the tester, which was the cause of a defect. Here a tester is expected to mention all the steps the developer can perform to reproduce the defect. Often there are times when the tester reports the defect, but the developer cannot replicate the same, and hence the defect gets rejected. This might happen due to incorrect steps/missing steps mentioned in the description. Clear steps help everyone to understand the defect and replicate it without having the dependency of reaching out to a tester to get inputs.

Test Data

A tester needs to mention the data used during the flow of testing, which leads to an issue. This information gives the developer a chance to use similar data to reproduce the defect and find the root cause for the same.

Some scenarios exist where a tester finds a defect using specific data, but the same issue is not reproducible using similar data. This might happen due to data corruption. Hence entering data gives a chance to discover the defect’s root cause. A developer might not understand the code level if data corruption exists. This kind of defect can convert into a data defect.

Expected & Actual Result

This is the highlight of the detailed description field where a tester proves that the error encountered is indeed a defect. Imagine a defect is logged with all the details, but it does not specify the expected outcome of the scenario! Mentioning the expected result makes things clear for every stakeholder to consider the error a defect.

Usually, a tester enters only the expected result may be in a line or two. However, it is very important to mention the source of the expected result. Source here a reference to the document where the expected result is mentioned. This could be a required document or a storyboard reference.

Reference to files/data

Sometimes the defect involves the generation of a file or input as a file. In this scenario, a tester must provide information about the file in use and the cause. These files can also be attached using the defect management tool or provided with a reference. These reference locations should be accessible to all stakeholders.

Reference to snapshot

Snapshots play an important role when you want to show them the exact page break error message displayed on the screen or when you want to show the screen navigation details. Snapshot gives a quick idea about the defect, location, data on the screen, etc. Every defect management tool has a provision for attaching snapshots. Sometimes tester might attach Excel spreadsheets or Word documents as well.

Returning to the defect life cycle, after assigning the defect to a developer, he/she will analyze it using the data in the defect item. These were the various components of defect logging and the best practices for each. If, as per the analysis, the issue is indeed a defect, the developer will “Open” the defect to work on its fix.

New – Open

A defect in Open status shows that it is on the development plate, and the developers are working on its fix. If the analysis finds out the issue logged is not a defect, this might happen when there is an understanding gap in the system’s expected behavior. If the analysis says the defect is invalid, the developer will reject the defect. Terminology is “Rejected” or “Return to Testing”.

New – Return to Testing.

How should the tester validate if the defect was indeed invalid?

This scenario is where a particular requirement document helps the team conclude if the defect is invalid or valid. Referring to requirement documents helps the tester and the developer come to the same conclusion, easing the discussion process.

There are scenarios where the correctness of design and requirement documents is questionable while referring to these documents during defect discussions. At such times, going back to Business Analyst is the best option to clarify the queries.

As a best practice, requirements and design documents should always be up to date to refer to them without any ambiguities.

In “Open” status, the development team works on fixing the defect. After fixing the defect, the status changes to “Ready for Deployment”.

Open – Ready for Deployment

Deployment is the process where the changes are uploaded to the server so that the testing team can work on the fixed version of the code. Usually, every project has a separate deployment team for this task.

So on a high level, a software team mainly consists of these 3 groups –

Development
Defect Life Cycle in Testing
Deployment (or sometimes called Build team)

Once the build is deployed and the defect is again available for retesting, it’s assigned to an appropriate tester for the retesting task.

Defect Assigned to – Test Lead.

Test Lead – Individual Tester.

Defect Assigned – Individual Tester.

At some workplaces, the defect is first assigned to the Test lead, and he/she, in turn, assigns it to an individual tester. However, in some places, the defect is directly assigned to the tester who would be testing it or the one who had raised the defect.

Status here changes from Ready for Deployment – Ready SIT Testing.

Now the defect is in the tester’s plate. The testing team will validate the defect, and there are 2 possibilities, either the fix would work correctly, or the same issue would be encountered again. Depending upon the outcome defect can move to follow statuses –

Ready SIT Testing – Closed

Ready SIT Testing – Reopen

In both the above scenario, the tester must add the comments of testing. This includes mentioning the scenarios tested and the data used. If the defect re-opens, the tester should provide the exact steps, which again led to the error.

Reopen status is the same as the “New” defect status.

Once the defect re-opens, it will follow the same cycle again.

Defect life cycle challenges

Deciding on defect severity is a common topic of discussion (often fights) among testers v/s developers.
A defect is not reproducible on the developer’s system.
The defect raised in the scenario is not in the requirements and design documents.
A defect cannot be the scenario’s occurrence in the production environment.

How should a tester overcome the above challenges?

Severity is directly proportional to the impact the defect is causing on the application. If the tester cannot proceed due to the defect, it is surely the highest severity.
If a workaround exists to continue testing, it should be a medium severity. Also, besides considering the impact of further defect life cycle testing, severity can be decided regarding the situation where an entire module is failing. In this case, even though the testing of another module can be carried out but the severity of the current module is high, so the defect should be marked with the highest severity.
If a defect is not reproducible on the developer’s system, there are chances that the development and test environment are not in sync. A reproducible defect on the testing system is always a valid defect.
There are situations when a defect is logged considering the overall business scenario, but the direct scenario is not mentioned in the requirements or design document. Communication with business analysts and other product stakeholders is important to log such defects. Viewing the actual business scenarios is always a best practice instead of just following the test steps.
There are scenarios when a tester finds out a gap in business logic during the testing phase. Finding such holes is, again, a big plus for a tester. Design gaps are usually via enhancements.
Enhancement – If a behavior needs to be changed during the testing phase of a software life cycle, an enhancement is created, which can be taken in the current or next release considering the timelines and bandwidth of the development and test teams.
There are some scenarios that a tester might test during ad-hoc testing, which could be invalid scenarios, considering the possibility of their occurrence in production.

Who is the tester’s best friend?

Where should a tester go in case of ambiguity? The answer depends on the type of query. If a question is regarding requirements, it is advisable to first discuss within the team to correct understanding of the system by consulting senior members. The next point of contact should be Business analysts.

Contact the test lead or manager if the query concerns the testing process.

If the query is regarding understanding the technicalities of the application, a development team member could be the right person to go to.

Since testing is a process that requires an overall understanding of the system, communication helps a tester get quick answers to queries. It just depends on asking the right questions to the right individuals. Shying away from asking questions at the right time might lead to a defect leaking into the production environment.

How important is the role of a tester in the corporate today?

There are projects where the testing team is equally important as the development team, and in some scenarios, there is more dependency on the test team than on the development team. The latter scenario is rare, but it does exist in some workplaces. This has happened over time and might be for some specific time period when the development team is not as experienced as the testing team. Some people understand the overall flow and functionality better than most other team members. Such an individual could be part of the testing/development team. This is one of the factors which decides the dependency on a team/individual for a specific project.

What is the career path for a tester?

An individual might take some time to understand the overall testing process, domain, and other daily tasks that he/she needs to complete. Based on this understanding, exploring further areas that a tester might take up is advisable. There are always opportunities in the process to automate various flows. Creating small utilities can also help the team in a big way. It is a big plus if a tester is good at programming. This opens opportunities for automation roles. Performance testing is also one of the career tracks for testers.

A business analyst is another option. A business analyst must have good domain knowledge and good communication skills. Testing opens many opportunities for testers to work on various domains, tools, processes, etc. It just depends on an individual to pick up and start going deep inside one of the testing core areas. There are many certifications specific to various tools to specialize in one of the testing areas. Thus, having certification from the standard vendor is an advantage to boost the career. But the certificate alone cannot help you in the long run without the correct work experience.

Quiz Result
Total Questions	Correct Answers	Wrong Answers	Percentage