Difference between revisions of "DOCUMENT THE TESTWARE"

From Test Automation Patterns
Jump to navigation Jump to search
 
(5 intermediate revisions by 3 users not shown)
Line 1: Line 1:
<div id="content_view" class="wiki" style="display: block"><span style="font-size: 14px">.................................................................................................................[[Main Page]] / Back to [[Process Patterns]] / Back to [[ Test Automation Patterns]]</span><br />  
+
<div id="content_view" class="wiki" style="display: block"><span style="font-size: 14px">.................................................................................................................[[Main Page]] / Back to [[Process Patterns]] / Back to [[ Test Automation Patterns]]</span>  
=<span style="font-size: 16px">Pattern summary</span>=
+
=<span style="font-size: 16px">'''Pattern summary'''</span>=
<span style="font-size: 16px">Document the automation scripts and the test data.</span><br /> <br />  
+
<span style="font-size: 16px">Document the automation scripts and the test data.</span>  
=<span style="font-size: 16px">Category</span>=
+
=<span style="font-size: 16px">'''Category'''</span>=
<span style="font-size: 16px">Process</span><br />  
+
<span style="font-size: 16px">Process</span>  
=<span style="font-size: 16px">Context</span>=
+
=<span style="font-size: 16px">'''Context'''</span>=
<span style="font-size: 16px">This pattern is essential for long lasting and maintainable automation. It's not necessary for disposable scripts</span><br /> <br />  
+
<span style="font-size: 16px">This pattern is essential for long lasting and maintainable automation. It's not necessary for disposable scripts</span>  
=<span style="font-size: 16px">Description</span>=
+
=<span style="font-size: 16px">'''Description'''</span>=
 
<span style="font-size: 16px">Document the automation scripts and the test data, so that they are:</span><br />  
 
<span style="font-size: 16px">Document the automation scripts and the test data, so that they are:</span><br />  
 
 
* <span style="font-size: 16px">easily found </span>
 
* <span style="font-size: 16px">easily found </span>
 
* <span style="font-size: 16px">understandable</span>
 
* <span style="font-size: 16px">understandable</span>
 
* <span style="font-size: 16px">reusable</span>
 
* <span style="font-size: 16px">reusable</span>
 
* <span style="font-size: 16px">traceable (e.g. to requirements)</span>
 
* <span style="font-size: 16px">traceable (e.g. to requirements)</span>
<br />
+
=<span style="font-size: 16px">'''Implementation'''</span>=
=<span style="font-size: 16px">Implementation</span>=
 
 
<span style="font-size: 16px">Some suggestions:</span><br />  
 
<span style="font-size: 16px">Some suggestions:</span><br />  
 
 
* <span style="font-size: 16px">Documentation will be easier to write, maintain and read if you [[SET STANDARDS ]]</span>
 
* <span style="font-size: 16px">Documentation will be easier to write, maintain and read if you [[SET STANDARDS ]]</span>
 
* <span style="font-size: 16px">Descriptive names go a long way in documenting what some testware is or does</span>
 
* <span style="font-size: 16px">Descriptive names go a long way in documenting what some testware is or does</span>
Line 27: Line 24:
 
* <span style="font-size: 16px">Put the documentation in configuration management together with the testware and the corresponding release of the SUT </span>
 
* <span style="font-size: 16px">Put the documentation in configuration management together with the testware and the corresponding release of the SUT </span>
 
* <span style="font-size: 16px">If your current documentation is incomplete, let newbies update it: they learn faster and you get a better documentation</span>
 
* <span style="font-size: 16px">If your current documentation is incomplete, let newbies update it: they learn faster and you get a better documentation</span>
<br />  
+
* <span style="font-size: 16px">Automating the tests is also a good time to extract expert knowledge from your manual testers and to document it as automated test cases </span>
=<span style="font-size: 16px">Recommendations</span>=
+
 
<span style="font-size: 16px">Automating the tests is also a good time to extract expert knowledge from your manual testers and to document it as automated test cases</span><br /> <br />  
+
 
=<span style="font-size: 16px">Issues addressed by this pattern</span>=
+
=<span style="font-size: 16px">'''Potential Problems'''</span>=
<span style="font-size: 16px">''[[DATA CREEP]]''</span><br /> ''<span style="font-size: 16px">[[INADEQUATE DOCUMENTATION]]</span>''<br /> ''<span style="font-size: 16px">[[ INEFFICIENT EXECUTION]]</span>''<br /> ''<span style="font-size: 16px">[[INFLEXIBLE AUTOMATION]]</span>''<br /> ''<span style="font-size: 16px">[[KNOW-HOW LEAKAGE]]</span>''<br /> ''<span style="font-size: 16px">[[LIMITED EXPERIENCE]]</span>''<br /> ''<span style="font-size: 16px">[[ OBSCURE TESTS]]</span>''<br /> ''<span style="font-size: 16px">[[SCRIPT CREEP]]</span>''<br /> <br />
+
<span style="font-size: 16px">The documentation may not be clear to the intended audience. Get someone to review what is written to make sure it is at the right level of detail and covers what needs to be documented.</span><br /> <br />  
=<span style="font-size: 16px">Experiences</span>=
+
 
<span style="font-size: 16px">=Bryan Bakker= says: When documenting automated test cases it is a good idea to have the detailed documentation of the test cases in the test scripts directly. Code and documentation are together then, and making sure they are synchronized with every change is a lot easier (maintainability increases). When documentation is still needed (e.g. for reviews, regulatory) documentation can be generated with e.g. Doxygen.</span><br /> <span style="font-size: 16px">Test designs can still be in documentation of course.</span><br /> <br /> <span style="font-size: 16px">=James Tony=: Better to use a simple text file to describe what a test does – if that is enough to suit your needs</span><br /> <br /> <br /> <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 [[Process Patterns]] / Back to [[Test Automation Patterns]]</span></div>
+
=<span style="font-size: 16px">'''Issues addressed by this pattern'''</span>=
 +
<span style="font-size: 16px">''[[DATA CREEP]]''</span><br /> ''<span style="font-size: 16px">[[INADEQUATE DOCUMENTATION]]</span>''<br /> ''<span style="font-size: 16px">[[ INEFFICIENT EXECUTION]]</span>''<br /> ''<span style="font-size: 16px">[[INFLEXIBLE AUTOMATION]]</span>''<br /> ''<span style="font-size: 16px">[[KNOW-HOW LEAKAGE]]</span>''<br /> ''<span style="font-size: 16px">[[LIMITED EXPERIENCE]]</span>''<br /> ''<span style="font-size: 16px">[[ OBSCURE TESTS]]</span>''<br /> ''<span style="font-size: 16px">[[SCRIPT CREEP]]</span>''
 +
=<span style="font-size: 16px">'''Experiences'''</span>=
 +
 
 +
<span style="font-size: 16px">Bryan Bakker says: When documenting automated test cases it is a good idea to have the detailed documentation of the test cases in the test scripts directly. Code and documentation are together then, and making sure they are synchronized with every change is a lot easier (maintainability increases). When documentation is still needed (e.g. for reviews, regulatory) documentation can be generated with e.g. Doxygen.</span><br /> <span style="font-size: 16px">Test designs can still be in documentation of course.</span><br /> <br /> <span style="font-size: 16px">James Tony: Better to use a simple text file to describe what a test does – if that is enough to suit your needs</span><br /> <br /> <br />  
 +
 
 +
<span style="font-size: 16px">If you have also 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 [[Process Patterns]] / Back to [[Test Automation Patterns]]</span></div>

Latest revision as of 17:35, 19 September 2018

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

Pattern summary

Document the automation scripts and the test data.

Category

Process

Context

This pattern is essential for long lasting and maintainable automation. It's not necessary for disposable scripts

Description

Document the automation scripts and the test data, so that they are:

  • easily found
  • understandable
  • reusable
  • traceable (e.g. to requirements)

Implementation

Some suggestions:

  • Documentation will be easier to write, maintain and read if you SET STANDARDS
  • Descriptive names go a long way in documenting what some testware is or does
  • use naming conventions consistently to make available testware easy to find
  • Use a standard template as the Test Description: document in every script or batch file:
    • What does it do
    • How do you call it
    • What does it return
    • other relevant test characteristics (e.g. a smoke test, performance test, feature tested, TEST SELECTOR tags)
  • Put the documentation in configuration management together with the testware and the corresponding release of the SUT
  • If your current documentation is incomplete, let newbies update it: they learn faster and you get a better documentation
  • Automating the tests is also a good time to extract expert knowledge from your manual testers and to document it as automated test cases


Potential Problems

The documentation may not be clear to the intended audience. Get someone to review what is written to make sure it is at the right level of detail and covers what needs to be documented.

Issues addressed by this pattern

DATA CREEP
INADEQUATE DOCUMENTATION
INEFFICIENT EXECUTION
INFLEXIBLE AUTOMATION
KNOW-HOW LEAKAGE
LIMITED EXPERIENCE
OBSCURE TESTS
SCRIPT CREEP

Experiences

Bryan Bakker says: When documenting automated test cases it is a good idea to have the detailed documentation of the test cases in the test scripts directly. Code and documentation are together then, and making sure they are synchronized with every change is a lot easier (maintainability increases). When documentation is still needed (e.g. for reviews, regulatory) documentation can be generated with e.g. Doxygen.
Test designs can still be in documentation of course.

James Tony: Better to use a simple text file to describe what a test does – if that is enough to suit your needs


If you have also 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 Process Patterns / Back to Test Automation Patterns