Difference between revisions of "AD-HOC AUTOMATION"

From Test Automation Patterns
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]]</span><br /> <span style="font-size: 14px">B10</span></div>
+
<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

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