Parent page: Test Automation Problems

Coverage

 How thoroughly script goes through the test case flow and how many test cases are automated per test plan?  

Points of consideration 

1)     Scattered vs. in-depth functionality coverage 

• Each functionality module of the application requires initial effort spent on GUI mapping and common functions development. However, this effort is not a pure investment as changes in the application will require updating of GUI maps and library functions. So the benefit of automation is significantly increased if test assets are used as much in possible 
• Any script does “see” GUI elements only if it is actually coded to do that with input or verification operation. Automatically populating only mandatory controls leaves a significant part of a window or a web page not verified, while manual tester still performs an informal check of the entire GUI in the same place 

2)     Test flow reusability 

• Most of test cases within the same functionality module of the application have overlapping test flow: same windows (pages), same controls, and even same test data. Adding extra few steps to already implemented test flow could allow covering a couple of more test cases 
• Negative and boundary testing test cases repeat positive test flow completely except the PASS/FAIL criteria. Enhancing scripts with error-handling based on recovery scenarios not only greatly increases Robustness but also allows reusing positive test case scripts for negative and boundary testing