READABLE REPORTS

From Test Automation Patterns
Revision as of 11:34, 28 June 2018 by Seretta (talk | contribs)
Jump to navigation Jump to search
.................................................................................................................Main Page / Back to Design Patterns / Back to Test Automation Patterns

Pattern summary

Design the reports to be easy for the recipient to read and understand.

Category

Design

Context

Use this pattern for efficient and long lasting automation.
You will not need it for a one-time solution.

Description

Reports should at a glance show if a test passed, but they must also be helpful in finding why a test failed. Reports must also deliver metrics for management, for instance trends.
What gets reported should be related to the goals and objectives of the automation; hopefully you have already SET CLEAR GOALS.

Implementation

Design the reports in different levels depending on who will read them. Testers or developers will need detailed information to be able to resolve failures, but will not want to waste time with passed tests. Managers will need more statistical kinds of data, depending on their goals and what they want to monitor.
At first, you may be reporting mainly on the progress of starting automation; later on, when the automation is more established, you should report on the health of the automation (such as reducing costs and increasing benefits).

Recommendations
SHARE INFORMATION to find out what each recipient needs and wants

Issues addressed by this pattern

INEFFICIENT FAILURE ANALYSIS
OBSCURE MANAGEMENT REPORTS

Experiences

If you have used this pattern, please add your name and a brief story of how you used this pattern: your context, what you did, and how well it worked - or how it didn't work!
.................................................................................................................Main Page / Back to Design Patterns / Back to Test Automation Patterns