Defects:
Defects are the most visible part of the Software Test Process. Defects found in Production/Live environment and by customer are termed ‘Failures’.
Any testing team is evaluated by the number found during testing and the failures encountered by the customer. If the customer encounters a vast number of failures, the efficacy of the testing team is strongly questioned.
Defect reports help provide the following info:
- If the product is ready to be shipped
- Most defective modules and why
- Root cause of defects
- Issues caused by test environment, installation
- Defects found during testing and defects found after the product has gone live
Defects are logged when testing begins and the Actual results do not match with the Expected Result. Defects are the most visible part of testing. They also go by the names – Faults, Bugs. Typical defects include:
- Installation related
- Screens/UI related
- Functional – the product is not working as expected
- Performance – response time, memory, cpu usage high etc
- Unstable – unexpected crashes or failure
The Defects can be tracked using Excel spread-sheets or with tools like PVCS, Bugzilla, HP UFT (Quality Center) etc. The tools have the advantage of – streamlining the process (imposing Mandatory fields, using same values from drop-boxes), the ability to send emails when the defect status changes, reports, ability to view defects from a Browser from anywhere in the world and a log or History of changes to the defect. In addition, many tools provide interfaces to the Configuration Management tools. And hence tracking changes to code becomes easier.
Most organizations also track ‘Change Requests(CR)’ through the Defect Tracking tools. The CRs are essentially changes to the existing features requested by customers.
Defect Information:
A tester who can provide good defect reports is highly valued. A good defect report is one that provides sufficient information to the Developer to fix the defect. A good defect report has the following:
- Defect Title (summary of the defect)
- Defect Description ( Test Steps, Expected Result, Actual result)
- Screen-shots, test data, database dumps, log files etc that can serve as evidence
- Test Environment: Build number, OS, Browser, Module etc
- Defect Severity( business impact), Priority(time to fix)
- Date detected, Defect found by
- Reproducible defect or Randomly occurring
Before logging a defect it is wise to :
- Check the defect tracking report to see if this issue has been raised previously.
- Reproduce (replicate) the issue on different environment / test bed / OS / Browser / machines
- Reproduce the issue with different test data
- Consult a SME (Subject Matter Expert) viz peers / BA / lead / manager
In practice, developers may reject defects as Invalid because of insufficient information, misunderstandings with the way the defect has been written. Hence writing a good defect report is essential.
