UNAUTOMATABLE TEST CASES
Jump to navigation
Jump to search
.................................................................................................................Main Page / Back to Design Issues / Back to Test Automation Issues
.................................................................................................................Main Page / Back to Design Issues / Back to Test Automation Issues
Issue summary
Existing test cases are “unautomatable”
Category
Design
Examples
- 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.
- Test cases build on each other to complex scenarios that make it very difficult to write test cases independent from each other
- 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:
- SHARE 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: 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: apply this pattern to enhance communication and learning between testers and automators
.................................................................................................................Main Page / Back to Design Issues / Back to Test Automation Issues