UNAUTOMATABLE TEST CASES

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

Issue summary

Existing test cases are “unautomatable”

Category

Design

Examples

1. Test cases are written in a very "terse" way assuming that manual testers know the SUT inside out. Automators usually cannot understand what they are supposed to automate.
2. Test cases build on each other to complex scenarios that make it very difficult to write test cases independent from each other
3. Test cases are performed only once in a while and are quite complicated

Questions

Who writes the test cases?
Has time been planned to explain the test cases to the automation team?

Resolving Patterns

Most recommended:

• SSHARE INFORMATION: apply this pattern to clear misunderstandings between testers and automators
• WHOLE TEAM APPROACH: apply this pattern to get rid of misunderstandings in the team
• THINK OUT-OF-THE-BOX THINK OUT-OF-THE-BOX: try to look at the problem from unusual viewpoints

Other useful patterns:

• KNOW WHEN TO STOP: this pattern helps to recognize that not all tests are automatable
• MANAGEMENT SUPPORT: you will need to use this pattern especially if you want to implement a WHOLE TEAM APPROACH and nobody is going agile yet in your company
• PAIR UP PAIR UP: apply this pattern to enhance communication and learning between testers and automators

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