Defect/Bug Life Cycle

Defect Life Cycle:

• Defect life cycle, also known as Bug Life cycle is the journey of a defect cycle, which a defect goes through during its lifetime.
• It varies from organization to organization and also from project to project as it is governed by the software testing process and also depends upon the tools used.
• Defect Life Cycle is a cyclic process, which describes how a defect or bug passes through different stages from the identification stage to the Fixing stage. it begins when a tester finds or logs a bug and it ends when the bug is fixed.
• If Developer reject a defect understand the reason why defect is rejected , if developer is correct we can close the defect or else we can discuss it with test lead or project lead and than reopen the defect.

Some of the familiar values used for defects, during their life cycle are :

• New : New defect is reported.
• Open : The developer is currently working on the defect.
• Fixed : The code changes are completed and the defect is resolved .
• Deferred : Developers will fixed the defect later.
• Duplicate : The defect is same like one of the previous defect. When previous is fixed it also fixed.
• Retest : the tester starts the task of retesting the defect to verify if the defect is fixed or not.
• Rejected : Developers did not accept the defect .
• Close : After re test if defect is working correctly .
• Reopen : After re test if defect is still exist then we reopen the defect.
• Not a Bug : If the defect does not have an impact on the functionality of the application, then the status of the defect gets changed to “Not a Bug”.
• There are others of course, and some groups might use combinations of these values (such as Closed-Fixed, Closed-WontFix, etc.).

Defect Report | Priority and Severity

Defect Report: 

• If application is not working as expected we can report that as defect in defect report. 
• A defect report is a document that has concise details about what defects are identified, what action steps make the defects show up, and what are the expected results instead of the application showing error (defect) while taking particular step by step actions.
• Defect Reporting, Defect Tracking, and Status Tracking is called Defect Management. Some companies use Manual Process (Excel workbook), and some companies use Tool-based processes for Defect Management. 
• Defect Management Tools Examples: Bugzilla / Issue-Tracker / PR-Tracker etc.
  Important fields of a Defect Report template:
• Defect Id :  It is a unique number for every defect we found while testing.
• Summary :  Full description of the defect .
• Detected By : Name of the tester who found the defect .
• Assigned to :  Currently the defect is assign to whom. When a tester found a defect the it has to assign to any developer.
• Severity : Severity defines how impactful a bug can be to the system. It can values either high or medium or low specifies the seriousness of the defect.
• Priority : Priority indicates how soon the bug should be fixed. It can values either high or medium or low specifies the importance of the defect or functionality. The defect are fixed based on priorities.
  
  
  
  Defect Status in defect life cycle is the present state from which the defect or a bug is currently undergoing. The goal of defect status is to precisely convey the current state or progress of a defect in order to better track and understand the actual progress of the defect lifecycle. 
• Build version : It show currently build version in which we are testing. We  can check this from release note document. 
• Module : In which module the defect is found.
• Environment :  The defect is found in which environment like : Test environment, UAT or Production environment.
• Defect Type :  Specify the type of defect like functional , network , data , performance or UI ( User Interface) etc.
• Reproduceable : It has value either YES or NO:

                YES: Every time the defect is occurring .
                NO: Most of the time its working correctly, only few cases it is failing and not able to reproduce  

• ( If the defect is non reproduceable we can take screen shot of the defect and report it along with the defect.)
• Reproduce Steps : Specify the navigation steps to reproduce the defect.

Test Execution Process | Environment setup

Test Execution:

• Test execution is the process of executing the test cases and comparing the expected and actual results.
• After developers finish the coding and give the build to the tester , tester will conduct the testing and validate the application as per the requirement.
• The developers will prepare the below document and give to the testing team during the build release :

SRN (software release note)
DD (Deployment Document)

• Tester deploy the build in test environment a per the instruction in the release document note .
• The build is deployed in the test environment either by tester or developer or n/w team. 

• As we know after build release 1st test should be performed is sanity test .
• After Sanity test is pass we will continue test execution and validate all the functionality.
• Test execution can be done either manual aur automation.
• Testing performed by tester without using any tools is called manual testing.
• Testing conducted with the help of tool is called automation testing.
• During execution validate all the test cases and specify actual result and status.
• If the status is fail we can report that as defect to the developers.

SRN (software release note)

• A release note refers to the technical documentation produced and distributed alongside the launch of a new software product or a product update.
• It briefly describes a new product or specific detail level changes included in a product update.
• A software release notes template is a simple document that companies use to document any changes to their product. Elements of release notes template are like : 
• Build version , build location , requirement in build , Precondition , environment , deployment steps , known issue , defect files , prepare by.

Requirement Traceability Matrix

Traceability Matrix:

• In this document the test cases are mapped to the corresponding requirement to ensure the coverage of test cases, to find any gap between requirement and test cases.
• It is also known as Requirement Traceability Matrix (RTM) or Cross Reference Matrix (CRM).
• It is prepared before the test execution process.
• This document is designed to make sure that each requirement has a test case. 
• The test engineer will prepare TM for their respective assign modules, and then it will be sent to the Test Lead. Then test lead consolidate all and prepare one TM document for project.

Goals of Traceability Matrix:

• It allows you to see if a requirement is fully documented or not. A requirement traceability matrix can even call attention to missing requirements. 
• It ensures that the software completely meets the customer's requirements.
• A traceability matrix can help in the effort to provide proper and consistent documentation for your team. 
• It helps in detecting the root cause of any bug.

Types of Traceability Matrix:

The traceability matrix can be classified into three different types which are as follows:  

• Forward Traceability
• Backward or reverse Traceability
• Bi-directional Traceability

Forward Traceability:

Forward traceability is used to map the requirements to the test cases.

• Not only this will establish that every requirement is being tested from top to bottom, but it will also assist in confirming that a project’s trajectory is sound. 
• The main objective of this is to verify whether the product developments are going in the right direction.

Backward or reverse Traceability:

You can make a backward traceability matrix by mapping test cases with the requirements. 

• The reverse or backward traceability is used to check that we are not increasing the space of the product by enhancing the design elements, code, test other things which are not mentioned in the business needs. 
• The main objective of this that the existing project remains in the correct direction.

Bi-directional Traceability:

Bidirectional traceability essentially combines forward and backward traceability into one document. 

• This type is useful because it establishes that each requirement has relating test cases. 
• It also evaluates the modification in the requirement which is occurring due to the bugs in the application.

Test Case Review Process and Guidelines

 Test Case Review : 

• Test case review process is an important process to follow in software testing. Test case should be effective and also follow the standards to write test case.
• After preparation of the test cases review are conduct to ensure the completeness and correctness of the test case, proper flow, and maximum test coverage.
• The test lead or project manager have to approve the test cases.
• During this review process, if the reviewer found any mistake, he/she writes it in a separate document, which is known as Review document and sends it back to the author.

Test Case Review Techniques : 

• Self-review: This is carried out by the tester who wrote the test cases. By looking at SRS/FRD, he/she can see if all of the requirements are met or not.
• Peer review:  Before test lead the test cases reviewed by another team member who is not familiar with the system is called peer review. Maker and Checker are two other names for the same thing.
• Supervisory review: This is done by a team lead or project manager who is higher in rank than the tester who wrote the test cases and has an extensive understanding of the requirements and system.

Common mistakes which are check during Test Case Review  : 

• Incomplete Test Cases. Missing negative test cases. No Test Data. Inappropriate/Incorrect Test data.
• Spelling errors can sometimes cause a lot of confusion or make a statement difficult to grasp.
• While review process, it is very important to check whether all the standards and guideline are properly followed.
• If proper template is followed then it becomes easy to add/modify test cases in future and test case plan looks organized.
• If the grammar is incorrect, the test case can be misinterpreted, leading to incorrect findings. 
• Test cases should have a very simple language which is easy to understand.
• Replication: It refers to the duplicate test cases removal. It is possible that two or more test cases test the same thing and can be merged into one, this would save time and space.
• Test case which are uselessness due to change in requirements or some modifications. Such test cases must be removed.

Test Case Repository  : 

• A test case repository is a centralized location where all the baseline test cases (written, review, and approved) are stored.
• Test repository comprises test cases that encompass all key possibilities of permutations and combinations in workflow execution and transaction, ensuring that all variations in system and user interactions are covered.
• A test case repository is used to store the approved test cases only.
• Any test engineer wants to test the application, then he/she needs to access the test case only from the test case repository.
• If we do not require any test case, we can drop them from the test case repository.
• Each version have a separate test case repository.