Providing the correct information to the development team on a problem discovered during testing is an important role of the tester. Terminology and process may be different among companies as it may be called a bug, an issue, or a problem report and the format you submit the problem can vary. To gain an understanding of the functionality’s expected behavior the tester may talk to a business user or a business analyst. Regardless of the differences among companies, this article will provide guidelines that a tester can follow when researching and developing a problem report.

Reproduce the Problem

It is important to reproduce the problem to determine if:
· you can reproduce it upon demand;
· the failure is related to specific test paths;
· the failure is associated with specific data;
· certain environments cause the problem (ie., client, browsers).

When encountering a problem that is sporadic, it is important to note that in your report and to provide as much information on the steps to make it fail. Providing a percentage of the failure can be helpful, such as: I ran test “x” 10 times and it failed 50% of the time. Sporadic problems can be difficult to fix; therefore, it is important to provide as much information that you can gather.

When appropriate, have another tester reproduce the problem to help identify additional details. If the problem cannot be reproduced on a different machine, note any differences such as version number of loaded software / add on tools.

Reproducing a problem can also identify tester error and it is best to catch those prior to submitting a problem that does not exist.

Error Logs

Some problems will produce an error log with additional information that is valuable to the developer. Understand what additional technical information is valuable and be sure to capture that information.

Screen Shots

Provide any appropriate screen shots that may be beneficial to the developer and when retesting the issue. If possible, crop the screen shots to show only the important details as to reduce the noise in the report. Too many large screen shots can be difficult and confusing to review which might cause the developer or anyone else who reviews the document to skip the pictures or worst yet, stop reading the report.

Document the Steps

Remember that someone else needs to reproduce this problem on his machine and sometimes problems are fixed months after they are submitted. When testing the solution, the original submitter may not test it depending upon the project workload. Therefore, take time in documenting the steps and review them by re-testing to ensure all critical steps are captured. Identifying at what point the problem occurs is important. For example, if the problem occurs when clicking on a create button or when clicking on the save button is valuable information to the developer.

Is it a Known Problem?

Before submitting a new problem, review the tracking system to ensure it has not been logged. If a problem has been logged, add any additional details if the information provide new insight. If a similar problem has been entered, work with the employee who can make the decision to determine if a new problem should be submitted.

Discussions with the Developer

If there is an opportunity, review the problem with the developer to gather more information to add to the report. For example, a developer may ask for additional tests to be performed and those results can be part of the report. This conversation may help the tester understand if the problem has been logged or if there is a difference in opinion on how the functionality should perform. Any differences should be resolved with the business user before submitting the problem.

Discussions with Business User

If the tester is unsure if the problem is legitimate or does not understand the intended behavior, review these questions with the business user who is in charge of the functionality. Be sure to follow any company policies such as reviewing with the Testing Lead or Testing Manager before escalating to the business community. Before submitting the report, make sure it is a problem and that the correct expected behavior is defined.

How Much Information to Document

How much information should you document in the test report? It can depend upon:
· the company’s standards;
· how difficult it is to reproduce;
· the complexity of the problem;
· how much information the development and testing team requires.

Writing the Report

Once you gathered the information and had appropriate conversations, it is then time to write the formal report. When writing the report, keep the sentences concise providing critical information at the beginning of the report. Additional information that may or may not be helpful to the developer should be placed at the end of the document with a descriptive heading. This ensures the developer does not have to read through the document to find the important details.

Re-read your report to ensure steps are not missing, sentences are clear, unnecessary information and words are not included, and the correct format based upon the company’s standards is followed.

Submitting the Report

The tester will submit his report based upon the tracking system adopted by the company. Sometimes a developer may challenge a tester’s report especially when a developer is closely attached to the feature. It is best to handle these conversations with the facts, reproduce the problem with the developer if that is helpful, and do not get into an emotional discussion. If an agreement is not reached, then be sure to involve the business user who is responsible for the functionality for the final decision. It is best to minimize these situations by gathering sufficient upfront information and having conversations with the developer and business user (or Test Lead, Test Manager) prior to submitting the problem.

Submitting a false or incorrect problem report can hurt the tester’s reputation and relationship between developers and testers.

Conclusion

A problem report is an important communication tool between the tester and developer. A properly written report detailing the correct information including steps to reproduce the problem is critical to ensure the problem gets fixed and the tester can properly test the solution. The report should go beyond the written aspect to include conversations with the developer and when appropriate the business user in charge of the functionality (or Test Lead, Test Manager) before submitting the report. It is important to ensure a report is submitted once the problem is verified with the correct expected behavior documented. False or incorrect problem reports can harm a tester’s reputation and relationship with developers.

 

https://i0.wp.com/www.testingcircus.com/wp-content/uploads/Problem-Report.jpg?fit=500%2C274&ssl=1https://i0.wp.com/www.testingcircus.com/wp-content/uploads/Problem-Report.jpg?resize=150%2C137&ssl=1Bernice Niel RuhlandArticlesBug ReportProviding the correct information to the development team on a problem discovered during testing is an important role of the tester. Terminology and process may be different among companies as it may be called a bug, an issue, or a problem report and the format you submit the problem can vary. To gain an...