Сегодня я буду рассуждать на тему эффективности автоматизации продукта причем в отрыве от инструментов и процессов и лишь немного затронув области, в которых она действительно необходима.
Исторически сложилось, что автоматизацию часто рассматривают в сравнении с ручным тестированием, и потому, если у вас нет специфических задач, которые могут быть решены только с помощью автоматизации – сравнение имеет смысл.
Итак, автоматизацию в общей случае имеет смысл реализовывать если соблюдается условие:
TAcr/N + TAerrval + TAupd < TMval* N,
где
N – количество выполнений в течении одной итерации;
TAcr – время на создание автоматического теста;
TAerrval – среднее время на понимание причины “падения” авто-теста;
TAupd – среднее время на апдейт авто-теста;
TMval – среднее время ручной проверки.
Таким образом, мы получаем следующий вывод: чем чаще авто-тесты выполняются и чем меньше время на создание, апдейт и анализ результатов выполнения тем более эффективна автоматизация.
Более того, если добавить коэффициент приоритета области продукта и убрать сравнение с ручным тестированием, можно получить формулу вычисления эффективности автоматизации разных областей одного и того же продукта.
Теперь становиться гораздо наглядней следующие моменты:
- почему не выгодно автоматизировать функционал, который нужно проверить всего несколько раз;
- почему выгодно автоматизировать регрессию;
- почему тестирование API всегда более выгодно автоматизировать;
- почему очень важно иметь высокий уровень абстракции в инструменте автоматизации;
- почему так важно иметь иметь качественное логгирование результатов выполнения авто-тестов
Уменьшить время проверки можно эффективной схемой анализа результатов и дизайна авто-скриптов.
Ответы на следующие вопрос должны быть получены как можно ранее:
- К какому функционалу каждая из ошибок принадлежит?
- Какие действия выполнял скрипт в момент появления ошибки?
- В каком состоянии было приложение и какими были динамические данные в момент выполнения авто-теста?
Время на создание и апдейт авто-скриптов может быть уменьшено использованием DRY принципов и техниками уменьшения зависимостей от приложения, т.е. увеличением уровня абстракции и вынесением общего функционала в компоненты.
