Ошибки случаются. Но когда баг попадает в прод — его цена совсем не смешная.
Существует мнение, что стоимость исправления дефекта растет экспоненциально на каждом последующем этапе разработки. То есть исправить баг на этапе требований — в десятки раз дешевле, чем после релиза.
В этой статье разберемся, сколько может стоить дефект, пропущенный в релиз, и почему тестирование до релиза — это не “перестраховка”, а экономия.
Дисклеймеры:
Существует мнение, что стоимость исправления дефекта растет экспоненциально на каждом последующем этапе разработки. То есть исправить баг на этапе требований — в десятки раз дешевле, чем после релиза.
В этой статье разберемся, сколько может стоить дефект, пропущенный в релиз, и почему тестирование до релиза — это не “перестраховка”, а экономия.
Дисклеймеры:
- Считаю как астроном, очень приблизительно. В зависимости от компании/региона/сложности/людей и прочего, значения могут отличаться как в большую, так и в меньшую сторону.
- Зарплата в расчетах 200 тысяч в месяц для всех вовлеченных сотрудников, без разделения на специализацию и грейд. 20 рабочих дней в месяце и 8 часов в день, итого час работы ~1250.
Итак, представим, что вместе с релизом команда выкатила средне-тяжелый баг, система при этом не лежит, но некоторых пользователей задело. Клиенты негодуют и начинают обращаться в службу поддержки.
Эпизод 1: Саппорт в панике
Подключился сотрудник саппорта.
Хороший расклад: Потратил 4 часа.
Плохой расклад: Потратил 2 дня. Не мог воспроизвести, несколько раз обращался к пользователю.
- Попытался повторить баг. Сразу не получилось, пришлось выяснять условия
- Собрал логи
- Оценил сколько пользователей задето
- В ходе работы обратился к старшим товарищам, админам, начальнику, девопсам и аналитикам, чтобы что-то выяснить
- Завел дефект и передал его в разработку
Хороший расклад: Потратил 4 часа.
Плохой расклад: Потратил 2 дня. Не мог воспроизвести, несколько раз обращался к пользователю.
Эпизод 2: Проджект согласовывает хотфикс
Проджект увидел баг, почитал, разобрался, нашел команду, которая будет фиксить.
Баг серьезный, решили срочно исправлять и катить хотфиксом.
Хороший расклад: Потратил 2 часа.
Плохой расклад: Потратил 2 дня. Несколько смежных команд, легаси код, сложно понять, кто виноват и прочее и прочее.
Баг серьезный, решили срочно исправлять и катить хотфиксом.
Хороший расклад: Потратил 2 часа.
Плохой расклад: Потратил 2 дня. Несколько смежных команд, легаси код, сложно понять, кто виноват и прочее и прочее.
Эпизод 3: Разработчик теряет терпение
Разработчик переключился с текущей задачи и начал исправлять ошибку продакшена.
Хороший расклад: Потратил 2 часа.
Плохой расклад: Потратил день. Долго пытался воспроизвести, пришлось привлекать девопсов и админов, чтобы подготовить среду.
- Раскатил нужную версию на стенд
- Начал воспроизводить и не смог. Психанул, отдал тестировщику
Хороший расклад: Потратил 2 часа.
Плохой расклад: Потратил день. Долго пытался воспроизвести, пришлось привлекать девопсов и админов, чтобы подготовить среду.
Эпизод 4: Тестер не может воспроизвести баг
Подключается тестер.
Хороший расклад: Потратил 4 часа. Аналитик - 2 часа.
Плохой расклад: Потратил 2 дня.
Плохой расклад для аналитика: Потратил день. Требования писал не он и половина нигде не зафиксирована, пришлось разбираться.
- Попытался воспроизвести и не смог. Оказалось, на стенде стоит не та версия
- Раскатил новую
- Воспроизвел баг
- Пошел к аналитику, т.к не понял, как должна работать система в этих условиях
- Собрал логи, дописал все нужное, сделал скрины, отдал разработчику
Хороший расклад: Потратил 4 часа. Аналитик - 2 часа.
Плохой расклад: Потратил 2 дня.
Плохой расклад для аналитика: Потратил день. Требования писал не он и половина нигде не зафиксирована, пришлось разбираться.
Эпизод 5: Ремонт системы
Подключается разработчик.
Хороший расклад: Потратил 3 часа.
Плохой расклад: Потратил неделю. Привлек аналитика, архитектора, проджекта, продукт овнера, т.к если делать как должно работать, необходимо переписать половину системы. Код-ревью прошел не сразу, пришлось вносить правки в код.
- Воспроизвел баг, понял, где ошибка в коде
- Пошел к аналитику за подробностями реализации
- Внес правки в систему
- Прошел код-ревью
- Отдал тестеру
Хороший расклад: Потратил 3 часа.
Плохой расклад: Потратил неделю. Привлек аналитика, архитектора, проджекта, продукт овнера, т.к если делать как должно работать, необходимо переписать половину системы. Код-ревью прошел не сразу, пришлось вносить правки в код.
Эпизод 6: Проверка и регресс
Опять подключается тестировщик.
Хороший расклад: потратил 2 часа.
Плохой расклад: Если регресс ручной, а задето много - потратил день. Или два. Или три. Тут все зависит от системы, процента автоматизации, влияния исправлений, людей, инфраструктуры и прочее.
- Проверяет исправление
- Проводит регресс
Хороший расклад: потратил 2 часа.
Плохой расклад: Если регресс ручной, а задето много - потратил день. Или два. Или три. Тут все зависит от системы, процента автоматизации, влияния исправлений, людей, инфраструктуры и прочее.
Эпизод 7: Хотфикс в прод
Сотрудник внедрения выкатывает хот-фикс.
Хороший расклад: Потратил 1 час.
Плохой расклад: Потратил день. Деплой ручной, что-то пошло не так.
Хороший расклад: Потратил 1 час.
Плохой расклад: Потратил день. Деплой ручной, что-то пошло не так.
Конец. Пользователи больше не нервничают. Система опять работает. Ура!
Приступим к подсчетам.
В описанной ситуации исправление дефекта заняло 20 часов и стоило 25 тысяч. Исправление может происходить быстрее, когда ошибка проще и больше автоматизации. Но в среднем по больнице картина такая.
При плохом же раскладе хотфикс мог занять 120 часов или 3 недели рабочего времени. И стоить уже 150 тысяч.
Это стоимость только разработки. Без убытка из-за неработающей системы, репутационных потерь, штрафов от регулятора.
И заметьте, во время исправления было мало обратных петель. А ведь могло быть так:
Для наглядности: таблица потерь на хотфиксах в зависимости от частоты релизов, количества дефектов и длительности исправления:
При плохом же раскладе хотфикс мог занять 120 часов или 3 недели рабочего времени. И стоить уже 150 тысяч.
Это стоимость только разработки. Без убытка из-за неработающей системы, репутационных потерь, штрафов от регулятора.
И заметьте, во время исправления было мало обратных петель. А ведь могло быть так:
- Разработчик поправил - отдал тестеру
- Тестер нашел привнесенную ошибку в другой части системы, вернул
- Разработчик не знает, что с этим делать - пошел к аналитику
- Потом опять тестер. Разработчик. Аналитик. Разработчик. Тестер…
Для наглядности: таблица потерь на хотфиксах в зависимости от частоты релизов, количества дефектов и длительности исправления:
Для своей команды/компании вы можете получить более точное значение по формуле:
ДЕНЕЖНЫЕ ПОТЕРИ = ТТМ хотфикса * Количество багов в релизе * Частота релизов * Стоимость часа работы
Конечно, не каждая компания тратит по 150 миллионов в год на хотфиксы, но даже такой умозрительный эксперимент — повод задуматься: стоит ли экономить на тестировании на ранних этапах, если потом это превращается в цепочку времени, нервов и потерь?
Чтобы таких ситуаций было меньше:
Чтобы таких ситуаций было меньше:
- Внедряйте shift-left тестирование
- Развивайте автоматизацию
- Усиливайте работу с требованиями
Quality Trek помогает выстраивать процессы так, чтобы стоимость ошибок снижалась, а баги ловились ещё до релиза.
