What is Defect in Testing and a format of defect IEEE 829 by testers or developers ?Definition , Life Cycle, Types, Management.

Defect in Testing:-

What is Defect ?

"Missing, Wrong, Not expected in the software which is difficult to understand, hard to use is called as Defect".

"A software error is present when the program does not do what product specification states it should do".

Who can report a Defect ?

• Anyone who has involved in software development life cycle and who is using the software can report a Defect.

• In most of the cases defects are reported by Testing Team.

Priority and Severity

Severity

• The degree of impact casted by the bug on an application.

• It is the seriousness of the problem.

Priority

• Relative degree of precedence given to a bug for its fixation.

• It is the urgency of fixing a problem.

Difference between Defect Priority and Defect Severity

Defect Priority

1. Priority defines the order in which the developer should resolve a defect.
2. Priority is categorized into three types : Low, Medium, High.
3. Priority indicates how soon the bug should be fixed.
4. Priority states is based on the customer requirements.
5. Priority is driven by business value.
6. Priority of defects is decided in consultation with the manager/client.
7. High priority and low severity status indicates, defect have to be fixed on immediate basis but does not affect the application.

Defect Severity

1. It is defined as the degree of impact that a defect has on the operation of the product.
2. Severity are categorized into five type : Critical, Major, Moderate, Minor, Cosmetic.
3. Severity indicates the seriousness of the defect on the product functionality.
4. Severity status is based on the technical aspect of the product.
5. Severity is driven by functionality.
6. QA engineer determines the severity level of the defect.
7. High severity and low priority status indicates defect have to be fixed but not on immediate basis. 

Example of Severity and Priority

• High severity and High priority, System crashed in Log-in Page.

• High severity and Low priority, System crashed on clicking a button. The page on which the button is located is a part of next release.

• Low severity and High priority, Spelling mistake in any company name web site.

• Low severity and Low priority, Location of button in any web based application.

IEEE 829 Defect Report Format 

(By Testers)

• Defect ID : Unique number or name.

• Description : The summary of the defect.

• Build version number : The version number of current build, in which test engineers detected this defect.

• Feature : The name of module or functionality.

• Test Case Name : The name of failed test case.

• Reproducible : Yes/No

(Yes - if the defect appears every time during test execution : attach test procedure or script)

(No - if the defect rarely appears during test execution : attach strong reasons and snap shot)

• Severity in terms of functionality.
• HIGH/SHOWTOPPER Important and Urgent. Mandatory to resolve and Unable to continue testing without resolving.
• MEDIUM/CRITICAL Important but not urgent. Mandatory to resolve but able to continue testing.
• LOW/NONCRITICAL Not Important and Not urgent. May or may not resolve but able to continue testing.

• Priority : The Importance of the defect to be resolved with respect to the customer(HIGH/MEDIUM/LOW)
• Status : New/Re-open.

New : Reporting first time

Re-Open : Reporting same defect

• Reported by : Name of the Tester
• Reported on : Data and time of defect reporting.  

• Assigned To : The responsible person at development side to receive this defect.

• Suggest Fix (Option) : Reasons to accept and restore these defect.  

(By Developers)

• Fixed by : Project Manager or Team Leader.

• Resolved by : Name of programmer.

• Resolution Type : Accepted, rejected, or postponed.

• Resolved on : Date of resolving.

• Approved by : Signature of project Manager.

  Defect Management

• Primary goal is to prevent defects.
• Should be integral part of development process.
• As much as possible should be automated.
• Defect information should be used for process improvements.

Types of Defect Management : -

• Defect Prevention :- Implementation of techniques, methodology and standard processes to reduce the risk of defects.

• Deliverable Baseline :- Establishment of milestones where deliverables will be considered complete and ready for further development work. When a deliverable is baseline, any further changes are controlled.

• Defect Discovery :- Identification and reporting of defects for development team and acknowledgment. A defect is only termed discovered when it has been documented and acknowledged as a valid defect by the development team member's responsible for the component's in error.

• Defect Resolution :- Work by the development team to prioritize, schedule and fix a defect, and document the resolution. This also includes notification back to the tester to ensure that the resolution is verified.  

• Process Improvement :- Identification and analysis of the process in which a defect originated to identify ways to improve the process to prevent future occurrences of similar defects. Also the validation process that should have identified the defect earlier is analyzed to determine ways to strengthen that process.

•  Defect Submission :- In the above defect submission process, testing team uses defect tracking software.

E.g.  : Test Director, Bugzilla, ALM(application lifecycle management )....etc. 

 Defect Life Cycle

• New : Tester found new bug and reports it to test lead.

• Open : Team lead open this bug and assign it to the developer.

• Assign : Developer has three choices after assigning the bug.

1. Reject : He can say that this is not a bug because of some hardware or other problems you might getting defect in application.
2. Differed : He can postpone bug fixing according to priority of bug.
3. Duplicate : If the bug is repeated twice or the two bugs mention the same concept of the bug, then one bug status is changed to "Duplicate".

• Fixed : If there are no such conditions like reject, duplicate the developer has to fix the bug.

• Re-Testing : Re-test the whole application to find the defects if the defect is still there.
• In case there is a bug present, they will re-open the bug and if bug is not there it will move to verify.

• Re-open : If defect raised during re-testing we re-open bug.

• Verify : Test whole application(Regression).

• Close : Close the defect.

What is defect Age ?

Time gap between defect reporting and defect closing or deferring.

Defect Density

The average no. of defects found in a module or function is called defect density.  

Types of Defects

User interface defects

• Spelling mistakes.
• Invalid label of object w.r.t functionality.
• Improper  right alignment. 

Error handling defects

• Error message not coming for wrong operation.
• Wrong error message is coming for wrong operation.
• Correct error message but incomplete.

Input domain defects

• Does not take valid input.
• Taking valid and invalid also.
• Taking valid type but the range is exceeded.

 Manipulations defects

• Wrong output.
• Valid output without having decimal points.
• Valid output with rounded decimal points.
• EX : Actual answer is 10.96, High (13), medium (10) and low (10.9)

Race conditions defects

• Hang or dead lock.
• Invalid order of functionalities.
• Application build is running on some of platforms only.

H/W related defects

• Device is not connecting.
• Device is connecting but returning wrong output.
• Device is connecting and returning correct output but incomplete.

Load condition defects

• Does not allow customer expected load.
• Allow customer expected load on some of the functionalities.
• Allowing customer expected load on all functionalities w.r.t benchmarks.

Source defects

• Wrong help document.
• Incomplete help document.
• Correct and complete help but complex to understand.

ID control defects

• Logo missing, wrong logo, version number missing, copy right window missing, team members name missing.