INFLEXIBLE AUTOMATION

.................................................................................................................Main Page / Back to Execution Issues / Back to Test Automation Issues

Issue Summary

Execution of automated tests is ad-hoc or too rigid. Subsets of tests cannot be selected to run - it's "all or nothing".

Category

Execution

Examples

1. It is difficult to select a subset of tests in order to test only some special feature, or to run a different set of regression tests than last time.
2. Automated tests can be run only by one person. If he / she is on sick leave the tests don't run!
3. Your test suites cannot be used for smoke tests because all the tests build on each other.
4. To run an automated test again you have to make a lot of manual changes to the tests

Questions

Do you know what every test does? Is this documented?
Who can run the tests? Who decides what tests to run?
How do the different test cases in a test suite relate to each other? Are there dependencies?
Do the tests have different priorities?

Resolving Patterns

Most recommended:

• TEST SELECTOR: Implement your test cases so that you can turn on various selection criteria for whether or not a given test is included in an execution run (example 1)
• UNATTENDED TEST EXECUTION: This pattern is what you want to automate your tests for! Use it!
• INDEPENDENT TEST CASES: Apply this pattern if your tests build on each other too much (example 3)
• TESTWARE ARCHITECTURE: Apply this pattern to avoid problems such as MANUAL INTERVENTIONS in automated testing (example 4)
• PRIORITIZE TESTS: Apply this pattern to take advantage of flexible execution, e.g. you have time to run some tests but not all of them.

Other useful patterns:

• DOCUMENT THE TESTWARE: use this pattern so that you know what each test does

................................. .................................................................................Main Page / Back to Execution Issues / Back to Test Automation Issues