MANAGEMENT SUPPORT

From Test Automation Patterns
Revision as of 09:48, 28 April 2018 by Seretta (talk | contribs) (Corrected link to management patterns)
Jump to navigation Jump to search

.................................................................................................................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:

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