Difference between revisions of "LATE TEST CASE DESIGN"
Jump to navigation
Jump to search
(Created page with "<div id="content_view" class="wiki" style="display: block"><span style="font-size: 14px">.........................................................................................") |
m (Topic titles in capital letters) |
||
| Line 1: | Line 1: | ||
<div id="content_view" class="wiki" style="display: block"><span style="font-size: 14px">.................................................................................................................[[Main Page]] / Back to [[Process Issues]] / Back to [[Test Automation Issues]]</span> | <div id="content_view" class="wiki" style="display: block"><span style="font-size: 14px">.................................................................................................................[[Main Page]] / Back to [[Process Issues]] / Back to [[Test Automation Issues]]</span> | ||
| − | =<span style=" | + | =<span style="font-size: 16px">'''Issue Summary'''</span>= |
| − | + | <span style="font-family: Arial; font-size: 16px">Automated test cases are designed and written only after the Software Under Test (SUT) has been implemented.</span><br /><span style="font-size: 16px">There is a prevailing misconception that automation cannot start until the software being tested is "stable". Although there are some things that may need to wait until you know exactly what the interface is, far more can be done much earlier than many people realise.</span> | |
| − | =<span style="font-size: 16px">Category</span>= | + | =<span style="font-size: 16px">'''Category'''</span>= |
| − | + | <span style="font-size: 16px">Process</span> | |
| − | =<span style=" | + | =<span style="font-size: 16px">'''Examples'''</span>= |
| − | |||
| − | |||
# <span style="font-family: Arial; font-size: 16px">The test automation efforts start only when the SUT has become quite stable, that is long after it has been developed.</span> | # <span style="font-family: Arial; font-size: 16px">The test automation efforts start only when the SUT has become quite stable, that is long after it has been developed.</span> | ||
# <span style="font-family: Arial; font-size: 16px">Test automation starts only when the GUI has been developed, so no test cases are written in advance.</span> | # <span style="font-family: Arial; font-size: 16px">Test automation starts only when the GUI has been developed, so no test cases are written in advance.</span> | ||
| − | + | =<span style="font-size: 16px">'''Questions'''</span>= | |
| − | =<span style=" | + | <span style="font-family: Arial; font-size: 16px">Who writes the test cases?</span><br /> <span style="font-family: Arial; font-size: 16px">Who does test automation?</span><br /> <span style="font-family: Arial; font-size: 16px">What things will need to be tested?</span><br /> <span style="font-family: Arial; font-size: 16px">Are the proposed tests too close to the software and to the tool? Has any thought been given to layers of abstraction between the tests and the implementation of the tests?</span> |
| − | + | =<span style="font-family: Arial; font-size: 16px">'''Resolving Patterns'''</span>= | |
| − | =<span style="font-family: Arial; font-size: 16px">Resolving Patterns</span>= | + | <span style="font-family: Arial; font-size: 16px">Most recommended:</span><br /> |
| − | |||
| − | |||
* <span style="font-family: Arial; font-size: 16px">[[DOMAIN-DRIVEN TESTING]]: This pattern works quite well when testers and automators belong to different teams and have different skills</span> | * <span style="font-family: Arial; font-size: 16px">[[DOMAIN-DRIVEN TESTING]]: This pattern works quite well when testers and automators belong to different teams and have different skills</span> | ||
* <span style="font-size: 16px">[[WHOLE TEAM APPROACH]]: this pattern takes care of issues like Examples 1. and 2., but it means that you have to completely overhaul how software is developed in your company. If you don't manage to get support for it, apply instead [[DOMAIN-DRIVEN TESTING]]</span> | * <span style="font-size: 16px">[[WHOLE TEAM APPROACH]]: this pattern takes care of issues like Examples 1. and 2., but it means that you have to completely overhaul how software is developed in your company. If you don't manage to get support for it, apply instead [[DOMAIN-DRIVEN TESTING]]</span> | ||
<br /> <span style="font-size: 16px">Other useful patterns:</span><br /> | <br /> <span style="font-size: 16px">Other useful patterns:</span><br /> | ||
| − | |||
* <span style="font-size: 16px">[[KEYWORD-DRIVEN TESTING]]: use this pattern when you have issues like Example 1. and developers to code the necessary keywords</span> | * <span style="font-size: 16px">[[KEYWORD-DRIVEN TESTING]]: use this pattern when you have issues like Example 1. and developers to code the necessary keywords</span> | ||
<br /> <span style="font-size: 14px">.................................................................................................................[[Main Page]] / Back to [[Process Issues]] / Back to [[Test Automation Issues]]</span></div> | <br /> <span style="font-size: 14px">.................................................................................................................[[Main Page]] / Back to [[Process Issues]] / Back to [[Test Automation Issues]]</span></div> | ||
Latest revision as of 09:44, 2 May 2018
.................................................................................................................Main Page / Back to Process Issues / Back to Test Automation Issues
.................................................................................................................Main Page / Back to Process Issues / Back to Test Automation Issues
Issue Summary
Automated test cases are designed and written only after the Software Under Test (SUT) has been implemented.
There is a prevailing misconception that automation cannot start until the software being tested is "stable". Although there are some things that may need to wait until you know exactly what the interface is, far more can be done much earlier than many people realise.
Category
Process
Examples
- The test automation efforts start only when the SUT has become quite stable, that is long after it has been developed.
- Test automation starts only when the GUI has been developed, so no test cases are written in advance.
Questions
Who writes the test cases?
Who does test automation?
What things will need to be tested?
Are the proposed tests too close to the software and to the tool? Has any thought been given to layers of abstraction between the tests and the implementation of the tests?
Resolving Patterns
Most recommended:
- DOMAIN-DRIVEN TESTING: This pattern works quite well when testers and automators belong to different teams and have different skills
- WHOLE TEAM APPROACH: this pattern takes care of issues like Examples 1. and 2., but it means that you have to completely overhaul how software is developed in your company. If you don't manage to get support for it, apply instead DOMAIN-DRIVEN TESTING
Other useful patterns:
- KEYWORD-DRIVEN TESTING: use this pattern when you have issues like Example 1. and developers to code the necessary keywords
.................................................................................................................Main Page / Back to Process Issues / Back to Test Automation Issues