Difference between revisions of "AD-HOC AUTOMATION"
Jump to navigation
Jump to search
m (empty lines removed) |
|||
| Line 24: | Line 24: | ||
* <span style="font-size: 16px"><span style="font-size: 16px">[[DO A PILOT]]: </span>Start a pilot project to explore how to best automate tests for the application.</span> | * <span style="font-size: 16px"><span style="font-size: 16px">[[DO A PILOT]]: </span>Start a pilot project to explore how to best automate tests for the application.</span> | ||
* <span style="font-size: 16px">[[TEST AUTOMATION BUSINESS CASE]]: this pattern may be needed when you start planning test automation or to justify making changes to existing automation that has stalled or not given sufficient benefit.</span> | * <span style="font-size: 16px">[[TEST AUTOMATION BUSINESS CASE]]: this pattern may be needed when you start planning test automation or to justify making changes to existing automation that has stalled or not given sufficient benefit.</span> | ||
| − | <br /> <span style="font-size: 14px">................................................................................................................[[Main Page]] / Back to [[ Management Issues]] / Back to [[Test Automation Issues]] | + | <br /> <span style="font-size: 14px">................................................................................................................[[Main Page]] / Back to [[ Management Issues]] / Back to [[Test Automation Issues]]</span></div> |
Latest revision as of 09:58, 26 June 2018
................................................................................................................Main Page / Back to Management Issues / Back to Test Automation Issues
................................................................................................................Main Page / Back to Management Issues / Back to Test Automation Issues
Issue Summary
Automation is done ad-hoc with no planning or preparation.
"Ad hoc" means something created or done only for a particular purpose, impromptu, expedient, improvised, makeshift, "rough and ready".
Category
Management
Examples
- Management thought that buying a tool was enough. Goals, architecture, resources etc. have not been planned or considered
- Expenses for test automation resources have not been budgeted
- There are not enough machines on which to run automation
- The databases for automation have to be shared with development or testing
- There are not enough tool licences
- Automation is done "on the side" when one has time to spare
- Support from testers, developers or other specialists has not been planned, so they have no time to help
Questions
Who is doing automation? Is somebody in charge?
Does management know about it? Do they support it?
Resolving Patterns
Most recommended:
- TEST AUTOMATION OWNER: Appoint an owner for the test automation effort. If there is already a "champion" give him or her public support. The owner, once test automation has been established, controls that it stays "healthy" and keeps an eye on new tools, techniques or processes in order to improve it.
- MANAGEMENT SUPPORT: you need this pattern in order to be able to apply the other patterns.
- DEDICATED RESOURCES: helps you get the resources you need.
- WHOLE TEAM APPROACH: if your developer team uses an agile development process, this is the pattern of choice.
Other useful patterns:
- SET CLEAR GOALS: Define the automation goals from the very beginning and when you want to re-vitalise a stalled automation effort.
- DO A PILOT: Start a pilot project to explore how to best automate tests for the application.
- TEST AUTOMATION BUSINESS CASE: this pattern may be needed when you start planning test automation or to justify making changes to existing automation that has stalled or not given sufficient benefit.
................................................................................................................Main Page / Back to Management Issues / Back to Test Automation Issues