Блог про менеджмент и качество| Quality Trek

Цена ошибки: сколько стоит баг, дошедший до продакшена

2025-10-20 16:37
Ошибки случаются. Но когда баг попадает в прод — его цена совсем не смешная.

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

В этой статье разберемся, сколько может стоить дефект, пропущенный в релиз, и почему тестирование до релиза — это не “перестраховка”, а экономия.

Дисклеймеры:

  • Считаю как астроном, очень приблизительно. В зависимости от компании/региона/сложности/людей и прочего, значения могут отличаться как в большую, так и в меньшую сторону.
  • Зарплата в расчетах 200 тысяч в месяц для всех вовлеченных сотрудников, без разделения на специализацию и грейд. 20 рабочих дней в месяце и 8 часов в день, итого час работы ~1250.
Итак, представим, что вместе с релизом команда выкатила средне-тяжелый баг, система при этом не лежит, но некоторых пользователей задело. Клиенты негодуют и начинают обращаться в службу поддержки.

Эпизод 1: Саппорт в панике

Подключился сотрудник саппорта.

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

Хороший расклад: Потратил 4 часа.

Плохой расклад: Потратил 2 дня. Не мог воспроизвести, несколько раз обращался к пользователю.

Эпизод 2: Проджект согласовывает хотфикс

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

Хороший расклад: Потратил 2 часа.

Плохой расклад: Потратил 2 дня. Несколько смежных команд, легаси код, сложно понять, кто виноват и прочее и прочее.

Эпизод 3: Разработчик теряет терпение

Разработчик переключился с текущей задачи и начал исправлять ошибку продакшена.

  • Раскатил нужную версию на стенд
  • Начал воспроизводить и не смог. Психанул, отдал тестировщику

Хороший расклад: Потратил 2 часа.

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

Эпизод 4: Тестер не может воспроизвести баг

Подключается тестер.

  • Попытался воспроизвести и не смог. Оказалось, на стенде стоит не та версия
  • Раскатил новую
  • Воспроизвел баг
  • Пошел к аналитику, т.к не понял, как должна работать система в этих условиях
  • Собрал логи, дописал все нужное, сделал скрины, отдал разработчику

Хороший расклад: Потратил 4 часа. Аналитик - 2 часа.

Плохой расклад: Потратил 2 дня.

Плохой расклад для аналитика: Потратил день. Требования писал не он и половина нигде не зафиксирована, пришлось разбираться.

Эпизод 5: Ремонт системы

Подключается разработчик.

  • Воспроизвел баг, понял, где ошибка в коде
  • Пошел к аналитику за подробностями реализации
  • Внес правки в систему
  • Прошел код-ревью
  • Отдал тестеру

Хороший расклад: Потратил 3 часа.

Плохой расклад: Потратил неделю. Привлек аналитика, архитектора, проджекта, продукт овнера, т.к если делать как должно работать, необходимо переписать половину системы. Код-ревью прошел не сразу, пришлось вносить правки в код.

Эпизод 6: Проверка и регресс

Опять подключается тестировщик.

  • Проверяет исправление
  • Проводит регресс

Хороший расклад: потратил 2 часа.

Плохой расклад: Если регресс ручной, а задето много - потратил день. Или два. Или три. Тут все зависит от системы, процента автоматизации, влияния исправлений, людей, инфраструктуры и прочее.

Эпизод 7: Хотфикс в прод

Сотрудник внедрения выкатывает хот-фикс.

Хороший расклад: Потратил 1 час.

Плохой расклад: Потратил день. Деплой ручной, что-то пошло не так.
Конец. Пользователи больше не нервничают. Система опять работает. Ура!
Приступим к подсчетам.
В описанной ситуации исправление дефекта заняло 20 часов и стоило 25 тысяч. Исправление может происходить быстрее, когда ошибка проще и больше автоматизации. Но в среднем по больнице картина такая.

При плохом же раскладе хотфикс мог занять 120 часов или 3 недели рабочего времени. И стоить уже 150 тысяч.

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

И заметьте, во время исправления было мало обратных петель. А ведь могло быть так:

  • Разработчик поправил - отдал тестеру
  • Тестер нашел привнесенную ошибку в другой части системы, вернул
  • Разработчик не знает, что с этим делать - пошел к аналитику
  • Потом опять тестер. Разработчик. Аналитик. Разработчик. Тестер…

Для наглядности: таблица потерь на хотфиксах в зависимости от частоты релизов, количества дефектов и длительности исправления:
Хороший расклад
Плохой расклад
Часов на хотфикс (TTM хотфикса)
20
120
Количество багов в релизе
5
20
Частота релизов
1 в месяц (12 в год)
1 в неделю (50 в год)
Часов на хотфиксы в год
1.200
120.000
Денежные потери в год
1.500.000 рублей
150.000.000 рублей
Для своей команды/компании вы можете получить более точное значение по формуле:
ДЕНЕЖНЫЕ ПОТЕРИ = ТТМ хотфикса * Количество багов в релизе * Частота релизов * Стоимость часа работы
Конечно, не каждая компания тратит по 150 миллионов в год на хотфиксы, но даже такой умозрительный эксперимент — повод задуматься: стоит ли экономить на тестировании на ранних этапах, если потом это превращается в цепочку времени, нервов и потерь?

Чтобы таких ситуаций было меньше:

  • Внедряйте shift-left тестирование
  • Развивайте автоматизацию
  • Усиливайте работу с требованиями
Quality Trek помогает выстраивать процессы так, чтобы стоимость ошибок снижалась, а баги ловились ещё до релиза.