Отдельный тест-кейс проверяет одну точку: нажали — получили. Но пользователь работает с продуктом не точками, а цепочками: открыл, создал, отредактировал, сохранил, вернулся, передумал. Многие баги живут именно на стыках таких шагов — там, куда точечные проверки не заглядывают. Инструмент для охоты на них — пользовательские сценарии.
Что такое пользовательский сценарий
Пользовательский сценарий — цепочка действий, которую человек выполняет в определённой ситуации ради конкретной цели. Например, цель «распечатать табличку на дверь»:
- Запустить текстовый редактор.
- Создать документ.
- Набрать текст «Идёт работа, не стучать!».
- Отформатировать.
- Отправить на печать.
- Сохранить документ.
- Закрыть редактор.
Каждый пункт может стать шагом кейса или целым кейсом — а вся цепочка превращается в последовательный набор проверок, который имитирует реальную работу куда лучше, чем разрозненные «точечные» кейсы.
У сценариев есть ещё два ценных свойства. Они понятны всем — сценарий можно обсуждать с аналитиком и заказчиком, в отличие от простыни из двухсот кейсов. И они вскрывают дыры в требованиях: если на каком-то шаге сценария непонятно, что должно происходить, — с требованиями явно что-то не то (мы уже встречали этот приём как «мысленную прогулку» при ревью требований).
Персонажи: кто именно пользуется продуктом
Сценарий становится сильнее, когда у него есть персонаж — обобщённый образ пользователя. Классифицируем пользователей по двум осям — квалификация и склонность к экспериментам — и дадим каждому типу имя:
| Низкая квалификация | Высокая квалификация | |
|---|---|---|
| Не склонен к экспериментам | «Осторожный» | «Консервативный» |
| Склонен к экспериментам | «Отчаянный» | «Изощрённый» |
Уже по именам легко представить разное поведение. «Осторожный» идёт строго по инструкции и пугается любого сообщения. «Консервативный» знает продукт, но использует только проверенные пути. «Отчаянный» жмёт всё подряд («Гляньте, что я придумал!») и находит комбинации, которые никто не предусматривал. «Изощрённый» знает продукт глубоко и использует его нестандартно — горячие клавиши, обходные пути, массовые операции.
Теперь один и тот же сценарий «оформить заказ» превращается в четыре разных: «Осторожный» будет трижды перепроверять корзину и нажимать «назад»; «Отчаянный» откроет два окна и оформит заказ в обоих. На составление такой таблицы уходит несколько минут, а идей она даёт больше, чем час бессистемных кликов. В предельном случае сценарии можно даже не расписывать — самого названия «"Отчаянный" оформляет заказ» опытному тестировщику достаточно.
Наборы кейсов: свободные и последовательные
Когда кейсы объединяют в сьюты, полезно понимать два способа организации:
- Свободный набор — кейсы независимы, выполняются в любом порядке. Упал один — остальные всё равно можно выполнять. Это то, к чему мы стремимся по умолчанию (вспомните свойство независимости из статьи про кейсы).
- Последовательный набор — порядок важен: результат одного кейса служит стартовым состоянием следующего. Так устроены сценарии: «создать заказ» → «оплатить заказ» → «отменить оплаченный заказ». Выигрыш — резкое сокращение шагов (не нужно в каждом кейсе заново создавать заказ) и реалистичность. Плата — хрупкость: упал первый кейс, и весь хвост выполнять бессмысленно.
Практическое правило: основной регресс держите на свободных наборах, а сценарные последовательности используйте прицельно — для сквозных путей пользователя.
Четыре вопроса перед тестированием чего угодно
Сценарии, персонажи, кейсы — всё это отвечает на вопрос «как проверять». Но начинать стоит с вопросов попроще. Перед тестированием любой функции ответьте себе на четыре вопроса:
- Что перед вами? Если не понимаете, что тестируете, — дальше будут только бездумные формальные проверки.
- Кому и зачем оно нужно? Ответ мгновенно порождает характерные сценарии использования — и подсказывает, что важно, а что нет.
- Как оно обычно используется? Это готовые идеи позитивных проверок — типичные пути типичных пользователей.
- Как оно может сломаться? А это идеи негативных проверок: где пользователь ошибётся, что введёт не так, в каком порядке нажмёт.
Ответы на третий и четвёртый вопросы удобно сразу фиксировать чек-листом — и вот у вас уже есть каркас проверок, построенный от пользователя, а не от интерфейса.
Где это применяется
Сценарии — это язык, на котором тестирование разговаривает с бизнесом. «Мы проверили 214 кейсов» ничего не говорит менеджеру; «мы проверили полный путь покупателя от поиска товара до возврата денег» — говорит всё. А внутри команды персонажи и сценарии — самый быстрый способ размножить идеи проверок: вместо «что бы ещё потестировать» вы спрашиваете «а как это сделает "Отчаянный"?».
Где спотыкаются начинающие:
- Проверяют функции по отдельности и никогда — цепочками. Все точечные кейсы зелёные, а пользователь, прошедший путь целиком, ловит баг на третьем шаге.
- Строят все наборы последовательными — ради экономии шагов. Первый же упавший кейс блокирует весь прогон.
- Пропускают вопрос «кому и зачем». Без него проверки строятся от кнопок, а не от людей — и главные сценарии остаются непроверенными.
Что учить дальше. Показательность отдельных кейсов — в статье про качество тест-кейса; систематический перебор условий внутри шага сценария — в техниках тест-дизайна и таблицах решений.