Automation effectiveness
When we start script development we can focus on the following benefits:
- Time
- Budget
- Quality
Automation could be effective only in the case when one of the listed benefits is reached. All three benefits are very hard target that is almost unreachable. Stakeholders should identify desired benefits as it strongly influences the automation process.
Let’s consider any benefit in detail.
Time
Automation time includes:
- Development time (one-time activity)
- Support scripts time (continuous activity)
Manual time includes:
- Test case writing time (on time activity)
- Execution time (continuous activity)
To get time benefit with automation tests: «Automation time» should be less then «Manual time».
This could be achieved if: Support scripts time (continuous) < Execution time (continuous)
Automation script time benefits
For a fixed application scope and team, project gets time benefit right after automated test development is complete. Test team can perform additional tasks as it has spare time.
Budget
Automation budget includes:
- Tool cost
- Development cost
- Support cost
Manual Budget includes:
- Test documentation writing
- Execution cost
To get Budget benefit with automation tests:
Automation budget less then Manual budget
This could be achieved if:
Execution cost > Support cost

Automation script budget benefit
Usually, budget gets benefit from automation much later than a time benefit. This is caused by a non-zero automation tool cost. However, in the case of using a freeware automation tool, budget gets its benefit from automation exactly at the same time. In the case when auto tests support time is more then manual tests time, automation will NEVER bring any benefits to the project.
Quality
Automation quality:
- Consistent tests
- Consistent test data
- Minor defects may left unrevealed for a long time
Manual quality:
- Human factor
- Flexible coverage
- Inconsistent test data
- Work-around
To get Quality benefit with automation tests:
Automation quality should be more then Manual quality
This is true for rarely changed parts of application only: core part functionality, ready to production modules, etc.

Комментарии