Когда тестов нет вовсе, соблазн начать с главного экрана: он на виду и его легко проверить. Это ошибка порядка, а не усилий.
Начинайте с того, что стоит денег
Первые тесты пишутся на пути, где ошибка стоит денег: оплата, пополнение, выплата, возврат. Не «самые важные функции», а самые дорогие поломки. Всё остальное можно починить в понедельник, неработающую оплату — нельзя.
Дальше вход и главный сценарий продукта: заказ оформлен, смена закрыта, работа сдана — то, что оплачивает ваши счета.
Потом — то, как это ломается
Счастливый путь никогда не был риском. По-настоящему полезная часть сьюта — негативные ветки:
- отклонённая карта и зависший терминал;
- токен, протухший посреди работы;
- двойное нажатие на плохой связи;
- уведомление от провайдера, пришедшее дважды;
- заблокированный аккаунт с активным оплаченным заказом.
В нашем маркетплейсе три сьюта из двадцати четырёх состоят только из негативных случаев, и это не перестраховка: именно там живут обращения в поддержку, которые дороже всего разбирать вручную.
Что не стоит автоматизировать в начале
- Экраны, которые вы собираетесь переделать в этом квартале.
- Внешний вид. Для этого есть другие инструменты, и они окупаются позже.
- Всё подряд ради процента покрытия. Это число, которым удобно отчитываться и невозможно пользоваться.
- Редкие административные сценарии, которые быстрее проверить руками раз в квартал.
Пятнадцать путей: как выглядит список
Абстракция «критичные пути» становится понятной, когда её пишут словами. Вот
типичный список для продукта с деньгами внутри — примерно то, с чего мы
начинаем сами.
1. Регистрация и вход, включая забытый пароль
2. Вход с истёкшей сессией — пользователь возвращается через неделю
3. Главный сценарий целиком: от первого экрана до результата
4. Оплата успешная
5. Оплата отклонённая банком
6. Оплата, которую пользователь бросил на середине
7. Уведомление от провайдера, пришедшее дважды
8. Уведомление, пришедшее с опозданием в час
9. Возврат полный
10. Возврат частичный
11. Отмена заказа каждой из сторон
12. Доступ: чужой пользователь пытается открыть не свой заказ
13. Роль без прав пытается сделать действие администратора
14. Ключевой отчёт, который открывают руководители
15. Экспорт данных, на который все полагаются и о котором никто не помнит
Обратите внимание: из пятнадцати пунктов только два про счастливый путь.
Остальные — про то, как всё ломается, и именно они окупают сьют.
Чем измерить результат через месяц
Покрытие в процентах тут ничего не говорит. Полезнее три вопроса:
Стало ли меньше выкатов с откатом? Это то, ради чего всё делалось.
Если релиз по-прежнему страшно выпускать в пятницу, сьют покрывает не то.
Узнаёте ли вы о поломке раньше клиента? Единственный по-настоящему важный
показатель. Он же самый простой: посчитайте, сколько обращений в поддержку
за месяц было про то, что уже сломано.
Верит ли команда красному тесту? Если на красный смотрят и перезапускают —
доверия нет, и сьют надо чинить, а не расширять.
Признак хорошего первого набора
Двенадцать–пятнадцать тестов, каждый назван по пути, который защищает, каждый создаёт свои данные и может выполняться в любом порядке. Красный тест даёт видео и трассировку, а не строчку «упало».
И главное: команда начинает выкатывать по пятницам. Это и есть измеримый результат, ради которого всё затевалось.
Мы делаем такой набор за две недели и от 150 000 ₽, с фиксированным списком путей, согласованным до начала. Если хотите сначала понять, что у вас не покрыто, — расскажите, что ломалось в последние полгода: список сценариев обычно пишется сам собой.
На ту же тему, с другой стороны: сколько стоит автоматизация тестирования и что за эти деньги получаешь.