Ответ
При сокращении сроков необходимо сфокусироваться на максимальном снижении рисков для бизнеса, используя подход, основанный на оценке рисков (Risk-Based Testing).
План действий:
- Срочный анализ и приоритизация:
- Совместно с продукт-менеджером и разработчиками выделить критические user flows и бизнес-критические функции (например, оформление платежа, основная логика продукта).
- Определить зоны высокого риска: новые компоненты, изменения в сложной логике, интеграции.
- Пересмотр тестового покрытия:
- Обязательно: Выполнить Smoke и Sanity тестирование для проверки работоспособности основных функций после сборки.
- В первую очередь: Протестировать сценарии из зон высокого риска.
- Во вторую очередь: Основные позитивные сценарии (Happy Path) для остальных функций.
- Можно отложить: Углубленное негативное тестирование, тестирование неосновных функций, кросс-браузерное/кросс-платформенное тестирование (если не критично).
- Оптимизация процесса:
- Использовать чек-листы вместо детальных тест-кейсов для скорости.
- Запустить имеющиеся автоматизированные регрессионные тесты для быстрой проверки стабильности.
- Параллельное тестирование: Распределить проверки между членами команды.
- Усилить коммуникацию: Короткие ежедневные стендапы для оперативного выявления блокеров.
Пример приоритизации для интернет-магазина:
# Критический (High Risk) - Делаем в первую очередь
Сценарий: Успешное оформление заказа с оплатой картой.
# Важный (Medium Risk) - Делаем во вторую очередь
Сценарий: Добавление товара в корзину.
# Низкий приоритет (Low Risk) - Делаем, если осталось время
Сценарий: Фильтрация товаров по цвету.- Фокус на качестве баг-репортов:
- Баги должны описываться четко, с однозначными шагами воспроизведения, чтобы разработчик мог быстро их понять и исправить.
- Критические баги эскалируются немедленно.
Итог: В условиях цейтнота цель — не «протестировать всё», а предотвратить выход критических дефектов в продакшен, сконцентрировав усилия на самых важных с точки зрения бизнеса и пользователя областях.
Ответ 18+ 🔞
А, ну вот, опять сроки поехали, как говно с горки! «Срочно, вчера, горит!» — а тестировать-то когда, в перерыве между вдохом и выдохом? Ладно, слушай сюда, раз уж так, действовать надо по-хитрому, как жулик на базаре.
Первым делом — включаем режим «паника, но контролируемая». Забываем про «протестируем всё красиво и глубоко». Это уже нереально, как мои шансы стать балериной. Теперь наш девиз: не уронить самое ценное в тазик.
Что делаем, пока все носятся как угорелые:
-
Хватаем за жабры продакта и ключевых разрабов. Садимся (виртуально) и орем: «Братья! Что тут у нас самое-самое? Без чего пользователь просто обоссётся от злости и уйдёт нахуй?». Выписываем это. Оформление заказа? Авторизация? Приём платежа? Вот на этом и концентрируемся. Всё остальное — фон, шум, пыль.
-
Режем покрытие, не стесняясь. По плану:
- Обязаловка:
SmokeиSanity. Собрали сборку — быстренько пробежались, дышит ли она вообще. Не дышит — всё, пиздец, дальше можно не продолжать. - Первая линия атаки: Лезем сразу в зоны высокого риска. Новый платёжный шлюз? Переписанная корзина? Вот тут копаем, как кроты, ищем косяки.
- Вторая очередь: Проверяем основные счастливые пути (
Happy Path) для остального. Работает — и ладно, слава богу. - Что смело откладываем в долгий ящик: Глубокое негативное тестирование («а что если ввести номер карты буквами?»), проверку второстепенных фич (смена аватара в личном кабинете), кросс-браузерную/девайсную вакханалию (если, конечно, это не главная боль проекта).
- Обязаловка:
-
Оптимизируем процесс, чтоб аж свистело.
- Чек-листы — наше всё. Забываем про толстенные тест-кейсы. Берём список из пункта 1 и тупо ставим галочки: проверил — не проверил.
- Автомат — в бой. Если есть хоть какая-то автоматизация регресса — запускаем её немедленно. Пусть машина пашет, она не устаёт.
- Делимся. Не надо, чтобы один человек всё тестировал. Раскидываем зоны ответственности и работаем параллельно.
- Общаемся чаще. Короткие стендапы утром и вечером. «Я нашел жопу в платежах», «У меня всё ок». Чтобы не получилось, что три дня искали баг, а он уже известен и пофикшен.
Вот, смотри, как это выглядит на примере магазина:
# Критично (High Risk) - Делаем ПРЯМО СЕЙЧАС, блядь!
Сценарий: Успешное оформление заказа с оплатой картой.
# Важно (Medium Risk) - Делаем, когда с критичным управились
Сценарий: Добавление товара в корзину.
# По приколу (Low Risk) - Делаем, если все уже пофиксили и есть полчаса до дедлайна
Сценарий: Фильтрация товаров по цвету.- Пишем баги так, чтоб разраб аж прослезился. Никакой воды. Чёткие шаги: «Зашёл туда, нажал то, ввёл это — получил вот эту хуйню». Скриншоты, логи, запросы. Критичный баг? Сразу орем в общий чат и лепим метку
BLOCKER. Время — деньги, а у нас их нет.
Итог, блядь: Наша задача в аврале — не найти все баги, а не пропустить в прод те, от которых бизнес накроется медным тазом. Фокусируемся на главном, отсекаем всё лишнее и работаем как швейцарские часы, только очень-очень быстрые. Всем пиздец, но контролируемый!