Introduction to Defect Life Cycle in Software Testing

As you might be aware by now that test execution is the phase where the tester would be actually executing 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. Nowadays there are tools available for test execution, tools like – Quality Center, Microsoft visual studio and so on. The actual execution process of performing each step to compare actual and expected result remains the same for the functional tester irrespective of tools used. In this article will see about defect life cycle in software testing.

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

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

How to log a defect?

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

There are some of the mandatory fields which 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

Defect Life cycle starts from logging a new defect. Whenever a defect is logged, it goes in “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 defect life cycle process to assign it directly to a respective developer and at some places the defect is first assigned 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

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, Defect detailed description are the fields which helps the stakeholders to understand the defect in one go. Defect Summary should always have only the high level information of the defect. At the same time it should have sufficient information to describe the overview of defect in one line.

Defect description is the place where 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 the short overview of various elements of Defect Detailed Description –

Environment

Test environment where the defect was found. 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. The purpose of having various environments is that it provides flexibility within the development and test team to have the code deployed on any of the available environment to start off the testing on time.

There are times when the Product test (also called as system test) and UAT testing overlaps, hence having multiple environments is a must to continue testing in parallel.

There are cases when the development team needs an additional environment to debug the issues reported by the testing team. Also the develop team has a dedicated environment for unit testing task.

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

Scenario

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

Test Data

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

There are some scenarios in which a tester finds a defect using a specific data but the same issue is not reproducible using similar kind of data. This might happens due to data corruption, hence entering data gives a chance to find out the root cause of defect. A developer might not dig down to code level if data corruption is the case. This kind of defect can be converted to data defect.

Expected & Actual Result

This is the highlight of detailed description field where a tester proves that the error encountered is indeed a defect. Clearly mentioning the expected result makes the things clear for every stake holder to consider the error as a defect. Imagine a defect is logged with all the details but it does not specifies the expected outcome of the scenario!

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

Reference to files/data

Sometimes the defect involves generation of file or input as a file. In this kind of scenarios, tester is supposed to provide information of the file which was used and that caused the issue in application. These files can be attached using the defect management tool or the reference for the same can be provided. These reference locations should be accessible by all stakeholders.

Reference to snapshot

Snapshots play very important role when you want to show them the exact page break error message as displayed on the screen or when you want to show the screen navigation details. Snapshot gives quick idea about the defect encountered, screen on which defect was found, data used on the screen and so on. Every defect management tools has provision to attach the snapshots. Sometimes tester might attach the Excel spreadsheets or word documents as well.

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

New – Open

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

New – Return to Testing.

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

This is the scenario where a precise requirement document helps everyone in the team to come to the conclusion if the defect logged was an invalid or a valid one. Referring to requirement documents helps tester as well as developer to come on the same conclusion and it really eases up the discussion process.

There are scenarios where the correctness of design and requirement documents is questioned while referring these documents in times of defect discussions, at such times going back to Business Analyst is considered as the best option to clarify the queries.

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

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

Open – Ready for Deployment

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

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

Development
Defect Life Cycle in Testing
Deployment (or sometimes called as 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, defect is first assigned to Test lead and he/she in turn assigns it to individual tester however at some places, defect is directly assigned to 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 tester’s plate. Testing team will validate the defect and there are 2 possibilities, either the fix would work correctly or the same issue is encountered again. Depending upon the outcome defect can move to following statuses –

Ready SIT Testing – Closed

Ready SIT Testing – Reopen

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

Reopen status is same as “New” defect status.

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

Defect life cycle challenges

Deciding on defect severity – this is one of the common topic of discussion (often fights) among testers v/s developers.
Defect is not reproducible on developer’s system.
Defect raised on the scenario which is not mentioned in requirements and design documents.
Defect is found but the same cannot be raised as the occurrence of the scenario on production environment is not feasible.

How a tester should overcomes above challenges?

Severity is directly proportional to impact the defect is causing to the application, if tester cannot proceed due to the defect, it is surely marked with highest severity.
If there exists a workaround to continue testing, it should be marked as medium severity. Also besides considering the impact of further defect life cycle testing, severity can also be decided considering 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 to the current module is high so the defect should be marked with highest severity.
If a defect is not reproducible on developer’s system, there are chances that the development and test environment are not in sync. A defect reproducible on testing system is always considered as 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. It is always considered a best practice to consider the actual business scenarios instead of just following the test steps. Communication with business analysts and other product stakeholders plays an important role to log such defects.
There are scenarios when a tester finds out a gap in business logic during testing phase. Finding such gaps is again considered a big plus for a tester. Design gaps are usually handled via enhancements.
Enhancement – If a behavior needs to be changed during testing phase of 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 which a tester might test during ad-hoc testing which could actually be the invalid scenarios, considering the possibility of their occurrence in the production.

Who is tester’s best friend?

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

If the query is regarding the testing process, reaching out to test lead or test manager is advisable.

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

Since testing is a process which requires overall understanding of the system, communication helps a tester to get quick answer to the queries, it just depends on asking right questions to right individuals. Shying away from asking questions on the right time might lead to a defect to leak to production environment.

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

There are projects where testing team is equally important as the development team and in some scenarios there is more dependency on the test team than on development team. The later scenario is rare but it does exists at some workplaces. This has happened over the time and might be for some specific time period when the development team is not much experienced as compared to the testing team. There are people who understand the overall flow and functionality better than most of the other team members. Such an individual could be part of testing/development team. This is one of the factor which decides the dependency on a team/individual for the 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 tasks which he/she is expected to work on in day to day life. Based on this understanding, it is advisable to take decision to explore further areas which a tester might take up. There are always opportunities in the process to automate various flows. Creating small utilities can also help the team in big way. If a tester is good at programming, it is considered as a big plus. This opens opportunities for automation roles. Performance testing is also one of the career tracks for testers. Business analyst is another option. Good domain knowledge with good communication skills are the required skill sets to be a business analysts. Testing opens many opportunities for the testers to work on various domains, tools, processes and so on. 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 the areas of testing. Having certification from the standard vendor is an advantage to boost the career but the certificate alone cannot help you in the long run if not combined with the correct work experience.

Quiz Result
Total Questions	Correct Answers	Wrong Answers	Percentage