Difference between revisions of "READABLE REPORTS"
m (Topic titles in capital letters) |
m (Corrected link to INEFFICIENT FAILURE ANALYSIS) |
||
Line 13: | Line 13: | ||
<span style="font-size: 16px">[[SHARE INFORMATION]] to find out what each recipient needs and wants</span> | <span style="font-size: 16px">[[SHARE INFORMATION]] to find out what each recipient needs and wants</span> | ||
=<span style="font-size: 16px">'''Issues addressed by this pattern'''</span>= | =<span style="font-size: 16px">'''Issues addressed by this pattern'''</span>= | ||
− | ''<span style="font-size: 16px">[[ | + | ''<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 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!</span><br /> <span style="font-size: 14px">.................................................................................................................[[Main Page]] / Back to [[Design Patterns]] / Back to [[Test Automation Patterns]]</span></div> | <span style="font-size: 16px">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!</span><br /> <span style="font-size: 14px">.................................................................................................................[[Main Page]] / Back to [[Design Patterns]] / Back to [[Test Automation Patterns]]</span></div> |
Revision as of 13:26, 4 May 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, 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