Difference between revisions of "READABLE REPORTS"
| (One intermediate revision by the same user not shown) | |||
| Line 15: | Line 15: | ||
''<span style="font-size: 16px">[[INEFFICIENT FAILURE ANALYSIS]]</span>''<br /> ''<span style="font-size: 16px">[[OBSCURE MANAGEMENT REPORTS]]</span>'' | ''<span style="font-size: 16px">[[INEFFICIENT FAILURE ANALYSIS]]</span>''<br /> ''<span style="font-size: 16px">[[OBSCURE MANAGEMENT REPORTS]]</span>'' | ||
=<span style="font-size: 16px">'''Experiences'''</span>= | =<span style="font-size: 16px">'''Experiences'''</span>= | ||
| − | <span style="font-size: 16px">If you have used this pattern, please | + | |
| + | <span style="font-size: 16px">If you have used this pattern and would like to contribute your experience to the wiki, please go to [[Feedback]] to submit your experience or comment.</span><br /> <br /> | ||
| + | |||
| + | |||
| + | <span style="font-size: 14px">.................................................................................................................[[Main Page]] / Back to [[Design Patterns]] / Back to [[Test Automation Patterns]]</span></div> | ||
Latest revision as of 15:56, 21 August 2018
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 and would like to contribute your experience to the wiki, please go to Feedback to submit your experience or comment.