Difference between revisions of "MANAGEMENT SUPPORT"
Jump to navigation
Jump to search
(Created page with "<div id="content_view" class="wiki" style="display: block"> <span style="font-size: 14px">.......................................................................................") |
|||
| (4 intermediate revisions by 2 users not shown) | |||
| 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 /> | ||
| − | =<span style="font-size: 16px">Category</span>= | + | =<span style="font-size: 16px">'''Category'''</span>= |
<span style="font-size: 16px">Management</span> | <span style="font-size: 16px">Management</span> | ||
| − | =<span style="font-size: 16px">Context</span>= | + | =<span style="font-size: 16px">'''Context'''</span>= |
<span style="font-size: 16px">This pattern is applicable when test automation is intended to be used by many people within an organisation.</span><br /> <span style="font-size: 16px">This pattern is not applicable for one person beginning to experiment with a tool to see what it can do.</span> | <span style="font-size: 16px">This pattern is applicable when test automation is intended to be used by many people within an organisation.</span><br /> <span style="font-size: 16px">This pattern is not applicable for one person beginning to experiment with a tool to see what it can do.</span> | ||
| − | =<span style="font-size: 16px">Description</span>= | + | =<span style="font-size: 16px">'''Description'''</span>= |
<span style="font-size: 16px">Many issues can only be solved with good management support. </span><br /> <span style="font-size: 16px">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.</span><br /> <span style="font-size: 16px">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.</span><br /> <span style="font-size: 16px">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.</span><br /> <br /> | <span style="font-size: 16px">Many issues can only be solved with good management support. </span><br /> <span style="font-size: 16px">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.</span><br /> <span style="font-size: 16px">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.</span><br /> <span style="font-size: 16px">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.</span><br /> <br /> | ||
| − | =<span style="font-size: 16px">Implementation</span>= | + | =<span style="font-size: 16px">'''Implementation'''</span>= |
<span style="font-size: 16px">Some suggestions when starting (or re-starting) test automation:</span><br /> | <span style="font-size: 16px">Some suggestions when starting (or re-starting) test automation:</span><br /> | ||
| Line 26: | Line 26: | ||
* <span style="font-size: 16px">In these cases you may need to [[SELL THE BENEFITS]] in order to convince management that the investment will be worthwhile.</span> | * <span style="font-size: 16px">In these cases you may need to [[SELL THE BENEFITS]] in order to convince management that the investment will be worthwhile.</span> | ||
| − | =<span style="font-size: 16px">Potential Problems</span>= | + | =<span style="font-size: 16px">'''Potential Problems'''</span>= |
<span style="font-size: 16px">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.</span><br /> <br /> <span style="font-size: 16px">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".</span><br /> <br /> <span style="font-family: Arial; font-size: 12pt">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)</span><br /> | <span style="font-size: 16px">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.</span><br /> <br /> <span style="font-size: 16px">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".</span><br /> <br /> <span style="font-family: Arial; font-size: 12pt">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)</span><br /> | ||
| − | =<span style="font-size: 16px">Issues addressed by this pattern</span>= | + | =<span style="font-size: 16px">'''Issues addressed by this pattern'''</span>= |
<span style="font-size: 16px">''[[AD-HOC AUTOMATION]]''</span><br /> ''<span style="font-size: 16px">[[AUTOMATION DECAY]]</span>''<br /> <span style="font-size: 16px">''[[BRITTLE SCRIPTS]]''</span><br /> ''<span style="font-size: 16px">[[DATA CREEP]]</span>''<br /> <span style="font-size: 16px">''[[HIGH ROI EXPECTATIONS]]''</span><br /> ''<span style="font-size: 16px">[[INADEQUATE RESOURCES]]</span>''<br /> <span style="font-size: 16px">''[[INADEQUATE SUPPORT]]''</span><br /> <span style="font-size: 16px">''[[INADEQUATE TOOLS]]''</span><br /> <span style="font-size: 16px">''[[NO PREVIOUS TEST AUTOMATION]]''</span><br /> <span style="font-size: 16px">''[[SCHEDULE SLIP]]''</span><br /> ''<span style="font-size: 16px">[[SCRIPT CREEP]]</span>''<br /> <span style="font-size: 16px">''[[STALLED AUTOMATION]]''</span><br /> <span style="font-size: 16px">''[[SUT REMAKE]]''</span><br /> ''<span style="font-size: 16px">[[TOO EARLY AUTOMATION]]</span>''<br /> <span style="font-size: 16px">''[[UNAUTOMATABLE TEST CASES]]''</span><br /> ''<span style="font-size: 16px">[[ UNFOCUSED AUTOMATION]]</span>'' | <span style="font-size: 16px">''[[AD-HOC AUTOMATION]]''</span><br /> ''<span style="font-size: 16px">[[AUTOMATION DECAY]]</span>''<br /> <span style="font-size: 16px">''[[BRITTLE SCRIPTS]]''</span><br /> ''<span style="font-size: 16px">[[DATA CREEP]]</span>''<br /> <span style="font-size: 16px">''[[HIGH ROI EXPECTATIONS]]''</span><br /> ''<span style="font-size: 16px">[[INADEQUATE RESOURCES]]</span>''<br /> <span style="font-size: 16px">''[[INADEQUATE SUPPORT]]''</span><br /> <span style="font-size: 16px">''[[INADEQUATE TOOLS]]''</span><br /> <span style="font-size: 16px">''[[NO PREVIOUS TEST AUTOMATION]]''</span><br /> <span style="font-size: 16px">''[[SCHEDULE SLIP]]''</span><br /> ''<span style="font-size: 16px">[[SCRIPT CREEP]]</span>''<br /> <span style="font-size: 16px">''[[STALLED AUTOMATION]]''</span><br /> <span style="font-size: 16px">''[[SUT REMAKE]]''</span><br /> ''<span style="font-size: 16px">[[TOO EARLY AUTOMATION]]</span>''<br /> <span style="font-size: 16px">''[[UNAUTOMATABLE TEST CASES]]''</span><br /> ''<span style="font-size: 16px">[[ UNFOCUSED AUTOMATION]]</span>'' | ||
| − | =<span style="font-size: 16px">Experiences</span>= | + | =<span style="font-size: 16px">'''Experiences'''</span>= |
| − | <span style="font-size: 16px">If you have used this pattern, please | + | |
| + | <span style="font-size: 16px">If you have used this pattern and would like to contribute your experience to the wiki, please go to [[Feedback]] to submit your experience or comment.</span><br /> <br /> | ||
| + | |||
| + | |||
| + | <span style="font-size: 14px">.................................................................................................................[[Main Page]] / Back to [[Management Patterns]] / Back to [[ Test Automation Patterns]]</span></div> | ||
Latest revision as of 14:47, 21 August 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 and would like to contribute your experience to the wiki, please go to Feedback to submit your experience or comment.