Свяжитесь с нами

ИТ и разработкаСколько стоит заявка

Сколько на самом деле стоит ручное тестирование в релизном цикле?

Регрессия занимает три дня из десяти. Что она стоит в деньгах и когда автоматизация окупается.

Что дал расчёт

Стоимость релиза
было412196₽ тыс−52%
Срок релизного цикла
было10,46,1раб. дней−41%
Доля ручной работы в цикле
было298%−21 п.п.

На потоке 26 релизов в год это5,6 млн ₽в год

Что за процесс и где он ломался

Релизный цикл продукта: сборка, автотесты, ручная регрессия, приёмка, выкатка. Релиз раз в две недели, ручная регрессия — три дня силами четырёх тестировщиков.

Вопрос, на который отвечали

Сколько на самом деле стоит ручное тестирование в релизном цикле?

Признаки, по которым стало понятно: дело не в людях

Автоматизацию регрессии обсуждают второй год. Аргументы обеих сторон качественные: «долго» против «дорого», цифры не звучали ни разу.

Как процесс превратили в имитационную модель

Смоделировали цикл целиком со стоимостью каждого этапа: ставки участников, время ожидания между этапами и вероятность возврата на доработку после регрессии.

Автоматизацию задали долей покрытых сценариев, от 0 до 100%, а не тумблером «есть или нет». Это и позволяет увидеть точку, после которой каждый следующий процент покрытия стоит дороже, чем экономит.

Какие данные взяли и что честно допустили

Релизы
26 в год
Ручная регрессия
3 дня × 4 человека
Возврат на доработку после регрессии
31% релизов
Автоматизация
6 месяцев работы двух инженеров (оценка команды)

Отчёт симуляции: что показал расчёт

Здесь будет живой отчёт симуляции

Расчёт по этому кейсу ещё не прогнан. После прогона сюда встанет тот же отчёт, что видит пользователь Storm: очереди, загрузка ресурсов, время цикла и стоимость одной заявки по каждому сценарию.

Какие сценарии прогнали и чем они отличались

Сценарии, прогнанные в модели
СценарийЧто меняли
Как есть БазовыйПолная ручная регрессия каждый релиз
Автоматизация 60% сценариев Ручными остаются сложные
Автоматизация 90% сценариев Ручной остаётся дымовая проверка
Релиз раз в месяц вместо двух недель Регрессий вдвое меньше

Было и стало

Сравнение «было / стало» по каждой метрике. У метрик разные единицы, поэтому каждая пара показана в своём масштабе.
  • Было
  • Стало
  1. Стоимость релиза , ₽ тыс

    412
    196−52%
  2. Срок релизного цикла , раб. дней

    10,4
    6,1−41%
  3. Доля ручной работы в цикле , %

    29
    8−21 п.п.
Ключевые метрики процесса до и после изменения
МетрикаБылоСталоИзменение
Стоимость релиза , ₽ тыс412196−52%
Срок релизного цикла , раб. дней10,46,1−41%
Доля ручной работы в цикле , %298−21 п.п.
Окупаемость автоматизации , мес9

Что показал расчёт

  1. Ручная регрессия стоит 5,4 млн в год

    Это не только ставки тестировщиков, но и стоимость задержки релиза на три дня.

  2. Автоматизация 60% окупается за 9 месяцев

    Доведение до 90% окупается за 21 — последние сценарии самые дорогие.

  3. Редкие релизы дешевле за штуку и дороже за год

    Стоимость задержки растёт быстрее экономии на регрессиях.

Что оказалось не так, как считали

Три дня регрессии стоят дороже людей, которые её проводят. Весь релиз всё это время стоит на месте, и вложенные в него деньги стоят вместе с ним.

Сколько на самом деле стоит ручное тестирование в релизном цикле?

Что решили сделать и что получилось

Автоматизацию согласовали в объёме 60% сценариев — по посчитанной точке окупаемости, а не «до победного». Долю полезного времени в цикле считали приёмом «Коэффициент касания», эффект покрытия — приёмом «Автоматизировать задачу».

Спор закрыли цифрой, а не аргументом.

Приёмы оптимизации, которые здесь сработали

Почему на этот вопрос отвечает имитационное моделирование, а совещание — нет

Стоимость процесса — это не сумма ставок. Она включает деньги, замороженные в ожидании, и именно эту часть таблица не считает никогда. Модель показывает полную стоимость заявки, включая цену задержки.

Ручное тестирование занимало 29% цикла и стоило 412 тысяч на релиз; после автоматизации 196 тысяч с окупаемостью за 9 месяцев.

Где этот вывод не работает

Оценка трудоёмкости автоматизации дана командой и может оказаться заниженной. При удвоении срока разработки окупаемость сдвигается до 18 месяцев.

Частые вопросы по этому расчёту

Почему не автоматизировать всё?

Потому что последние 30% сценариев дороже остальных семидесяти вместе взятых, а экономят они меньше.

Три дня регрессии стоили 5,4 млн в год — как это считается?

Это не только ставки четырёх тестировщиков на три дня: это стоимость задержки 26 релизов в год на 3 дня каждый. Пока релиз стоит, разработчики не выпускают следующую фичу, PR зависит от даты. Модель считает весь замороженный капитал.

Если команда волнуется, что 60% автоматизации недостаточно?

При 60% окупаемость 9 месяцев — выгодно. При 90% окупаемость 21 месяц: последний 30% требует вдвое больше кода и экономит вдвое меньше. Дойти до 60%, выпустить в боевую, потом пересмотреть нужна ли 90%.

Если релизы начнут выходить раз в неделю вместо двух?

Регрессий вдвое больше, стоимость ручной регрессии удвоится примерно до 10,8 млн. Экономия от автоматизации вырастет, и окупаемость 60% сдвинется вперёд — первые 60% окупятся за 4–5 месяцев вместо 9, потому что срок цикла упадёт с 10,4 до 6,1 раб. дня.

Ваш процесс, ваши числа

Покажем на вашем процессе

Пришлите диаграмму и то, что знаете про поток: сколько заявок в день, сколько людей, сколько занимает операция. Соберём модель, прогоним сценарии, которые вы назовёте, и разберём отчёт вместе — с очередями, загрузкой ресурсов, сроком и стоимостью заявки.

  1. Присылаете диаграмму и три-четыре цифры про поток
  2. Собираем модель и прогоняем сценарии, которые вы назовёте
  3. Разбираем отчёт вместе и обсуждаем, что из него следует

Первый процесс считаем бесплатно: нужна диаграмма и несколько цифр по потоку.

Поддержка