In this article, we present 6 of the most important steps to write an effective test report and make your test reports better:
Before we go ahead with suggestions on how to create an effective test report, look into the reports below and ask yourself, which one would you prefer if you are a decision maker or even a team member (any recipient of the report).
Report #1:
Tested the following modules:
- Module X: Login page.
- Module Y: Home page and relevant tabs.
- Bugs observed:
- Login page: Users can enter invalid characters for the Username field.
- Login page: Application crashes if the Cancel button is clicked after providing valid information for the username and password fields.
- Login page: Spelling for Password label is wrong.
- Homepage: Does not load for IE.
- Home page: If the user tries to reload the page by pressing CTRL+F5, only half of the page gets loaded.
- Home page: Clicking on the back arrow reloads the home page.
- Home page: Spelling mistakes for a word in the Company Profile paragraph.
Table of Contents:
How to write an effective test report
Report #2:
Test Report – 12th September 2016
Application: XYZ
Modules tested:
- X: Login page
- Y: Home page
Test Cases:
- PFA the detailed test cases used during testing.
- In addition to that, performed exploratory testing.
Details of the Bugs Reported:
Total bugs observed: 7
Critical bugs: 2
- Login page: Application crashes if Cancel button is clicked after providing valid information for the username and password fields.
- Home page: Does not load for IE.
Major bugs: 2
- Home page: If a user tries to reload the page by pressing CTRL+F5, only half of the page gets loaded.
- Home page: Clicking on the back arrow reloads the home page.
Minor: 3
- Login page: User can enter invalid characters for Username field
- Login page: Spelling for Password label is wrong.
- Home page: Spelling mistake for a word in the Company Profile paragraph
Road Blocks:
Cannot test the application for Opera browser as the application crashes in Opera browser.
Plan for tomorrow:
- Verification for bug fixes
- Testing for Module Z
I think those examples simplify and present pretty much everything I wanted to share via this post.
Recommended read => A Simple 12 Steps Guide to Write an Effective Test Summary Report
Being a tester doesn’t mean you need to always create and send a testing report. But, to be a good tester and after couple of years of experience, you are expected to write an effective test report; a report that can make or break your day and/or your development team’s.
How do I create an effective test report
What should the test report be? Which factors should be considered while writing the test report? What tricks can make a test report more effective?
This article answers those questions…..Read on.
#1) Know the audience:
Knowing who is going to receive and rely on the testing report and what kind of decisions are going to be made based on it, is very important.
The QA lead needs detailed information about what was tested and what was found because management would like to see the overall testing progress and coverage. Some information remains common for all types of test reports, but again, different templates are used for different audiences.
#2) Provide details but not too much:
A number of factors play an influence in the writing of a test report. As I said, the details to be provided in the testing report depend upon the audience and their relevant interest.
When providing details, make sure you do not provide too many details and the ones you choose to include should be on-point and easily understandable.
#3) Always provide reference to tasks done today and what is planned for tomorrow:
A test report should always consist of two main things: Tasks done and tasks to be done.
At the beginning of a test report, when you provide tasks done, the reader of the test report will have a clear idea about what the report is going to be about.
Also, the future tasks mentioned will help the upper-level management to understand the task pipeline and will give them a chance to change task prioritization, if need be.
#4) Always share road blocks:
The testing report should always mention road blocks, if any.
It is a good way for the reader (at any level) to get clarity about why the task was not completed and what kind of issues were faced.
The road blocks allow other team members to chime in and help you. Road blocks allow you to go back and provide references as to why you were not able to complete the task.
#5) Proofread it:
Don’t be in a hurry to send the report. Anything written should always be proofread at least once.
While proofreading you might realize:
- You wanted to convey something else or in a different manner.
- You wanted to add some more points too.
- You could have written that paragraph as bullet points to make it easier to read and understand.
- You forgot to check for spellings.
- You have not included all the required people in the email list.
- You were supposed to work on some other tasks too.
- You were supposed to provide an update for some older tasks.
Thus, proofreading is helpful in resolving many problems in one go. So don’t miss it.
#6) Practice to make it better:
Always try to make the test report better for your audience. Search online for better templates, ask for views from the audience, read others’ reports and make sure to look for good points that you can include in your testing report.
A concise and to the point test report will be helpful to your audience.
Sample test report template
=> Download Sample Test Summary Report:
Click here to download a sample test report template with an example.
Further reading => How to Report Test Execution Smartly [Download Status Report Template]
Conclusion
Finally, a test report should not be a document that is too lengthy, includes every piece of info and whose format is set in stone. The testing report will always change as per the latest implementations, modifications and requirements.
While writing a testing report, make sure to identify the readers’ needs and keep them updated until you reach a workable solution.
Also, maintain a reasonable report size by providing reference documents as test plans and use an addendum for lengthy information such as bugs.
A precise, easy to read, short, flexible and actionable test report is the way to go!
About the author: This helpful post was written by STH team member Bhumika M. She is a project lead, carrying 10+ years of software testing experience.
Please let us know your thoughts/feedback in the comments section below. We would love to hear from you.
I accept all the points above(except few points),
@Bhumika,
Question 1, Ideally Test Report/TSR will be published at the end of testing only in any project, then how it can be keep on changing in one shot delivery of the project(if it reaches to mentioned scope in Test Plan)?
2. Tasks which are done/not done and what tasks planned for tomorrow, those details really required in TSR?
3. Best practices/Lesson Learnt also very options to add in the TSR?
Overall I like this article , It would be great if can answer my queries/questions!!!
As Bhumica said..all the points what she covered is mandatory..
@Naga:Ans1&2. It depends on your work environment. If the QA cycle let’s say 1 week, then team should know how many tasks done and how many remains..
i am looking for some kind of extension to record the web activities during manual test and generate automatic file with the steps capture automatically during the flow and SS with ability to edit insert note even during the flow
i found Qmetry but its related to JIRA and i am looking for stand alone tool
Thank you readers,
@Sekhar, I will get back to you with answers in a while.
Very good document
The article is educational especially on how to create test report
I think its time to end the reporting era, i still dont see how many ppl are looking at Bug report (critical, minor, major) its really not useful is what i mean. Management are more concerned with the quality of software delivered than these kinds of reports
thanks for the article.
Could you cover the “#2) Provide details but not too much:” little better?
Test Reports travel to different stakeholders who might be interested in various aspects of the test report.
Also, is there any standard nomenclature for naming Test Reports?
Good article, specially point #5 As a tester/QA nobody expects spelling mistakes or silly mistakes by tester.
Also this kind of reports can be sent on daily basis. Management might not be interested to see or read everything but client will surely interested to know that we are working on daily basis to improve the quality of the system under test/development.