STALLED AUTOMATION

From Test Automation Patterns
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.
.................................................................................................................Main Page / Back to Process Issues / Back to Test Automation Issues

Issue Summary

Automation has been tried, but it never "got off the ground" or has now fallen into disuse.

Category

Process

Examples

  1. The automation tools were tried, but are not used efficiently or have already become shelf-ware.
  2. The current tools are no longer supported or don't fit the current version of the Software Under Test (SUT).
  3. The automation has been implemented by a lone champion without any support from management and he or she has left the company.
  4. Testers are expected to do the test automation, but cannot use the tools efficiently (see NON-TECHNICAL-TESTERS)
  5. You wanted to automate everything and got stuck with not automatable features.
  6. The SUT changes so fast that you just have time to fix the current automation, but have no resources to do new stuff.
  7. In order to automate new functionalities you need resources or specialists that are not available.
  8. No one is adding new automated tests, so only what already exists is used, and no one is looking at it.
  9. Existing tests are being run, but if there are problems with a test, it is more likely to be removed than the problem to be fixed.

Questions

Who is doing the automation?
Is someone coordinating the automation efforts or is everyone on their own?
Who has selected the tools and how?
Are the current tools being used? If not, why not?
Has all existing and previous work in automation been documented?
What has changed since the automation was originally developed?
Can you quantify the benefit of investing resources (time, effort) into the automation?

Resolving Patterns

Most recomended:

  • DO A PILOT: Use this pattern to find out why the automation effort got stalled and what to do about it.
  • LAZY AUTOMATOR: This is the right pattern for a lone champion!
  • MAINTAIN THE TESTWARE: You should already be using this pattern. Not using it could be why your automation effort has stalled.
  • TEST AUTOMATION OWNER: appoint an "owner". If nobody feels ownership for test automation, nobody will really care if it's successful or not
  • WHOLE TEAM APPROACH: Use this pattern if you want your test automation effort to be effective and successful. It will be easy to implement if the development team for the SUT already adopted an agile process. Otherwise you will have to convince development to do so before you can apply this pattern.


Other useful Patterns:

  • ABSTRACTION LEVELS: use this pattern if your issue is similar to Example 4.
  • KNOW WHEN TO STOP: This pattern helps you recognize that you cannot automate everything (see Example 5.)
  • LEARN FROM MISTAKES: this pattern helps turn mistakes into learning experiences.
  • MANAGEMENT SUPPORT: Apply this pattern to get the support you need in order to use other patterns.
  • SELL THE BENEFITS: If your issue is similar to Example 3. and nobody is supporting you, this pattern can help you get the support you need.
  • TAKE SMALL STEPS: Apply this pattern to get going again with the automation effort.
  • TEST AUTOMATION FRAMEWORK: Check if your problems would be solved with this pattern.

.................................................................................................................Main Page / Back to Process Issues / Back to Test Automation Issues