What’s defect?
Defects life cycle?
Defects states?
Defects priorities ?
Defects reporting?
Defect sample template ?
Defects Classification?
Defect types?
Defect: A Defect, in simple terms, is a flaw or an error in an application that is restricting the normal flow of an application by mismatching the expected behavior of an application with the actual one.
•The defect occurs when any mistake is made by a developer during the designing or building of an application and when this flaw is found by a tester, it is termed as a defect.
•It is the responsibility of a tester to do thorough testing of an application to find as many defects as possible to ensure that a quality product will reach the customer.
Defect Life Cycle in detail:
•The Defect Life Cycle, also known as the Bug Life Cycle, is a cycle of defects from which it goes through covering the different states in its entire life. This starts as soon as any new defect is found by a tester and comes to an end when a tester closes that defect assuring that it won’t get reproduced again.
•Defect Workflow •It is now time to understand the actual workflow of a Defect Life Cycle with the help of a simple diagram as shown below.
Defect States:
1) New: This is the first state of a defect in the Defect Life Cycle. When any new defect is found, it falls in a ‘New’ state, and validations & testing are performed on this defect in the later stages of the Defect Life Cycle.
2) Assigned: In this stage, a newly created defect is assigned to the development team to work on the defect. This is assigned by the project lead or the manager of the testing team to a developer.
3) Open: Here, 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 appropriate then it may get transferred to any of the below four states namely Duplicate, Deferred, Rejected, or Not a Bug-based upon a specific reason. We will discuss these four states in a while.
4) Fixed: When the developer finishes the task of fixing a defect by making the required changes then he can mark the status of the defect as “Fixed”.
5) Pending Retest: After fixing the defect, the developer assigns the defect to the tester to retest the defect at their end, and until the tester works on retesting the defect, the state of the defect remains in “Pending Retest”.
6) 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 or not.
7) Reopen: If any issue persists in the defect, then it will be assigned to the developer again for testing and the status of the defect gets changed to ‘Reopen’.
8) Verified: If the tester does not find any issue in the defect after being assigned to the developer for retesting and he feels that if the defect has been fixed accurately then the status of the defect gets assigned to ‘Verified’.
9) Closed: When the defect does not exist any longer, then the tester changes the status of the defect to “Closed”.
10)Rejected: If the defect is not considered a genuine defect by the developer then it is marked as “Rejected” by the developer.
11)Duplicate: If the developer finds the defect as same as any other defect or if the concept of the defect matches any other defect then the status of the defect is changed to ‘Duplicate’ by the developer.
12)Deferred: If the developer feels that the defect is not of very important priority and it can get fixed in the next releases or so in such a case, he can change the status of the defect as ‘Deferred’.
•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”.
Defect Priorities:
•The QA team typically sets the priority status when the defect is brought to the attention of the development team and is based on the end user’s requirements.
•Low Priority: The defect fix is not of an urgent nature and can be delayed until more important fixes are completed.
•Medium Priority: The development team should fix the bug in subsequent builds.
•High Priority: The impact of the bug on the software is substantial and should be addressed immediately.
•Urgent Priority: The product cannot be used until the defect is fixed so it should be resolved urgently.
Defect Reporting:
•-Defect or Bug Report is the medium of communication between the tester and the programmer
•-Provides clarity to the management, particularly at the summary level •-Defect Report should be accurate, concise, thoroughly-edited, well conceived, high-quality technical document.
•-The problem should be described in a way that maximizes the probability that it will be fixed
•-Defect Report should be non-judgemental and should not point finger at the programmer
•-Crisp Defect Reporting process improves the test team’s communications with the senior and peer management.
Defect Template:
-Defect ID:
-Description:
-Feature/Module:
-Test Case Name:
-Reproducible (Yes/No) (does the defect comes again and again in a consistent way)
-Status: New/ Reopen
-Severity: Seriousness of Defect
-Priority: Importance of defect
-Reported Bug:
-Assigned to:
-Build Version ID:
-Suggested Fix: -Fixed by:
-Resolved by: -Resolved on:
-Resolution Type: (Guidelines given to the developer to fix the problem)
-Approved by:
Defect Classification :
•This section defines a defect Severity Scale framework for determining defect criticality and the associated defect Severity Levels to be assigned to errors found in the software.
The defect can be classified as follows:
•Critical: There is a functionality block. The application is not able to proceed any further.(The application crashes)
•Major: The application is not working as desired. There are variations in the functionality. (The application is not doing what it is supposed to do) •Minor: There is no failure reported due to the defect, but certainly needs to be rectified. (Example: there is date format error)
Cosmetic: Defects in the User Interface or Navigation. (UI error) •Suggestion: Feature which can be added for betterment.
Defect Types:
•The Defect can be of several types
–Functional Defects (requirement defects): The defect is filed against the functional requirements when the system does not fulfil some functionality correctly.
–Data Defects: Incorrect data population / update in database –Configuration Defects: When the defect is due to some configuration of the environment.
–Database Defect: Defect in the database schema/ Design –Boundary Conditions Neglected: Boundary conditions not addressed/incorrect –Logic Defect: Missing or Inadequate or irrelevant or ambiguous functionality in source code.
–Message Defect: Inadequate/incorrect/misleading or missing error messages in source code.
–Navigation Defect: Navigation not coded correctly in source code –Performance Defect: A Defect related to performance/optimality of the code
–Missing Requirements: Implicit/Explicit requirements are missed/not documented during requirement phase
–Missing Design: Design features/approach missed/not documented in the design document and hence does not correspond to requirements –Inadequate or sub optimal Design: Design features/approach needs additional inputs for it to be complete Design features described does not provide the best approach (optimal approach) towards the solution required
–Incorrect Design: Wrong or inaccurate Design Ambiguous Design: Design feature / approach are not clear to the reviewer. Also includes ambiguous use of words or unclear design features