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

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

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

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

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

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

И вот здесь история развернулась. Потому что объяснение получилось не про невнимательность.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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