Difference between revisions of "UNREALISTIC EXPECTATIONS"
(Created page with "<div id="content_view" class="wiki" style="display: block"><span style="font-size: 14px">.........................................................................................") |
|||
Line 1: | Line 1: | ||
<div id="content_view" class="wiki" style="display: block"><span style="font-size: 14px">.................................................................................................................[[Main Page]] / Back to [[Management Issues]] / Back to [[Test Automation Issues]]</span><br /> | <div id="content_view" class="wiki" style="display: block"><span style="font-size: 14px">.................................................................................................................[[Main Page]] / Back to [[Management Issues]] / Back to [[Test Automation Issues]]</span><br /> | ||
=<span style="font-size: 16px">Issue summary</span>= | =<span style="font-size: 16px">Issue summary</span>= | ||
− | <br /> <span style="font-size: 16px">There are unrealistic expectations regarding what test automation can and cannot deliver. The [[UNREALISTIC%20EXPECTATIONS%20Mind%20Map | + | <br /> <span style="font-size: 16px">There are unrealistic expectations regarding what test automation can and cannot deliver. The [[UNREALISTIC%20EXPECTATIONS%20Mind%20Map]] shows an overview of the resolving patterns for this issue.</span><br /> <br /> <span style="font-size: 16px">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.</span><br /> <br /> <span style="font-size: 16px">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.</span><br /> <br /> <br /> |
=<span style="font-family: Arial; font-size: 16px">Category</span>= | =<span style="font-family: Arial; font-size: 16px">Category</span>= | ||
<br /> <span style="font-family: Arial; font-size: 16px">Management</span><br /> <br /> | <br /> <span style="font-family: Arial; font-size: 16px">Management</span><br /> <br /> |
Revision as of 08:15, 5 April 2018
Issue summary
There are unrealistic expectations regarding what test automation can and cannot deliver. The UNREALISTIC EXPECTATIONS Mind Map shows an overview of the resolving patterns for this issue.
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.
Category
Management
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.
Questions
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?
Resolving Patterns
Most recommended:
- 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 pattern:
- TAKE SMALL STEPS: Use this pattern to show what can realistically be achieved within a short time frame such as a single Sprint
.................................................................................................................Main Page / Back to Management Issues / Back to Test Automation Issues