Difference between revisions of "READABLE REPORTS"

From Test Automation Patterns
Jump to navigation Jump to search
m (Topic titles in capital letters)
 
(3 intermediate revisions by 2 users not shown)
Line 9: Line 9:
 
<span style="font-size: 16px">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.</span><br /> <span style="font-size: 16px">What gets reported should be related to the goals and objectives of the automation; hopefully you have already [[SET CLEAR GOALS]].</span>
 
<span style="font-size: 16px">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.</span><br /> <span style="font-size: 16px">What gets reported should be related to the goals and objectives of the automation; hopefully you have already [[SET CLEAR GOALS]].</span>
 
=<span style="font-size: 16px">'''Implementation'''</span>=
 
=<span style="font-size: 16px">'''Implementation'''</span>=
<span style="font-size: 16px">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.</span><br /> <span style="font-size: 16px">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).</span>
+
<span style="font-size: 16px">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.</span><br /> <span style="font-size: 16px">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).</span><br /><br />
=<span style="font-size: 16px">'''Recommendations'''</span>=
+
<span style="font-size: 16px">Recommendations</span><br />
 
<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">[[​​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 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 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

.................................................................................................................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 and would like to contribute your experience to the wiki, please go to Feedback to submit your experience or comment.


.................................................................................................................Main Page / Back to Design Patterns / Back to Test Automation Patterns