Remove defects from the defect

Remove defects from the defect

For a tester, finding a defect in application is very crucial task. Because it’s not only one of the most important deliverables in testing life cycle but it also reflects tester’s performance and expertise to a large extent.  Making this defect acceptable to developers is the further step which confirms tester’s ability to understand functionality and user expectation. Nil or minimal defect leakage at end user’s end builds confidence of customer in the testing process effectiveness.
However, there are many factors that impact this entire process adversely and it leads to

• Endless communication between developer and tester to confirm defect occurrence
• Defect rejection from developer
• Cancellation of defect due to non-reproducible behavior
• Duplication of defects
• No detection of other defects introduced during earlier defect fixing
• Repetition of the similar types of defects detected at customer end

How to avoid all these situations is the crucial challenge for every tester. Let us look at some important aspects of the defect management process to take care of these issues.
The idea is to remove defects from the defect and the defect management process.
What causes defects in defect management process?
 Typically, the defect management process would involve following activities. Test case failure analysis

• Defect logging
• Defect verification
• Regression testing

There is a possibility of a “Defect” in any of these activities.
Let’s take an example.

• You are testing a school management system and one of the modules is related to displaying student’s marks.  Along with subject wise mark list, the screen also displays the minimum and maximum marks obtained by the student in that particular exam.
• During testing for one of the test cases, you find that the application is not showing minimum marks fields correctly. You log a defect “Application not showing correct value for minimum marks”.
• Developer makes it “not a defect” showing that at his end he could see that data is displayed correctly. You again check at your end and tell developer that for student XYZ, you got this error.
• Developer rechecks the issue and fixes the defect.
• You validate closure of this defect in next cycle checking with data corresponding to other student which you created in cycle 2 and close the defect.
• After application goes live, customer finds a defect that application is not showing minimum and maximum values correctly.

So what went wrong here? You tested, logged a defect, got is corrected and still customer finds the issues in the application.
Here are different reasons what could have gone wrong.

• You logged a defect with only one instance of testing and with one set of test data.
• You did not analyze what was the difference between the student record that developer used for the first time (claiming “Not a defect”) and student XYZ
• You validated defect with different set of test data
• You missed checking “Maximum marks” field during regression testing

Here are some ways how we can avoid such errors
Follow structured test case failure analysis

• Explicitly understand what is working and what exactly is failing
• Recheck failure in multiple other possible ways like
  • Alternate path for functionality flow
  • More test data with different combinations
  • Other set up or configuration
  • Pin point the exact failure and then convert it into the defect
  • Recheck the dependent functionality to assess impact of failure

Eliminate issues in defect logging

• Enter precise and concise defect description
• Include steps to reproduce defects
• Add test case number for reference
• Add snapshots wherever useful
• Mention requirement which you are testing
• Mention test data used to test
• Mention if any specific setting is done for application or test environment when defect occurred
• See if the defect is duplication of earlier defect detected in the same cycle before adding new
• Mention severity based on its impact on application functionality and testing schedule

Ensure complete defect verification

• Check for the defect closure by repeating the same steps you mentioned in defect description
• Use same set up and same test data used in defect situation for verification as well
• Check if the same defect is not occurring  by varying other parameters, test data or set up

Conduct sufficient regression testing

• Using requirement traceability matrix or from developer inputs, identify the areas that could have been impacted by code changes during defect fixing
• Check for the functionality that is dependent or linked to the defect

Summary
A little care in avoiding defects in defect management process adds benefits to the testing in terms of

• Increased defect acceptance rate
• Reduction in turn around time for defects
• Smooth communication with developer community
• Increased productivity of testing
• Less leakage of defects to customer
• Improved confidence of an organization with testing teams

For more details visit SEED Infotech Wagholi Pune Blog at : http://seedinfotechpune.blogspot.in/

Locate us on Google Map : https://www.google.co.in/maps/place/SEED+Infotech+Pune/@18.580642,73.976231,15z/data=!4m2!3m1!1s0x0:0xc4d19be6006792c9?sa=X&ei=-dFUVMiFFcGLuwT6qIL4BA&ved=0CHwQ_BIwCg

For any enquiry leave your details here for call back : http://seedinfotechwagholi-pune.co.in/enquiry.php

Google+ : https://plus.google.com/+SeedinfotechwagholipuneCoIn412207/posts