Ключевые выводы

Нужно тестировать пропорционально стоимости отказа, а не объёму кода. Строка в расчёте налога и всплывающая подсказка в админке — разный риск. Одинаковое внимание к обоим — расточительство или халатность.

«Больше тестов» без модели риска раздувает стоимость без снижения самых дорогих отказов. Зелёный конвейер с тысячей хрупких проверок может спокойно пропускать сценарий, который съедает маржу или ломает регуляторный отчёт.

Полная стоимость фичи шире спринта. Разработка + проверка + сопровождение + цена сбоя. Если четвёртый член огромный, «ускорить» за счёт проверки — ложная экономия.

Раннее обнаружение дёшево относительно позднего, но не бесконечно. Есть точка, после которой дополнительные проверки почти не снижают остаточный риск и начинают тормозить обучение продукта.

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

Полная стоимость фичи

Инженеры привыкли считать стоимость фичи как «сколько займёт реализация». Это бухгалтерский учёт только капитальных затрат на строительство. В реальности есть четыре слоя.

Первый слой — создание: анализ, проектирование, код, ревью, согласование контрактов. Его все видят в доске задач.

Второй — проверка: ручные сценарии, автотесты, стенды, проверка данных, прогон на «почти проде». Его часто режут первыми, потому что он не даёт видимой «фичи» в интерфейсе.

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

Четвёртый — цена отказа: сколько стоит, если поведение в проде окажется неверным. Сюда входят прямой ущерб (деньги, простой, штрафы), косвенный (нагрузка на поддержку, репутация, отток) и организационный (заморозка релизов, «геройские» ночные правки, потеря фокуса команды).

Именно четвёртый слой делает дешёвое тестирование дорогим. Если цена отказа низкая — можно сознательно принять риск и выпустить раньше. Если цена отказа высокая — «сэкономить» на проверке значит перенести стоимость в будущее с процентами.

Пример. Команда добавляет скидку на тарифе. Разработка — два дня. Автотесты на happy path — полдня. В проде забывают край: скидка применяется дважды при повторном списании. Прямой ущерб за выходные — десятки тысяч. Разбор, компенсации, постмортем — ещё несколько дней ключевых людей. Полная стоимость «простой фичи» оказывается на порядок выше сметы в тикете.

Тот же объём кода в другом месте — смена подписи в письме. Цена отказа почти нулевая. Здесь тяжёлая матрица сценариев — налог на скорость без страховки.

Связь с архитектурой прямая: чем больше связность и чем ближе код к деньгам, правам и необратимым действиям, тем выше цена отказа. Поэтому качество нельзя «натянуть» одинаковой политикой покрытия на весь репозиторий. Это как страховать гараж и ядерный реактор одним полисом.

Почему «больше тестов» — ложный ответ

Культ покрытия родился из правильного наблюдения: без автоматической страховки рефакторинг страшен, а регрессии дорогие. Из наблюдения сделали догму: больше красных/зелёных точек — лучше продукт.

Догма ломается в трёх местах.

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

Второе — смещение внимания. Команда оптимизирует то, что измеряют. Если ключевой показатель — процент покрытия, люди пишут тесты на геттеры, чистые функции и внутренности, которые завтра перепишут. Дорогие интеграционные сценарии остаются «на потом», потому что они медленные и неудобные в отчёте.

Третье — стоимость владения тестами. Каждый тест — тоже код: его чинят при смене API, при флаках, при обновлении стенда. Дешёвый в написании тест может быть дорогим в жизни. Особенно если его сгенерировала модель под текущую реализацию, а не под намерение продукта.

Поэтому вопрос не «сколько тестов у нас?», а «какие отказы мы сознательно страхуем, а какие принимаем?». Это язык риска, знакомый тем, кто уже думал о цене ошибки в маршрутизации моделей или о границах изменений в легаси с ИИ.

Анти‑паттерн «сначала добьём покрытие, риски потом» родственен «сначала выкатим, политики потом». Пока система маленькая, это выглядит как скорость. Когда появляется продуктовый объём, вы платите не за отсутствие тестов вообще, а за отсутствие тестов там, где отказ дорог.

Стоимость обнаружения и стоимость отказа

Классическая модель «баг на этапе требований дешевле бага в проде» полезна как направление, вредна как религия с фиксированными множителями. Цифры в презентациях из 1990‑х не являются законом для вашего продукта. Но логика слоёв остаётся.

Чем позже найден дефект, тем больше уже «налипло» вокруг него: зависимый код, данные, привычки пользователей, обещания продажам, кэш, интеграции. Исправление в проде часто включает не только патч, но и миграцию, коммуникацию и проверку, что компенсация не создала новый дефект.

Отсюда практическое следствие: инвестируйте в раннее обнаружение там, где поздний отказ дорог. Не «везде сдвиньте влево на максимум». Слева тоже есть стоимость: стенды, данные, люди, время до обратной связи от рынка.

Полезнее держать две оси:

Высокая цена × высокая неопределённость — зона максимальной страховки. Низкая цена × низкая неопределённость — зона осознанного риска.

Стоимость обнаружения падает, когда у вас хорошие швы, контракты и воспроизводимые данные. Поэтому «дешёвое тестирование» иногда означает не «мало тестов», а «дорого тестировать из‑за архитектуры»: монолит без границ, скрытое состояние, окружения, которые нельзя поднять за час. Тогда правильный рычаг — не ещё один сквозной прогон на ночь, а шов, который делает проверку дешевле. Здесь пересечение с идеями читаемости под изменения из разбора Clean Code и с дисциплиной работы без страховки из книг про легаси в подборке.

Не все баги одинаково дороги

Это центральный тезис статьи, и его стоит проговорить без эвфемизмов.

Баг в подсказке интерфейса и баг в начислении бонусов — оба «баги». Их экономическая природа разная. Первый тратит нервы и тикет в поддержку. Второй может тратить деньги клиентов и юридический риск.

Если команда распределяет тестовое внимание пропорционально объёму изменённых строк, она оптимизирует удобство отчёта, а не устойчивость бизнеса. Риск живёт не в диффе как тексте, а в последствиях неверного поведения.

Практический перевод:

• Смотрите на необратимость: деньги, удаление, публикация вовне, смена прав, юридически значимое действие.
• Смотрите на blast radius: один пользователь или все арендаторы; один регион или весь контур.
• Смотрите на обнаруживаемость: упадёт ли сразу мониторинг, или тихий дрейф данных месяцами.
• Смотрите на стоимость отката: можно ли выключить флагом, или нужна миграция назад по грязным данным.

Из этого следует правило распределения усилий: тестируйте риск, а не код. Код — носитель. Риск — объект управления.

Как это выглядит в спринте. Изменение в модуле оплаты: контрактные тесты на расчёт, сценарии идемпотентности, проверка округления, канарейка, дашборд аномалий суммы. Изменение в тексте кнопки: визуальная проверка и быстрый просмотр — достаточно. Одинаковые критерии готовности «юнит + сквозной» для обоих случаев — либо паранойя, либо ритуал.

Risk-based testing давно описан в литературе по качеству. В инженерной практике 2026 года к нему добавляется новый шум: ИИ предлагает «покрыть всё», потому что генерация дешёвая. Дешёвая генерация без ранжирования по цене отказа просто ускоряет производство ложной уверенности.

Убывающая отдача проверок

Даже на критичном контуре действует закон убывающей отдачи. Первые проверки снимают самые вероятные и дорогие классы ошибок. Следующие ловят более редкие комбинации. В какой‑то момент стоимость ещё одного сценария превышает ожидаемое снижение ущерба.

Это не оправдание лени. Это призыв считать предельную пользу. Если вы уже страхуете расчёт, права и идемпотентность платежа, двадцатый вариативный сквозной сценарий на редко используемый промокод может стоить дороже, чем оставить его под ручную дымовую проверку и хороший алерт.

Признаки, что вы зашли за точку окупаемости:

• Тесты падают чаще из‑за стенда и данных, чем из‑за реальных регрессий.
• Время обратной связи конвейера измеряется часами, а команда обходит его локальными пропусками.
• Новые кейсы копируют старые с микроизменениями и не добавляют нового класса риска.
• «Красный» статус перестаёт быть сигналом и становится фоном.

Отдельная статья кластера разберёт убывающую отдачу подробнее (план: diminishing-returns-testing-2026). Здесь достаточно принципа: цель — снизить ожидаемый ущерб, а не максимизировать число проверок. Когда предельная проверка почти не двигает ущерб, лучше вложить час в наблюдаемость, фичефлаг или упрощение дизайна.

Упрощение дизайна часто недооценено как «тест». Меньше ветвлений, меньше скрытых состояний, меньше способов сделать необратимое действие «случайно» — это снижение цены отказа и снижение стоимости проверки одновременно.

Скорость и надёжность как одна экономика

Спор «быстрее или надёжнее» часто ставят как культуру: стартап против энтерпрайза. Экономически это один и тот же баланс при разной цене отказа и разной цене задержки выхода на рынок.

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

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

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

Второй спутник кластера как раз про цену бага и этот баланс (план: bug-cost-speed-vs-reliability-2026). В опорной статье важно зафиксировать: баланс выбирают через цену отказа и цену задержки, а не через лозунги.

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

Как распределить усилия на практике

Ниже — рабочий каркас, который можно внедрить без новой «методологии на год».

1. Классифицируйте изменения по цене отказа

На уровне PR или тикета достаточно грубой шкалы: низкая / средняя / высокая / критическая. Критерии заранее: деньги, права, данные, необратимость, blast radius. Не спорьте о вкусе — спорьте о последствиях.

2. Выберите уровень страховки под класс

Пример политики (калибруйте под себя):

Политика должна быть короткой. Если её нельзя применить за минуту к тикету, ею не будут пользоваться.

3. Отделяйте тесты намерения от тестов реализации

Тест намерения ломается, когда меняется обещание продукта. Тест реализации ломается, когда меняется внутренность. Вторые дёшевы в генерации и дороги в сопровождении. Первые — то, что стоит писать руками (или тщательно править после модели) на дорогих рисках.

4. Считайте стоимость владения автотестами

Раз в квартал спросите: какие тесты чаще всего краснеют без пользы? Какие никогда не ловили реальный дефект? Что мешает быстрой обратной связи? Удаление мёртвого теста — тоже инвестиция в качество сигнала.

5. Используйте ИИ как ускоритель черновиков, не как владельца риска

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

6. Делайте проверку дешевле архитектурой

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

Матрица «риск × неопределённость» на одной странице

На стену команды достаточно простой матрицы 2×2:

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

Пересматривайте классы после инцидентов. Постмортем без переоценки цены отказа — театр.

Что сделать на этой неделе

Не внедряйте «новую культуру качества» с нуля. Сделайте четыре конкретных шага.

1. Возьмите последние три инцидента в проде. Для каждого оцените: цена отказа, где дефект мог быть пойман дешевле, какая проверка отсутствовала не «вообще», а именно здесь.
2. Введите в шаблон PR одно поле: «класс цены отказа» и одно: «как откатим». Без эссе — одна строка.
3. Выберите один критичный поток (оплата, права, импорт данных). Список из пяти инвариантов, которые нельзя сломать. Повесьте на них контрактные или интеграционные проверки, если их ещё нет.
4. Удалите или отключите один шумный автотест, который не защищает инвариант. Освободите сигнал.

Если после этого захочется «поднять покрытие на 10%» — сначала спросите, какой ожидаемый ущерб это снижает. Если ответа нет, это не инвестиция, а отчётность.

FAQ

Дальнейшее чтение

• Шлюз LLM и FinOps — параллель: цена ошибки задаёт, где нужна «дорогая» модель и жёсткий контроль.
• Чистый код: выжимка — тесты как страховка поведения, которое дорого потерять.
• Лучшие книги по программированию — в том числе легаси, рефакторинг и надёжность релизов.
• Легаси 15 лет и ИИ — как менять систему, когда страховки мало, а цена ошибки высока.
• Наблюдаемость ИИ‑систем — слой после релиза: увидеть деградацию раньше, чем её увидит клиент.

Экономика качества — не призыв тестировать меньше из лени и не призыв тестировать больше из страха. Это призыв платить страховку там, где пожар дорог, и не тратить спринт на полис для спичечного коробка. Когда следующий раз услышите «нам нужно больше тестов», переспросите: больше — относительно какой цены отказа?