Как выбирать тест кейсы для добавления на основе багов на проде
Что проверяют
Умеете ли вы превращать инцидент в постоянную защиту и не раздуваете ли набор проверок бездумно.
Как отвечать
Отправная точка простая: каждый дефект, дошедший до прода, это пропуск в проверках. Но добавлять тест на каждый баг подряд неправильно, набор станет неподъёмным. Нужен отбор.
По каким признакам стоит добавлять:
- влияние: затронуты деньги, данные, доступ, много пользователей. Такие сценарии закрываются автотестом обязательно;
- вероятность повторения: дефект в часто меняющемся коде вернётся, в замороженном модуле почти нет;
- класс ошибки: если баг вскрыл целое семейство (граничное значение, часовые пояса, пустой список, права доступа), добавляют проверку не на конкретный случай, а на класс;
- стоимость проверки: дешёвый модульный тест на условие добавляется сразу, дорогой сквозной сценарий только для критичного пути.
Дальше о том, где именно закрывать. Правило такое: опускать проверку на самый нижний уровень, где она ловится. Ошибка в расчёте закрывается модульным тестом, а не прогоном через интерфейс. Сквозной тест берут, когда дефект жил на стыке систем.
Хорошая практика: сначала написать падающий тест, воспроизводящий дефект, затем исправление, и убедиться, что тест позеленел. Заодно это доказывает, что причина найдена верно.
И регулярный разбор: раз в месяц смотреть на прошедшие в прод дефекты и искать закономерность. Часто выясняется, что дело не в конкретных проверках, а в процессе: нет проверки миграций, нет тестов на права, нет прогона на реалистичных данных.
Где спотыкаются
Добавляют сквозной тест на каждый баг и получают многочасовой нестабильный прогон.
Проверяют только тот самый случай из отчёта, не закрывая соседние граничные значения.
Не смотрят на дефекты в совокупности и чинят симптомы вместо процесса.