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

Задача: изменить стоимость тарифа подписки.

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

Первая реакция

Она была ровно такой, какой бывает всегда. Есть дефект на проде, есть человек, отвечающий за тестирование, значит есть и причина. Мы запросили объяснение. И вот здесь история развернулась. Потому что объяснение получилось не про невнимательность.

Базы тест‑кейсов на проекте нет. Чек‑листы пишутся с нуля под каждую задачу тем, кто ее тестирует. Нигде не хранятся, не переиспользуются, не дополняются. Мы знали про эту проблему, но каждый раз откладывали ее решение, так как проект рос быстрее, чем документация, и завести базу было некогда, а потом стало привычно жить без нее.

На практике это означает вот что: покрытие сценариев каждый раз зависит от того, что конкретный человек вспомнит в конкретный день. Знание о том, какие вообще состояния бывают у подписки, не записано нигде — оно живет в головах. А головы уходят в отпуск, болеют и увольняются. У нас как раз увольнялся тестировщик, и вместе с ним уходила вся накопленная им картина сценариев. Мы потеряли ее буквально за две недели до этой задачи.

Второе, что всплыло: задача была помечена как срочная. В постановке стояло «проверить максимально быстро и сразу залить в прод». Объем проверки при этом никто не согласовывал.

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

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

И третье. Дефект нашли спустя недели — но не потому, что плохо смотрели, а потому, что смотреть было негде. Алертов на этот сценарий не было. В мониторинге фатальная ошибка терялась в общем шуме. Мы узнали о проблеме от пользователей, и то лишь тогда, когда обращения пошли массово. То есть несколько недель сервис отдавал ошибку полумиллиону человек, и внутри компании об этом не знал никто.

Так ошибка тестировщика или нет?

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

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

Четыре отсутствующих механизма. Уберите любой из этих «не было» — и дефект либо не доехал бы до прода, либо был бы пойман за часы вместо недель.

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

Что мы поменяли

1) Согласование объема проверки для срочных задач. Теперь пометка «срочно» не отменяет разговор, а запускает его. До начала работы постановщик и тестировщик договариваются, что именно проверяется, а что осознанно остается непроверенным. Если по ходу становится ясно, что даже на согласованный объем времени не хватает, тестировщик сообщает об этом до наступления срока и запрашивает приоритеты — а не решает молча.

2) Перестали откладывать в долгий ящик тест‑кейсы и наняли автотестировщика. К счастью, доказывать руководству, как раньше, зачем он нужен не пришлось. Был реальный кейс.

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

Что я из этого вынесла

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

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