Difference between revisions of "PLAN SUPPORT ACTIVITIES"
Line 30: | Line 30: | ||
=<span style="font-size: 16px">'''Experiences'''</span>= | =<span style="font-size: 16px">'''Experiences'''</span>= | ||
− | <span style="font-size: 16px">If you have also used this pattern and would like to contribute your experience to the wiki, please go to [[ | + | <span style="font-size: 16px">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.</span><br /> <br /> |
<span style="font-size: 14px">.................................................................................................................[[Main Page]] / Back to [[Management Patterns]] / Back to [[Test Automation Patterns]]</span></div> | <span style="font-size: 14px">.................................................................................................................[[Main Page]] / Back to [[Management Patterns]] / Back to [[Test Automation Patterns]]</span></div> |
Latest revision as of 14:48, 21 August 2018
.................................................................................................................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.