The most important part of entire STLC (Software Testing Life Cycle) is to find and report bugs/defects. Although we may be proficient in finding defects, the real test is how we report them. I have seen many times that due to incomplete information, the defects are reassigned to the Testers asking for more information, resulting into time wastage and rework. So following are the things one should keep in mind while logging defects.
Defect Title: It is the most important part of a defect, as many times, developers apply the fix based only on the basis of Defect Title. So try to provide as much information as possible. Having said that, don’t write an entire essay in the title itself. Try limiting it to 10-15 words max. The information should be concise and to the point. Secondly, try to mention in the defect title itself whether it’s a Functional Bug or a UI bug. For me, I always write [Func] for functional and [UI] for UI defects. Thirdly, Mention the Module Name and if you’re working on multiple application write the App name as well.
Eg. [Func] DemoApp_DemoModule: Email Field is accepting invalid inputs.
Severity v/s Priority: Severity mostly concerns with how severe the impact of the bug is in terms of Business reputation, Financial loss etc. whereas Priority concerns with how quickly a bug must be resolved. It is very important to understand these two aspects and accordingly use them. Because these two parameters ultimately decide which bugs are going to be resolved, which are to be moved to next cycle/sprint, which are to be not fixed etc. In short, a lot of emphasis should be given before giving the priority and severity of a bug.
Steps to Reproduce:?The steps to reproduce is again an important part of Defect description. The steps should?always be written in points. Secondly, it should be informative. The steps should be such that a person who was no information of the application should be able to reproduce the defect by following the steps.
Eg.
- Open the website in any Browser.
- In the Website Header, click on the ‘Contact Us’ label.
- In the contact form, input valid Name and Message.
- In the email write @@invalidData@@
- Click on the Submit button and Observe.
Actual and Expected Results:?Be very careful while writing this as many a time we swap the contents for Expected and Actual results. Secondly, always write ‘should’ in the Expected results.
Eg.
Actual Result: A message is displayed stating ‘You have successfully submitted the form’.
Expected Result: A message should be displayed stating ‘The Email you have entered is invalid’.
Test Data:?Provide test data, as it helps the developer to reproduce the bug.
Eg.
Test Data 1: abcd.com@
Test Data 2: in.com@hello
Logs & Screenshots:? Last but not the least, always provide evidence of your defect. If it’s a UI defect provide screenshots and if it’s a functional defect, provide logs.
