There are unrealistic expectations regarding what test automation can and cannot deliver.
Usually it is managers who have unrealistic expectations for automation - sometimes they are hoping for a "silver bullet" that will solve all of their problems.
However, others may also have unrealistic expectations. For example, testers may believe that automated tests will "notice" things that a human being would notice, or developers may think that tests will "automate themselves" and testers are not needed to identify which tests are best to automate.
Examples of unrealistic expectations
- Every single (manual) test case can and should be automated.
- Even if the SUT is changed almost daily, the tests should be automated (now).
- There is no need to spend time developing a framework - the manager bought you the tool, now just get on with it.
- When automated tests pass, it means there are no defects in the software.
- Running an automated test the first time automatically gives Return on Investment (even if it takes 10 times longer to automate the test than it would to run it manually).
- Any manual tester can write automated test cases directly in the tool scripting language.
- Maintenance of automated tests will not be needed, or has a very small cost.
- Managers don't understand that introduction of test automation introduces a parallel development process and thus increases cost.
What do managers expect that automation will do for the company?
What sources have they used to find out about automation?
What do they see as the limitations of automation?
What investment do they think is still needed in automation?
How will they measure the benefits of automation?
- SET CLEAR GOALS: Apply this pattern if you still have to begin. If you are already automating, take a step back and apply this pattern so long until everybody has the same understanding of test automation
- DO A PILOT: When the automation effort hasn't started yet, apply this pattern to clarify what automation can and cannot do, what resources you will need (tools, people) etc.
- SHARE INFORMATION: This pattern is useful to resolve this issue if you are already in the thick of test automation. If people believe any of the things in the list above of unrealistic expectations, you will need to educate them to explain why this is not realistic.
Other useful patterns:
- TAKE SMALL STEPS: Use this pattern to show what can realistically be achieved within a short time frame such as a single Sprint