← назад к разделу

«Выложили на стенд оплату частями, посмотрите». Требований нет — переписка с аналитиком и два макета в задаче. Тест-кейсов тоже нет, и написать их не из чего. До показа заказчику полтора дня.

Один будет час нажимать всё подряд и напишет «вроде работает». Другой за сорок минут найдёт три места, где сумма к оплате расходится с ценой в карточке. Дело не в стаже: у второго была рамка — цель, срок и записанная заранее договорённость о том, что считать находкой. Это и есть исследовательское тестирование: проверки придумывают на ходу, но не наугад.

один и тот же экран, два маршрута по нему по кейсу: маршрут написан заранее корзина промокод сумма оплата ✓ ✓ ✓ ✓ 4 из 4 ✓ нашли ровно то, что было записано сессия: маршрут ветвится от замеченного корзина промокод дальше по списку сессия туда не пошла ✓ ✓ !сумма мигнула ввёл код дважды добавил бонусы ✗ к оплате 0 ₽в списке не было прямая линия закрывает список; ветка выходит за его пределы

Кейс ведёт прямой линией: что записано, то и проверено, отчёт сходится. Сессия идёт тем же путём ровно до первой странности — и сворачивает туда, где списка нет. Цена поворота: часть маршрута остаётся непройденной, и это тоже попадает в отчёт.

Три степени формализации: по кейсу, исследуя, наугадспросят на собеседовании

«Проверь новую функцию» делают тремя способами, и различает их одно — откуда взялся список проверок. Это и есть степень формализации.

По кейсу. Шаги тест-кейсов описаны заранее: ничего не забудется, прогон повторит любой в команде. Плата большая: кейс проверяет ровно то, что в нём написано, а баг в шаге в сторону остаётся незамеченным.

Исследовательское. Список рождается по ходу, шаг подсказан предыдущим: имя обрезалось на экране заказа → а в письме покупателю тоже? → а поиск по такому имени находит заказ?

Наугад. Ни цели, ни списка, ни заметок — десять минут «свежим взглядом» по свежей сборке. Разведка, а не метод.

Путают второе с третьим, а разница видна до первого нажатия: у сессии есть цель, срок и след.

Устав сессии: цель, срок и что считать находкойспросят на собеседовании

Рамки записывают заранее, тремя-четырьмя строками; такая запись называется уставом сессии (в англоязычных материалах — charter, чартер).

Что исследуем: применение промокода в корзине — сочетания скидок,
               истёкшие и чужие коды, повторный ввод.
Сколько:       40 минут, тестовый стенд, сборка 217, Chrome.
Находка:       расхождение суммы с карточкой товара; изменение суммы
               без действия покупателя; непонятная ошибка.
Не трогаю:     доставку и оплату картой — это отдельная сессия.

Широкая цель («оплата») превращает сессию в блуждание, узкая («кнопка „Применить“») не даёт ветвиться. Срок — 40-90 минут: меньше — не разогнаться, больше — внимание садится. Без строки «находка» вы полчаса спорите сами с собой, баг это или так задумано. «Не трогаю» держит от расползания.

Заметки на ходу: чтобы баг потом воспроизвёлся

Самая обидная потеря — находка, которую не получилось повторить. Дело не в памяти: в кейсе состояние на каждом шаге известно заранее, а в сессии вы двадцать минут его накапливали. Лечится привычкой писать строку до нажатия.

14:02 корзина, кофемолка 3400, код LETO25 → 2550, верно 14:05 тот же код второй раз → 1912: скидка легла дважды 14:07 повтор с пустой корзины: 3400 → 2550 → 1912, воспроизводится 14:09 третий ввод → 1434: ограничения на число применений нет

Заметка по ходу: время, что сделал, что увидел. По такой записи ошибку повторит другой человек — а «скидка применяется дважды» без шагов повторит только автор.

Из этих четырёх строк баг-репорт собирается за минуту. Строка 14:07 — повтор с чистого состояния; делать его надо сразу: он превращает «я что-то видел» в находку.

Задним числом не восстановить две вещи. Данные — не «товар», а «Кофемолка, 3400, код LETO25»: половина невоспроизводимых багов держится на конкретном значении. Время до минуты — по нему разработчик найдёт запрос в журнале сервера.

Откуда брать идеи и в каком порядке их применять

«Исследуй продукт» для новичка звучит как «придумай сам». Спасают заготовки — типовые ходы почти под любой экран.

  • Границы — ноль, единица, максимум, максимум плюс один: пустая корзина, 99 товаров при лимите 99, сумма на копейку ниже порога бесплатной доставки (техники тест-дизайна).
  • Повтор — кнопка дважды, код второй раз: разработчик думал про один вызов, второй даёт дубль — два заказа, две скидки, два письма.
  • Отмена на середине — уйти с полузаполненной формы, закрыть вкладку на оплате: остаётся зависшая бронь или списанный, но не зачисленный бонус.
  • Чужие данные — чужой номер заказа в адресе страницы: не ошибка на экране, а показанные посторонние данные.

Дальше идут «назад» и две вкладки (страница из кеша со старой суммой), замедление и обрыв сети в DevTools и время вокруг сроков — бронь на 15 минут, операция в 23:59. Всё вместе это предугадывание ошибок (error guessing): копилка набирается быстро, если после каждой находки спрашивать, где ещё может быть та же ошибка.

Порядок держат простой: простые позитивные проверки, потом простые негативные (пустое поле, заведомо неверные данные), дальше сложные позитивные (два промокода, частичный возврат) и только в конце сложные негативные. Начнёте с экзотики — получите продукт, который переносит хитрые атаки и ломается в элементарном случае. Главный путь заодно служит картой: странность видна на фоне обычного.

Что остаётся после сессии

Разбор заметок — последние четыре минуты из тех же сорока. В примере выше вопрос «где ещё та же ошибка?» привёл к бонусам: код плюс бонусы дали «0 ₽» к оплате, и заказ оформился. Из сессии выходят четыре вещи:

  • находки — баги в трекере, первым тот, что про деньги;
  • покрытие — «промокоды прошёл, доставку и оплату картой не трогал»; вторая половина фразы важнее первой;
  • идеи в кейсы — всё, что воспроизводится стабильно;
  • вопросы к требованиям — «код в нижнем регистре не принимается, так задумано?».

Сколько ушло на проверки и сколько на оформление, добавляют, если в команде считают метрики.

Где это применяется

В спринте порядок такой: задача приехала на стенд → сессия на 40-60 минут → находки в трекер → стабильные проверки оформлены в кейсы → кейсы ушли в регресс, а сессии ищут то, чего в регрессе нет.

Больше всего сессия даёт там, где кейсов ещё нет или от них уже нет толку: новая функция без требований, большая переделка (кейсы проверяют описанное, сессия ловит задетое боком), зелёные прогоны при живых жалобах. И не годится там, где нужны повторяемость и доказуемость: регресс обязан быть одинаковым от версии к версии (кейсы и регресс), двадцать однообразных сочетаний тарифа — работа для таблицы решений, а дежурную проверку после выката повторяет другой человек, значит нужен чек-лист.

Где спотыкаются начинающие:

  • Уходят в первую же нору. Странность на пятой минуте расследуют сорок минут, а цель сессии остаётся нетронутой.
  • Не повторяют находку сразу. Через двадцать минут состояние не восстановить, находка превращается в «мне показалось».
  • Начинают с экзотики. Полчаса на эмодзи в поле имени, а обычное сохранение формы ни разу не проходили целиком.
  • Идут в незнакомую область без подготовки. Ветвиться не от чего: сначала требования или полчаса с аналитиком.

Коротко

  • Степень формализации — про то, откуда взялся список проверок: написан заранее (кейсы), рождается по ходу (исследование) или его нет вовсе (наугад).
  • Устав пишут до начала: цель, срок 40-90 минут, что считать находкой и что не трогаем.
  • Заметку пишут до нажатия: время, данные, действие, результат — из четырёх таких строк баг-репорт собирается за минуту.
  • Заметили странность — сразу пройдите к ней с чистого состояния: повтор отделяет находку от впечатления.
  • Идеи дают заготовки: границы, повтор, отмена на середине, чужие данные, «назад» и два окна, обрыв сети, время. Порядок — от простых позитивных проверок к сложным негативным.
  • Сессия не заменяет кейсы там, где нужны повторяемость и доказуемость: регресс, приёмка, дежурные проверки, однообразные сочетания.
  • Заканчивается сессия разбором заметок: находки, покрытие (в том числе куда не дошли), идеи в кейсы, вопросы к требованиям.

Что почитать дальше