LATE TEST CASE DESIGN

.................................................................................................................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

1. The test automation efforts start only when the SUT has become quite stable, that is long after it has been developed.
2. 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