Тест анализ
Когда проект только стартует и требования напоминают черновик на салфетке, начинается распутывание клубка.
Первое — разбор требований. Выцепляешь несостыковки, неявные сценарии, краевые состояния. Часто то, что бизнес считает очевидным, в коде выливается в баг на проде. Пример: форма оплаты. В требованиях: «после успешной оплаты показать чек». А если оплата зависла? А если пользователь нажал «назад»? А если дважды кликнул? Всё это вытаскиваешь на этапе анализа, а не когда тестировщик уже тыкает кнопки.
Второе — модель приложения. Рисую mindmap или таблицу состояний и переходов. Главное — не перегрузить. Фиксирую сущности, их состояния и переходы. Для того же чекаут-процесса: корзина (пустая, с товаром, с применённым промокодом), этапы оформления, возможные ответы платёжки. Модель показывает, где тестов хватит, а где — слепое пятно. На старте может выглядеть как схема из трёх блоков, к середине анализа обрастает деталями.
Третье — раскладка по рискам. Далеко не все проверки одинаково полезны. Выделяю критические пути: что уронит бизнес, если сломается. Обычно это оплата, регистрация, ключевой функционал фичи. Дальше — смотрю технические риски: интеграции, миграции данных, изменения в базе. На стыке рисков и модели рождается стратегия тестирования. Не документ на двадцать страниц, а пара абзацев в Confluence или комментарий в тикете: «гоняем дымное, интеграционные с моком платёжки, приоритет — обработка ошибок».
Четвёртое — данные. Тест-аналитика упирается в тестовые данные. Нужны пользователи с определённой историей заказов, разными статусами, разными правами. Заранее описываю требования к данным: «аккаунт с пятью заказами в статусе “возврат”, карта с истекшим сроком, email без подтверждения». Без этого тест-дизайн превращается в гадание.
Пятое — готовность окружения и инструментов. Если анализ показал, что проверка должна включать логи сервера или запросы к API, сразу оговариваю доступы либо стаб. Иначе тест-кейсы лягут мёртвым грузом.
Всё перечисленное — непрерывный процесс. По мере прояснения требований и обратной связи от разработки модель уточняется. Часть гипотез отваливается, часть вылезает боком на код-ревью. Тест-аналитик здесь скорее следователь, чем писатель тест-кейсов. Итог работы: не красивая табличка, а понимание, где система сломается с наибольшей вероятностью и как это предотвратить до попадания к пользователям.
Новичкам: тренироваться на реальных задачах. Берёте любую фичу из бэклога и раскладываете по описанным шагам. Со временем скорость анализа растёт, и мозг сам начинает выхватывать мутные места.
