Monday 3 November 2014

Tips for registering defects

We have just been through a couple rounds of testing, and gathered a lot of observations. Some of these are not defects, they are the result of tester wish-listing, misunderstandings, wrong test cases etc. This is however as expected, and as always calls for a bug triage and refinement BEFORE any fixing and distribution of the defects happen – In other words, no defect management before you are actual sure that it is a defect.
Luckily for us, the testers have been very careful when raising an issue – Something that we benefit from now, saving vast amounts of time in the analysis. Despite the testers being new to testing, they have reported the observations in a way that facilitates future analysis. Simply by following our tips for issue reporting!
There  is little new in the tips for issue reporting below for all you professional testers, but for business reps who are invited to join a project as testers, everything is new, and that is when you will benefit from guides that explains key areas of your test process. We made such a guideline, consisting of a manual for using the test tool – Stripped for anything but what the testers needed. And a list of advice to help filing the issues while testing.
Make sure that you nurse your testers, so they understand their role and the expectations towards their deliveries – They become a powerful asset if you do.
 Happy testing!
/Nicolai
Tips for registering issues:
Reproduce the issue before filing an issue report: Your issue should be reproducible. Make sure your steps are robust enough to reproduce the issue without any ambiguity by someone who is not you. If the issue is not reproducible every time you can still file an issue mentioning the periodic nature of the bug.
Report the problem immediately: If you found any issue while testing, do not postpone the detailed report to later, instead write the issue report immediately. This will ensure a good and detailed bug report. If you decide to write the bug report later on, then chances are that you miss the important steps in your report.
Spend 2 extra minutes on the description: When writing a description please adhere to the following structure, to ensure that sufficient information is captured:
·         Reproduce steps: Clearly mention the steps to reproduce the issue, to facilitate reproduction of the issue by developers and others who will work on fixing the problem.
·         Expected result: How application is expected behave on above mentioned steps. Add a reference (if known) to the requirement that appears to be violated.
·         Actual result: What is the actual result on running above steps. Include a screenshot of the scenario, or clear detailing on test scenario, including test data used.
Read issue report before hitting SAVE button
Read all sentences, wording, steps used in bug report. See if any sentence is creating ambiguity that can lead to misinterpretation. Misleading words or sentences should be avoided in order to have a clear bug report, and ease communication with the receiver.

No comments:

Post a Comment