Как тестировать код, написанный под влиянием кофеина и дедлайнов? Разбор стратегий для «горящих» проектов

Всем привет, коллеги! Часто сталкиваюсь с ситуацией, когда команда пишет код на скорости света из-за горящих сроков, а потом этот код падает в прод с багами, которые можно было бы отловить на ранних этапах. Давайте обсудим, как QA-инженеру выживать и эффективно тестировать такой «кофеиновый» код, не сходя с ума. Первое, что я делаю в таких проектах — внедряю обязательные unit-тесты на критичные модули. Даже если разработчики пишут на коленке, пусть хотя бы покрывают базовые сценарии. Сама пишу на Python с pytest, и рекомендую команде, чтобы каждый новый метод имел хотя бы один тест на «счастливый путь». Пример: если функция парсит JSON, пусть будет тест с валидным и пустым словарём. Это спасает от 30% регрессий. Второй момент — сквозные сценарии в автотестах. Когда дедлайн горит, ручное регрессионное тестирование становится узким местом. Я автоматизирую end-to-end тесты на Selenium или Playwright, покрывая критический путь пользователя. Например, для интернет-магазина это: поиск товара -> добавление в корзину -> оформление заказа. Такие тесты выполняются за 10 минут вместо часа ручных проверок. Но важно не перегружать их — иначе они станут хрупкими. Третье — приоритизация багов по severity и probability. В условиях дедлайна разработчики не успевают фиксить всё подряд. Я веду баг-трекер и делю баги на три категории: блокеры (падение приложения), критические (неверные данные) и косметические (опечатки). Блокеры идут в фикс сразу, критические — по возможности, косметические — в бэклог. Пример из практики: в одном релизе была ошибка с отображением цены — это критично, так как вводит в заблуждение клиентов. Четвёртый пункт — code review с акцентом на безопасность. В «горящих» проектах часто забывают про валидацию ввода и обработку ошибок. Я прошу разработчиков добавлять хотя бы базовые проверки: не доверять данным от пользователя, экранировать спецсимволы, ловить исключения. Например, если приходит POST-запрос с полем username, проверять, что это строка, а не SQL-инъекция. Это предотвращает утечки данных. И последнее — документация тестовых сценариев. Даже если код писался на коленке, я фиксирую, какие кейсы были проверены и с какими данными. Это помогает при регрессии и при передаче проекта другому QA. Веду таблицу в Confluence с колонками: ID теста, шаги, ожидаемый результат, статус. Пример: тест на авторизацию с неверным паролем — шаги: ввести логин, пароль «wrong», нажать «Войти», ожидать сообщение «Неверные данные». А что вы делаете, когда проект горит? Используете ли TDD в таких условиях или всё на энтузиазме? Делитесь лайфхаками, особенно по автоматизации — буду рада обсудить.