Difference between revisions of "MANAGEMENT SUPPORT"
m (Topic titles in capital letters) |
m (Corrected link to management patterns) |
||
Line 1: | Line 1: | ||
<div id="content_view" class="wiki" style="display: block"> | <div id="content_view" class="wiki" style="display: block"> | ||
− | <span style="font-size: 14px">.................................................................................................................[[Main Page]] / Back to [Management Patterns]] / Back to [[Test Automation Patterns]]</span><br /> | + | <span style="font-size: 14px">.................................................................................................................[[Main Page]] / Back to [[Management Patterns]] / Back to [[Test Automation Patterns]]</span><br /> |
=<span style="font-size: 16px">'''Pattern summary'''</span>= | =<span style="font-size: 16px">'''Pattern summary'''</span>= | ||
<span style="font-size: 16px">Earn management support. Managers should only support sound and well-reasoned activities, so we need to work at selling the idea initially and then keep them up-to-date with progress and issues.</span><br /> | <span style="font-size: 16px">Earn management support. Managers should only support sound and well-reasoned activities, so we need to work at selling the idea initially and then keep them up-to-date with progress and issues.</span><br /> |
Revision as of 09:48, 28 April 2018
.................................................................................................................Main Page / Back to Management Patterns / Back to Test Automation Patterns
Pattern summary
Earn management support. Managers should only support sound and well-reasoned activities, so we need to work at selling the idea initially and then keep them up-to-date with progress and issues.
Category
Management
Context
This pattern is applicable when test automation is intended to be used by many people within an organisation.
This pattern is not applicable for one person beginning to experiment with a tool to see what it can do.
Description
Many issues can only be solved with good management support.
When you are starting (or re-starting) test automation, you need to show managers that the investment in automation (not just in the tools) has a good potential to give real and lasting benefits to the organisation.
In an ongoing project, inform regularly on the status and draw special attention to any success or return on investment. You still need to have good communication and a good level of understanding of current issues from management.
Sometimes a single incident can be more convincing than a large set of numbers, for example if a recurring bug is found by an automated regression test for a user that had complained about this same bug twice before.
Implementation
Some suggestions when starting (or re-starting) test automation:
- Make sure to SET CLEAR GOALS. Either review existing goals for automation, or meet with managers to ensure that their expectations are realistic and adequately resourced and funded.
- Build a convincing TEST AUTOMATION BUSINESS CASE. Test automation can be quite expensive and requires, especially at the beginning, a lot of effort.
- A good way to convince management is to DO A PILOT. In this way they can actually “touch” the advantages of test automation and it will be much easier to win them over.
- Another advantage is that it is much easier to SELL THE BENEFITS of a limited pilot than of a full test automation project. After your pilot has been successful, you will have a much better starting position to obtain support for what you actually intend to implement.
Some suggestions for on-going test automation:
- If you don't have one, appoint a TEST AUTOMATION OWNER to monitor test automation health.
- SHARE INFORMATION about the automation. People soon forget about the benefits that have been achieved, so it is good to keep reminding them.
- If you have INADEQUATE SUPPORT you may have to free some people from their current assignments.
- If you have INADEQUATE TOOLS you may need to invest in new tools or build or revise your TEST AUTOMATION FRAMEWORK.
- In these cases you may need to SELL THE BENEFITS in order to convince management that the investment will be worthwhile.
Potential Problems
It is almost equally important to set realistic expectations about what the test automation project can deliver. UNREALISTIC EXPECTATIONS can lead to disappointment and frustration and you can lose management support just when you need it most.
Another problem that can arise is that the manager talks about supporting you and claims to support your efforts. But when you need to take some additional time or use additional resources, then "sorry, they are not available". This is not true support, but "lip service".
It is also possible to inadvertently set UNREALISTIC EXPECTATIONS by being overly enthusiastic about what can be accomplished early on in automation. It can be easy to show good results when you haven’t yet encountered any of the problems that will occur later, such as the cost of maintaining the automated tests when the software under test is changed. (thanks to Jonathan Wright for mentioning this at EuroStar)
Issues addressed by this pattern
AD-HOC AUTOMATION
AUTOMATION DECAY
BRITTLE SCRIPTS
DATA CREEP
HIGH ROI EXPECTATIONS
INADEQUATE RESOURCES
INADEQUATE SUPPORT
INADEQUATE TOOLS
NO PREVIOUS TEST AUTOMATION
SCHEDULE SLIP
SCRIPT CREEP
STALLED AUTOMATION
SUT REMAKE
TOO EARLY AUTOMATION
UNAUTOMATABLE TEST CASES
UNFOCUSED AUTOMATION
Experiences
If you have used this pattern, please add your name and a brief story of how you used this pattern: your context, what you did, and how well it worked - or how it didn't work!.................................................................................................................Main Page / Back to Management Patterns / Back to Test Automation Patterns
B2