AD-HOC AUTOMATION

From Test Automation Patterns
Revision as of 08:19, 5 April 2018 by Cathal (talk | contribs) (Created page with "<div id="content_view" class="wiki" style="display: block"><span style="font-size: 14px">.........................................................................................")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
................................................................................................................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
B10