Bug Report that will help developers and testers alike.

I joined Xebia India as a tester for one of the project. While validating the defects the biggest problem that I faced was regarding the understanding of defect report and trying to reproduce the said problem when there were no steps. Being a new member to the team and joining the application in between the sprints added to it. Every time when I had to validate the defect and steps to reproduce were not there I had to run to the developer for their help. Developers too were tied up with their own tight schedules and sometimes the validation for the defect had to wait for sometime which created a backlog for me and then I thought to come up with the solution to it which I am discussing below. Using the following approach helped us and can help all. When a defect is entered in any bug reporting tool like Jira, we generally miss some of the very important and critical information. Due to this missing information either the developer who is trying to replicate the defect faces a lot of problems or it may also happen that a high priority defect rests in the low priority pool since the person who has logged the defect has forgotten to prioritize it. The results of this can be disastrous. To avoid all this we can move towards a more streamlined way of writing the bug reports i.e having the entire information that can be provided to replicate the issue, the priority and the severity too. Based on my experience, I started implementing developer's and tester's most desirable bug report which should have all the important ingredients required to reproduce and fix them. This bug report format was appreciated by the developer's and client team. Following are the most crucial ingredients that should be a part of any bug report:

• Description
• Steps to Reproduce
• Actual Result
• Expected Result
• More Information

Every bug report should start with a description, which should have a basic overview of the problem occurred, following the description one should add the steps to reproduce. The entire steps through which a reviewer/ developer can replicate the said issue should be provided so as to save time in trying to replicate the problem without the right steps and sequence. Sequence of the steps also plays a major role while you are trying to figure out the said problem, so as even a single missed step or wrongly sequenced step can lead to utter wastage of time for the developer and can hamper the tester-developer relationship. By providing the actual result, one can easily validate that whether the said defect is actually a defect or is just a functionality which is working fine. By the actual result the developer can easily be made aware that after following the steps provided what went wrong so that he/she can easily fix the problem and the tester can validate the fix. Whenever functionality is not working according to our expectations - a defect is logged. The person who is logging a defect should always mention the expected result as this will lead the developer to the fix. Developer should be made aware what is expected out of the functionality in which a defect is logged. Not providing this information can again lead to unnecessary time wastage as then developer will go back and read the entire functionality document. In the “more information” section you can provide with the other information that you feel can be useful in replicating the problem or may help in replicating the same problem with some other scenario. Prioritizing the defects in the bug report is always a good practice as a team of the developer can look and start working on the high priority defect and can leave some low priority things. If the defect is the showstopper and is not prioritized it may happen that a developer can over look it and miss it which can result into blunders.  Tester should have a good knowledge of the functionality and should have a good understanding of the concept of deciding the priority for a defect, as it can cost a lot too much. Below is an example from one of the logged bugs which follows the above mentioned approach. This example is specific to the project on which I am working: ------------------------------------------------------------------- Description: Some images are not being retrieved when undo button is clicked though the images are saved through Bestellen button. Steps to reproduce:

1. Open the application. 2. Click on the photo cover and select any definition for it. 3. Load some images. 4. Go to MBV, save the images. 5. Let the Progress bar reach 100% and then add some more images. 6. Click on Bestellen button. 7. On 'Opslaan' popup click sluiten, 8. On Waarschuwing popup click ok. 9. From Choose CoverView, go back to MBV and click on Undo button.

Actual Result: Files added in the step 5 are not being retrieved BUT the files added in step 3 are retrieved and displayed in the photo selection panel. Expected Result: Either we should display all the images when undo is clicked since the images added in step 5 were also saved and uploaded Or we should disable the Undo entirely for this scenario. More Info: I tried a similar scenario which is mentioned below: 1. Open the application. 2. Click on the photo cover and select any definition for it. 3. Load some images. 4. Go to MBV. 5. Click on Bestellen button. 6. On 'Opslaan' popup click sluiten, wait till all the files are uploaded 8. On Waarschuwing popup click ok. 9. From Choose CoverView, go back to MBV. Actual Result: Undo button is disabled. ------------------------------------------------------------------- Practicing the above method of writing a bug report can be really helpful for all, can save time and can create a healthy relationship between tester and developer.