Effective Defect Reporting – Dos And Donts

March 31, 2017

Defects are variations or deviations from the original business requirements and they need to be taken very seriously as small mistakes can be expensive and impact adversely on all aspects of a project including cost, schedule and quality.

When testers execute the test cases, they might come across test results that could be contradictory to the expected result. This variation in the test result is referred to as a Software Defect, often also called an issue, problem, bug or incident.

Write Clear, Reproducible Defects

When the information on the defect is either bad, incomplete or misleading, it results in development and QA teams wasting precious time in tracking down the defects based on bad information or constantly requesting clarification about poorly documented problems. Besides, an improperly classified defect might end up getting more attention than it deserves, thus causing loss of valuable time and effort, or even worse, an important defect might be overlooked because the severity is set too low.

What to do and what not to do

This list of do’s and dont’s can go on and on, but I am restricting myself to the top 3 worst habits of defect reporting and how we can break away from them.

Laziness – It is all about not taking the time to do the best that one can. Lack of passion leads to laziness. Go ahead spend that extra minute or two to document the defect more clearly. Have the right attitude, it matters!
Every Defect should have a Title, Summary, System configuration, Steps to reproduce, expected results and any other additional information that could help others understand the scenario better (you can also add screenshots of the defects). The ‘Steps to reproduce’ the error is the most critical step and this critical piece of information is often inadequately described, wasting time for developers and testers.

Do your due diligence and take ownership for the quality of your deliverable. Make sure the defects are valid and they don’t come back to you for want of information.

Rushing – Don’t be in a hurry to report a problem. Try to analyze it from different angles and perspectives.
Failure to allow enough time for testing the project can lead to missed requirements, inadequate analysis, poor design, rushed programming and incomplete documentation. The result can be a system that doesn’t meet expectations and fails in one or more key areas

Be 100% sure that you understand the impact of the problems from many angles

Creativity – Don’t just be reporting problems. Think out of the box. Provide suggestions.
Testers have a great opportunity to add value to the system by suggesting enhancements. If you think a certain feature is missing, you can try to put the idea forward.

You have to have curiosity to continue learning and need to reach out to other people in the community and stay up to date on current and emerging technologies because technology is constantly changing and change is the only constant.

With periodic self-assessments, bad habits can be identified and purged so an ineffective software engineer can become effective once more.

Leave a Reply

Your email address will not be published. Required fields are marked *