EDUCBA

EDUCBA

MENUMENU
  • Free Tutorials
  • Free Courses
  • Certification Courses
  • 600+ Courses All in One Bundle
  • Login
Home Software Development Software Development Tutorials Software Testing Tutorial Defect Life Cycle in Software Testing
Secondary Sidebar
Software Testing Tutorial
  • Basics
    • What is Software Testing
    • Careers in Software Testing
    • Defect Life Cycle in Software Testing
    • Bug Life Cycle
    • Levels of Software Testing
    • Software Testing Life Cycle
    • Software Tester Work
    • Software Testing Principles
    • Software Testing Services
    • Testing Methodologies
    • Test Approaches
    • Types of Software Testing
    • What is a Bug in Software Testing
    • Benefits of Automation Testing
    • What is Automation Testing?
    • Types of Automation
    • Typical Journey of a Software Tester
    • Automation Testing Process
    • Mobile Automation Testing
    • Automation Testing Life Cycle
    • Software Quality Assurance
    • Software Quality Assurance
    • What is Test Environment?
    • Verification and Validation Testing
  • Types of Testing
    • Adhoc Testing
    • Types of System Testing
    • Manual Testing Types
    • Unit Testing Types
    • Unit Testing Benefits
    • Agile Testing
    • What is Agile Testing
    • Acceptance Testing
    • Stress Testing Types
    • Alpha and Beta Testing
    • Application Testing
    • Automation Testing
    • Automation Testing Advantages
    • Benchmark Testing
    • Black Box Testing
    • Domain Testing
    • Dynamic Testing
    • Ecommerce Testing
    • Fuzz Testing
    • Gray Box Testing
    • GUI Testing
    • Installation Testing
    • Interface Testing
    • Interoperability Testing
    • Mainframe Testing
    • Manual Testing
    • Mutation Testing
    • Monkey Testing
    • Negative Testing
    • Penetration Testing
    • Penetration testing phases
    • Penetration testing framework
    • Protocol Testing
    • Recovery Testing
    • Regression Testing
    • Mobile Penetration Testing
    • Accessibility Testing
    • Sanity Testing
    • Scalability Testing
    • Security Testing
    • Spike Testing
    • Stability Testing
    • State Transition Testing
    • Static Testing
    • Gatling Load Testing
    • System Integration Testing
    • Structural Testing
    • Locust Load Testing
    • System Testing
    • Control Flow Testing
    • Unit Testing
    • Cypress testing
    • Volume Testing
    • Web Testing Application
    • What is Exploratory Testing
    • What is Stress Testing
    • What is Usability Testing
    • White Box Testing
    • Types of White Box Testing
    • Compatibility Testing?
    • Use Case Testing
    • Beta Testing
    • Integration Testing
    • Non Functional Testing
    • Non Functional Testing Types
    • What is Functional Testing
    • Functional testing types
    • Cookie Testing
    • Alpha Testing
    • Boundary Value Testing
    • Equivalence Class Testing
    • Glass Box Testing
    • SOA Testing
    • Smoke Testing
    • Visual Testing
    • Visual Paradigm
    • Model-Based Testing
  • Testing techniques
    • Software Testing Methodologies
    • Black Box Testing Techniques
    • Static Testing Techniques
    • Test Case Design Techniques
    • What is Static Analysis
  • Testing tools
    • Manual Testing Tools
    • Visual Testing Tools
    • Automation Testing Tools
    • Functional Testing Tools
    • GUI Testing Tools
    • Penetration Testing Tools
    • Performance Testing Tools
    • SOA Testing Tools
    • Accessibility Testing Tools
    • What is QTP
    • Regression Testing Tools
    • Security Testing Tools
    • Test Management Tools
    • Defect Management Tools
    • Code Coverage Tools
    • Test Coverage Tools
    • Defect Tracking Tools
    • Continuous Integration Tools
    • Install Bugzilla
    • Test data generation tool
    • Unit Testing Tools
    • Web Testing Tools
    • Stress Testing Tools
    • Performance Monitoring Tools
    • Mobile Testing Tools
    • Responsive Testing Tool
    • Cross Browser Testing Tools
    • Risk Based Testing
    • Database Testing Tools
    • WinRunner
    • What is Squish?
    • CubicTest
    • What is WinRM?
    • Bugzilla Tool
    • Code review tools
    • Penetration Testing Open Source Tools
  • Advance
    • Cyclomatic Complexity
    • Decision Table Testing
    • Decision Tree Algorithm
    • What is Continuous Integration
    • Mantis Bug Tracker
    • Equivalence Partitioning
    • Gantt Chart Software
    • Acceptance Testing Types
    • Load testing tools
    • Install TestNG
    • Install Unity
    • Defect Management Process
    • Test Plan Template
    • Testing Interview Questions
    • Testing of Mobile application
    • What is Test Automation Frameworks
    • Test Automation Framework
    • Application of Automation
    • Test Automation Process
    • Automation Testing Roles and Responsibilities
    • What is Instruction Cycle?
    • What is Cucumber?
    • 15 Best Popular Bug Reporting Tools
    • What is Automated Testing?
    • Software Maintenance Types
    • Types of Penetration Testing
    • Software Reliability
    • Best Gantt Chart Software
    • Code Coverage
    • Branch Coverage
    • Decision Coverage
    • Statement Coverage
    • What is Test Case
    • Types of Test Case
    • What is Test Scenario
    • Formal Review
    • Alpha Beta Pruning
    • What is Cyclomatic Complexity?
    • Test Coverage
    • How to Write Test Case
    • Testing Documentation
    • Performance Testing Life Cycle
    • Test Harness
    • Test Strategy
    • Software Incident Management
    • What is Debugging
    • What is Defect?
    • Listeners in TestNG
  • Inteview Questions
    • Automation Testing Interview Questions
    • Manual Testing Interview Questions
    • ISTQB Interview Questions
    • Cucumber Interview Questions
    • Software Testing Interview Questions
    • Penetration Testing Interview Questions

Defect Life Cycle in Software Testing

By Priya PedamkarPriya Pedamkar

Defect Life Cycle in Software Testing

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?

Start Your Free Software Development Course

Web development, programming languages, Software testing & others

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 –

  1. Development
  2. Defect Life Cycle in Testing
  3. 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

  1. Deciding on defect severity – this is one of the common topic of discussion (often fights) among testers v/s developers.
  2. Defect is not reproducible on developer’s system.
  3. Defect raised on the scenario which is not mentioned in requirements and design documents.
  4. 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?

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.

Recommended Articles

Here are some articles that will help you to get more detail about the Software Testing so just go through the link.

  1. Software Testing Interview Questions
  2. Careers in Software Testing
  3. Software Tester Work
  4. Software Reliability
Popular Course in this category
Software Testing Training (11 Courses, 2 Projects)
  11 Online Courses |  2 Hands-on Projects |  65+ Hours |  Verifiable Certificate of Completion
4.5
Price

View Course

Related Courses

Penetration Testing Training Program (2 Courses)4.9
TestNG Training (4 Courses, 2 Project)4.8
Primary Sidebar
Footer
About Us
  • Blog
  • Who is EDUCBA?
  • Sign Up
  • Live Classes
  • Corporate Training
  • Certificate from Top Institutions
  • Contact Us
  • Verifiable Certificate
  • Reviews
  • Terms and Conditions
  • Privacy Policy
  •  
Apps
  • iPhone & iPad
  • Android
Resources
  • Free Courses
  • Java Tutorials
  • Python Tutorials
  • All Tutorials
Certification Courses
  • All Courses
  • Software Development Course - All in One Bundle
  • Become a Python Developer
  • Java Course
  • Become a Selenium Automation Tester
  • Become an IoT Developer
  • ASP.NET Course
  • VB.NET Course
  • PHP Course

ISO 10004:2018 & ISO 9001:2015 Certified

© 2023 - EDUCBA. ALL RIGHTS RESERVED. THE CERTIFICATION NAMES ARE THE TRADEMARKS OF THEIR RESPECTIVE OWNERS.

EDUCBA
Free Software Development Course

Web development, programming languages, Software testing & others

By continuing above step, you agree to our Terms of Use and Privacy Policy.
*Please provide your correct email id. Login details for this Free course will be emailed to you
EDUCBA

*Please provide your correct email id. Login details for this Free course will be emailed to you

Let’s Get Started

By signing up, you agree to our Terms of Use and Privacy Policy.

EDUCBA

*Please provide your correct email id. Login details for this Free course will be emailed to you
EDUCBA

*Please provide your correct email id. Login details for this Free course will be emailed to you
EDUCBA Login

Forgot Password?

By signing up, you agree to our Terms of Use and Privacy Policy.

This website or its third-party tools use cookies, which are necessary to its functioning and required to achieve the purposes illustrated in the cookie policy. By closing this banner, scrolling this page, clicking a link or continuing to browse otherwise, you agree to our Privacy Policy

Loading . . .
Quiz
Question:

Answer:

Quiz Result
Total QuestionsCorrect AnswersWrong AnswersPercentage

Explore 1000+ varieties of Mock tests View more