UNAUTOMATABLE TEST CASES
Jump to navigation
Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.
.................................................................................................................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