Defect Reporting

Day-13

Defect Reporting

• Any mismatched functionality found in a application is called as Defect/Bug/Issue.

• Test engineer follows the process to tracking defects w.r.t test execution.

• During comprehensive testing, test engineers are reporting mismatches as defects to developers through templates or using tools like Quality Center, BugJilla etc..

Defect Report Contents• By Testers:-

– Defect ID– Description– Build Version– Test Case Title– Reproducible(Y/N)– Severity– Priority– Status– Reported By– Reported On– Assigned To

• By Developers:-– Fixed By– Resolved By– Resolution Type– Resolved On– Approved By

Defect Report Contents (Cont..)

Defect Severity

• Severity describes seriousness of defect.• Severity Types:-

– FATAL (Critical) - The bug causes a failure of the complete software system, subsystem or a program within the system.

– MAJOR - The bug does not cause a failure, but causes the system to produce incorrect, incomplete, inconsistent results or impairs the system usability.

– MINOR - The bug does not cause a failure, does not impair usability, and does not interfere in the fluent work of the system and programs.

– LOW(COSMETIC) - The bug is an aesthetic, is an enhancement or is a result of non-conformance to a standard.

Defect Priority

• Priority describes the importance of defect.• Priority is initially set by the Software Tester, it is

usually finalized by the Project/Product Manager. • Priority Types:-– High - This bug should be resolved as soon as

possible– Medium – This bug should be repaired after serious

bugs have been fixed– Low – It can be resolved in a future major system

revision or not be resolved at all

Defect Resolution Types

• After receiving the defect report from the testing team, development team conduct a review meeting to fix defects. Then they send a Resolution Type to the testing team for further communication.

• Resolution Types:-– Accept– Reject– Duplicate– Enhancement– Need more information– Not Reproducible– Fixed– As Designed

Defect Classification

Defect Severity

Critical

Major

Minor

Cosmetic

Defect Priority

High (P1)

Medium(P2)

Low(P3)

Defect Classification

Critical(Fatal) Defects

Major Defects

Minor Defects

Cosmetic Defects (UI)

Examples of Severity and Priority• Example for High Priority & Major (High) Severity defect:

– If 'Login' is required for an Application and the users are unable to login to the application with valid user credentials. Such defects need to be fixed with high importance. Since it is stopping the customer to progress further.

• Example for Low Priority and Major (High) Severity defect:– If an application crashes after multiple use of any functionality

i.e. if ‘Save’ Button (functionality) is used for 200 times and then the application crashes, such defects have High Severity because application gets crashed, but Low Priority because no need to debug right now you can debug it after some days.

• Example for High Priority & Minor (Low) Severity defect: – If in a web application, company name is miss

spelled or Text “User Nam:” is displayed instead of “User Name:” on the application login page. In this case, Defect Severity is low as it is a spell mistake but Priority is high because of its high visibility.

Defect Report Template

Defect Life Cycle

Defect Reporting

Test Closure

Test Closure

• After executing all the test cases and resolving corresponding defects, Test lead conducts a review meet along with the test engineers.

• Testing will be stopped once the following criteria have been met.

• All test cases executed and Passed.• Zero P1 & P2 defects.• Bug density should be below the level.