Как ошибка в коде становится убытком

Тестирование как фактор управляемости

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

По опыту Девелоники, работающей на стыке разработки и QA в крупных заказных проектах, именно тестирование позволяет сохранить управляемость продуктом — как в техническом, так и в финансовом смысле. Особенно это заметно в проектах, связанных с импортозамещением, глубокой интеграцией модулей и созданием цифровых сервисов с высоким пользовательским трафиком.

Тестирование: риски, которые можно исключить

Вместе с коллегами из Test IT, разработчики Девелоники доносят и разъясняют, почему QA — эффективный инструмент минимизации операционных рисков. Реализованные кейсы, опыт и практические задачи, решаемые после 22-го года позволили компании ГК Softline выделить три ключевые бизнес-цели, ради которых компании интегрируют зрелые практики тестирования. 

1. Снижение прямых убытков от ошибок

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

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

2. Снижение стоимости исправлений

Баг, найденный после релиза, обходится в несколько раз дороже, чем устраненный на этапе теста. Особенно в проектах с разветвленной архитектурой: ERP, CRM, ИС для госсектора. 

Так происходит, потому что подключается больше ресурсов и человеко часов, чтобы поправить бОльший объем работы. Переделка требует времени разработчиков, QA, аналитиков, DevOps. Часто приходится снова возвращаться к смежным модулям и вызвать повторную волну регрессионного тестирования.

3. Сохранение SLA, репутации и клиентской лояльности

Тестирование — это защита от сбоев, которые могут сорвать контракты, повлечь штрафы или вызвать отток пользователей. В b2b-проектах и госсекторе цена сбоя  помимо всего прочего, еще и репутационные потери. Если продукт (платформа, система, портал или приложение) будут работать некорректно, «минус» получат все и бизнес, и разработчик. 

Путь ошибки в бизнесе: так баг превращается в убыток

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

Этап 1. Возникновение

Баг формируется в момент написания кода — чаще всего из-за неформализованного ТЗ, устаревших зависимостей или срочной доработки. Проявиться он может в любой момент. Если ошибка обнаружена поздно, издержки (для крупных проектов — с 250 тысяч на инцидент и выше) складываются из времени команды, компенсаций и потенциальных SLA-штрафов.

Этап 2. Первое проявление

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

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

Этап 3. Диагностика

Следующий этап — попытка воспроизвести и локализовать баг. В проектах с большим количеством переменных и модулей это занимает 5–10 часов нескольких специалистов.

Чем позже обнаружена ошибка, тем сложнее ее воспроизвести. При отсутствии общего информационного пространства, где QA, Dev и аналитики работают в синхроне, диагностика затягивается. В таких случаях крайне важны инструменты, позволяющие централизовать работу над дефектами: платформы, которые объединяют команды и дают прозрачность по статусам, окружениям и сценариям.

Этап 4. Исправление и ретест

На исправление и ретест серьезной ошибки уходит от нескольких часов до нескольких дней, особенно если затронуты критичные функции. Даже при точной локализации баг может влиять на соседние зоны. Если нет CI/CD-процесса с автотестами и покрытием сценариев, любое исправление требует дополнительных часов проверки.

В портфеле проектов на одной из платформ, где Девелоника подключалась к QA-поддержке, время на устранение одного бага в релизной сборке доходило до трех рабочих дней. Баг, затронул фильтрацию статусов заказов и привел к нарушению SLA десятках доставок. Заказчику требовались пересборка, повторное тестирование и координация с продуктовой командой.

Этап 5. Оставленный баг

Если баг не критичен, он часто уходит в бэклог. Проблема в том, что при масштабировании эти «низкоприоритетные» баги проявляются системно: начинают влиять на скорость работы, совместимость с внешними модулями, стабильность UI.

По внутренней статистике компании, в корпоративных ИТ-системах от 10% до 20% багов, отложенных как «некритичные», могут стать причиной каскадных проблем в течение полугода после релиза. 

Контроль через процесс и инструменты

По 25-летнему опыту работы компаний бренда с рынком, совокупная стоимость одного серьезного бага, не выявленного до релиза, может составить от 250 тысяч до 1,5 млн рублей. Эти значения реалистичны для средних компаний, если учитывать затраты на устранение и косвенные издержки (штрафы, репутационные потери, отток клиентов). 

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

Контролировать эти риски можно только при наличии зрелого QA-процесса. Бизнес уходит от позиции «просто добавим тестировщика в команду», перестраиваясь на подход «какая архитектура качества мне нужна». 

На первый план выходят реальные инструменты и механики: встроенные сценарии, автоматизированное тестирование, общее рабочее пространство и прозрачные приоритеты. Особенно эффективны здесь специализированные платформы для управления тестированием, которые позволяют работать в едином окне и синхронизировать команды. Например, для управления тестированием одним из оптимальных решений с ИИ-функционалом и полным соответствием текущим стандартам рынка стала TMS Test IT.

Тестирование — обязательный этап в любой разработке

Для Девелоники, которая работает как с внедрением коробочных решений, так и с кастомной разработкой, соблюдение принципов безопасной разработки — один из признаков стабильности и надежности. 

Чем раньше выстроена система тестирования, тем выше предсказуемость результата и стабильность развития продукта. Когда команды разработки и QA работают синхронно и под единым управлением, выигрывает и только продукт, и весь бизнес-контур вокруг него. Поэтому тестирование на отечественном рынке должно восприниматься как инвестиция в управляемость и снижение потерь. Это неотъемлемая часть любого проекта, применимая в любой его стадии.