SCHEDULE SLIP

From Test Automation Patterns
Revision as of 14:57, 27 June 2018 by Seretta (talk | contribs)
(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

The planned automation is not keeping up with its schedule for developing the automation or for automating tests.

Category

Management

Examples

  1. Test automation is done only in people's spare time
  2. Team members are working on concurrent tasks which take priority over automation tasks
  3. Schedules for what automation can be done were too optimistic
  4. Necessary software or hardware is not available on time or has to be shared with other projects
  5. The planned schedule was not realistic

Questions

What is the priority for test automation?
Is test automation supported by management or is it performed by a "lone crusader"?
Who is doing the planning for test automation? How is the required time for automation calculated?
What software or hardware is needed? When?

Resolving Patterns

Most recommended:

  • SHORT ITERATIONS: using this pattern you will be able to deliver something sooner, even if not what you had originally hoped or planned
  • WHOLE TEAM APPROACH: if development is using an agile process, then this is the pattern to apply
  • DEDICATED RESOURCES: this pattern will help you pick up speed.
  • PLAN SUPPORT ACTIVITIES: use this pattern from the beginning so that resources are available when needed


Other useful patterns:


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