Сегодня я буду рассуждать на тему эффективности автоматизации продукта причем в отрыве от инструментов и процессов и лишь немного затронув области, в которых она действительно необходима.

Исторически сложилось, что автоматизацию часто рассматривают в сравнении с ручным тестированием, и потому, если у вас нет специфических задач, которые могут быть решены только с помощью автоматизации – сравнение имеет смысл.

Итак, автоматизацию в общей случае имеет смысл реализовывать если соблюдается условие:

TAcr/N + TAerrval + TAupd < TMval* N,
где
N – количество выполнений в течении одной итерации;
TAcr – время на создание автоматического теста;
TAerrval – среднее время на понимание причины “падения” авто-теста;
TAupd – среднее время на апдейт авто-теста;
TMval – среднее время ручной проверки.

Таким образом, мы получаем следующий вывод: чем чаще авто-тесты выполняются и чем меньше время на создание, апдейт и анализ результатов выполнения тем более эффективна автоматизация.
Более того, если добавить коэффициент приоритета области продукта и убрать сравнение с ручным тестированием, можно получить формулу вычисления эффективности автоматизации разных областей одного и того же продукта.

Теперь становиться гораздо наглядней следующие моменты:

• почему не выгодно автоматизировать функционал, который нужно проверить всего несколько раз;
• почему выгодно автоматизировать регрессию;
• почему тестирование API всегда более выгодно автоматизировать;
• почему очень важно иметь высокий уровень абстракции в инструменте автоматизации;
• почему так важно иметь иметь качественное логгирование результатов выполнения авто-тестов

Уменьшить время проверки можно эффективной схемой анализа результатов и дизайна авто-скриптов.
Ответы на следующие вопрос должны быть получены как можно ранее:

• К какому функционалу каждая из ошибок принадлежит?
• Какие действия выполнял скрипт в момент появления ошибки?
• В каком состоянии было приложение и какими были динамические данные в момент выполнения авто-теста?

Время на создание и апдейт авто-скриптов может быть уменьшено использованием DRY принципов и техниками уменьшения зависимостей от приложения, т.е. увеличением уровня абстракции и вынесением общего функционала в компоненты.