PLAN SUPPORT ACTIVITIES

From Test Automation Patterns
Revision as of 14:48, 21 August 2018 by Dorothy (talk | contribs) (→‎Experiences)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

.................................................................................................................Main Page / Back to Management Patterns / Back to Test Automation Patterns

Pattern summary

Plan time and resources not only for the project goals, but also for support activities.

Category

Management

Context

This pattern is appropriate if you are to have long lasting automation, since you will need specialists both for implementing new automation and for maintaining it.
This pattern isn't appropriate for one-off or disposable scripts, or for short-term one-off automation efforts where support will not be required.

Description

Planning often focuses on initial and major changes, such as acquiring a new tool. However, planning should also be done for the ongoing activities that will be needed to provide continuous support for the automation, after the initial major changes. If such support is not planned, technical debt can build up and can cause serious damage to the test automation.

Implementation

Your planning should already have taken into account the time and effort needed to get started, and you may already have done a pilot. Once the pilot has shown that automation can work for your organisation, there will be ongoing investment needed to continually support the automation.
For example, more people may need to become familiar with the tool; for this you may need to GET TRAINING.
You may need knowledge and advice from specialists for particular technical problems with the tests, so don't be afraid to ASK FOR HELP.
You may also need to work closely with the developers of the Software under Test (SUT) to make sure that the software is testable using the automation, so SHARE INFORMATION about what you need, and also ask what you can do to help them. For example, if you can quickly run some smoke tests, that may benefit the developers, and they will be more likely to cooperate with you.

Although you may not know in advance what support activities will be needed, it is important to anticipate that some will be needed!


In your business case don’t forget to plan resources and time for:

  • Testing and bug fixing of the automated tests
  • Refactoring (SUT and the testware)
  • Training, both in the tool itself and in the regime that you put in place for effective automation (e.g. local naming conventions)
  • Support from developers, database specialists, network administrators and others


Your managers may not appreciate what is needed or what you are spending time on. At every presentation show your managers why you need this extra time and resources. Calculate the costs and the technical debt of ignoring this issue.

Potential problems

Problems could be:

  • You need more time than was planned to automate test cases, because you are not well acquainted with the tool
  • You need support from testers because the manual test cases are not documented well enough or are not ‘automatable’
  • You need support from IT specialists (e.g. database managers), but they never have time
  • You need support from the developers of the SUT, but they are always busy
  • The SUT is not really “testable”
  • Your test suites find lots of bugs, but there is no time to fix them or the fixing takes longer than expected.
  • You would like to refactor your testware, but you never have the time or the resources to do it

Issues addressed by this pattern

HIGH ROI EXPECTATIONS
INADEQUATE SUPPORT
NO PREVIOUS TEST AUTOMATION
SCHEDULE SLIP
UNAUTOMATABLE TEST CASES
UNMOTIVATED TEAM

Experiences

If you have also used this pattern and would like to contribute your experience to the wiki, please go to Feedback to submit your experience or comment.


.................................................................................................................Main Page / Back to Management Patterns / Back to Test Automation Patterns