Почему код без багов — неверная цель
В любой системе есть дефекты, на которые ещё никто не наткнулся, и по мере того как очевидные устраняются, стоимость поиска следующего резко растёт. С какого-то момента час, потраченный на охоту за дефектами, приносит меньше, чем тот же час, потраченный на то, чтобы сбои было дёшево обнаруживать и чинить.
Вторая проблема — культурная. Когда объявленная цель — код без багов, баг превращается в провал, который нужно объяснить, а не в информацию, на которую нужно отреагировать, и люди начинают о нём молчать.
Три цели, которые работают
Без повторов
Конкретный баг случается один раз. После каждого исправления остаётся проверка.
Достижимо — и эффект накапливается.
Найдено раньше пользователей
Перенести обнаружение из продакшена в pull request.
Измеримо: какая доля была поймана своими силами.
Дёшево чинить
Время от сбоя до исправления, которое зависит в основном от качества отчёта о сбое.
Почему первая цель важнее всего
Команда, которая ни разу не выпускает один и тот же баг дважды, становится лучше каждый месяц уже по самому устройству процесса. Для этого нужна ровно одна привычка: исправили что-то — оставьте после себя проверку. Большинство команд чинят баг, закрывают тикет и не оставляют никакого следа того, что это поведение вообще нуждалось в защите.
Что измерять
Отслеживайте долю дефектов, найденных до релиза, и время от сбоя до исправления. Обе метрики сдвигаются, когда реально что-то улучшается, и ни одну нельзя накрутить, просто написав больше тестов, — в этом их ценность. Количество тестов и процент покрытия растут по первому требованию и не говорят почти ни о чём.
Почему команды всё равно продолжают за этим гнаться
Понимание того, что цель неверная, не мешает людям в неё целиться, и причину стоит разобрать: она структурная, а не наивная.
Баги заметны, а предотвращение — нет. У дефекта, дошедшего до клиента, есть тикет, название и ответственный. У двенадцати, пойманных до релиза, нет ничего, потому что ничего не произошло. В итоге видимая история квартала — это список провалов, а естественная реакция на список провалов — потребовать, чтобы их стало меньше.
Противовес — сделать заметным и предотвращение. Показывайте, сколько дефектов поймано до релиза, рядом с тем, сколько просочилось. Первое число обычно намного больше, и когда его видно, разговор смещается с «почему у нас постоянно баги» на «меняется ли соотношение» — а это вопрос, на который есть полезный ответ.
Как это выглядит на практике
На каждый баг заводится проверка. Проверки запускаются на каждое изменение, а не перед релизом. Сбои приходят в таком виде, с которым тот, кто их чинит, может работать сразу, не восстанавливая всю картину заново.
Терминал
npm install -g @testsprite/testsprite-cli
testsprite setup
Дашборд закрывает то же самое для тех, кто не хочет ставить ничего локально, а полный набор команд лежит в репозитории CLI.
Триггер важнее механизма. Если привязать его к событию деплоя, каждое изменение будет проверяться без чьего-либо отдельного решения; GitHub App делает это из дашборда, а шаг GitHub Actions выполняет то же самое изнутри вашего workflow.
Как TestSprite поддерживает эти три цели
Ближе всего он работает на цель «без повторов». Кейс, который воспроизвёл баг, остаётся в проекте и запускается на каждое изменение, так что после исправления остаётся проверка — и никому не нужно помнить о том, чтобы её написать.
«Найдено раньше пользователей» — вопрос ритма. Покрытие генерируется из вашего продукта и запускается на pull request, а значит, обнаружение сдвигается из продакшена обратно к изменению, которое его вызвало.
«Дёшево чинить» зависит от отчёта о сбое. Прогон возвращается в виде того, что пытались сделать, что сделало приложение и где эти две вещи разошлись, — так что тот, кто чинит (всё чаще это кодинг-агент), начинает с фактов, а не с восстановления истории.
Достижим ли код без багов в принципе?
Для небольших систем с формальной спецификацией — почти, но ценой, которую почти никто не может оправдать. Для обычного продукта — нет.
Какой уровень дефектов считать разумным?
Сравнивайте с собственным трендом, а не с отраслевой цифрой. Направление важнее уровня.
Больше тестирования — меньше багов?
До определённого предела. Дальше новые тесты добавляют поддержку, но не добавляют сигнала, особенно если дублируют то, что уже покрыто.
Стоит ли отслеживать количество багов?
Отслеживайте просочившиеся дефекты и время до исправления. Сырые счётчики растут, когда улучшается сама отчётность, поэтому сигнал из них плохой.
Какая одна привычка даёт наибольший эффект?
Каждый раз, исправляя что-то, оставляйте после себя проверку. Это единственная привычка, которая накапливает эффект.
Цельтесь в отсутствие повторов, а не в ноль.
Код без багов недостижим и искажает приоритеты. Цельтесь в «без повторов», «найдено раньше пользователей» и «дёшево чинить». После каждого исправления оставляйте проверку и измеряйте просочившиеся дефекты, а не количество тестов.