Как составить чартер одной сессии в исследовательском тестировании

Чартер исследовательской сессии нужен не для отчётности, а чтобы одна проверка не распалась на случайные клики. Хороший чартер отвечает на узкий вопрос: что именно я хочу узнать за эту сессию, где остановлюсь и как зафиксирую результат. Если вместо этого написать общий список вроде «проверить форму», сессия быстро уходит в сторону: часть времени тратится на очевидные сценарии, а рискованные места остаются без внимания.

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

Что должен решить чартер до начала сессии

В исследовательском тестировании вы не просто выполняете шаги, а одновременно проверяете продукт, учитесь на наблюдениях и меняете следующий ход в зависимости от того, что нашли. Поэтому чартер не должен быть длинной инструкцией. Его задача другая: задать рамку, внутри которой у вас остаётся свобода выбора. Иначе получится одна из двух крайностей: либо хаотичный просмотр экрана, либо обычный тест-кейс под другим названием.

Минимально рабочий чартер отвечает на три вопроса. Первый: какая у сессии цель. Второй: что входит и не входит в эту проверку. Третий: какой результат я обязан вынести, даже если багов не нашёл. Такой результат может быть разным: список наблюдений, один подтверждённый дефект, вопрос к требованиям, набор сценариев для следующей сессии.

Удобно держать чартер коротким. На практике хватает одной таблицы:

Как сформулировать цель сессии

Самая частая ошибка — писать цель слишком широко. Формулировка «исследовать авторизацию» годится для половины дня, но не для одной сессии. Лучше сузить объект, риск и ожидаемое поведение. Например: «Понять, как форма восстановления пароля обрабатывает валидные, пограничные и неожиданные адреса электронной почты, и не теряет ли пользователь понятную обратную связь». Здесь уже ясно, где искать проблемы: валидация, сообщения, состояние формы после отправки.

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

• Слишком размыто: проверить форму восстановления пароля.
• Рабочая формулировка: проверить, как форма восстановления пароля обрабатывает разные email и что видит пользователь при успехе, ошибке и повторной отправке.

Если вы не можете объяснить цель в одном-двух предложениях, значит, сессия ещё не нарезана. Лучше сделать два коротких чартера подряд, чем один большой, в котором невозможно понять, что именно было исследовано.

Как задать границы и подготовить данные

Границы экономят время сильнее, чем кажется. До старта решите, в каком окружении тестируете, какой браузер или устройство берёте, какая роль пользователя нужна и что сознательно оставляете за пределами сессии. Например, можно проверить форму восстановления только для неавторизованного пользователя в десктопном Chrome и не трогать письма, которые приходят на почту. Это не «упущение», а нормальное сужение задачи, если цель сессии — поведение самой формы.

Отдельно подготовьте данные. Для одной короткой сессии обычно нужны три группы значений: обычные, пограничные и неожиданные. Обычные показывают базовую работоспособность. Пограничные помогают увидеть ограничения длины и формата. Неожиданные проверяют, насколько продукт устойчив к реальному вводу пользователя. Важно не брать данные на ходу: случайный набор значений трудно воспроизвести и ещё труднее описать в баг-репорте.

Учебный пример. Допустим, у нас есть форма «Забыли пароль?» с одним полем email и кнопкой отправки. Мы планируем 35-минутную сессию. Исходные данные такие:

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

Как вести журнал во время сессии

Журнал сессии не обязан быть подробной стенограммой каждого клика. Его смысл — сохранить логику исследования и доказательства. Достаточно писать короткими строками: время, действие, факт, вопрос. Если обнаружилось странное поведение, добавьте шаги воспроизведения и отметьте, удалось ли повторить результат. Это защитит от ситуации, когда через час вы помните «что-то было не так», но не можете объяснить, что именно.

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

Для нашего учебного примера журнал может выглядеть так:

00:00–00:03 Открыта форма, поле пустое, кнопка активна.
00:04 Пустое значение -> нажата кнопка.
Факт: сообщение "Введите email", отправка не произошла.
00:07 user@example.com -> отправка.
Факт: сообщение об успехе, поле очищено.
00:11 user@example.com + пробел в конце -> отправка.
Факт: тоже сообщение об успехе.
Вопрос: пробел отрезается или адрес уходит как есть?
00:16 user@@example.com -> отправка.
Факт: форма показала успех вместо ошибки формата. Повторено 2 раза.
00:23 Пробелы "   " -> отправка.
Факт: сообщение "Введите email".
00:27 Повторная отправка валидного email сразу после успеха.
Факт: кнопка активна, ограничителя повторной отправки нет.
00:31 verylongname@example.com -> отправка.
Факт: успех, визуальных проблем нет.

Уже по такому журналу видно, что есть минимум один кандидат в дефект и один вопрос к обработке пробелов. При этом заметки короткие и не мешают самой сессии.

Как подвести итог и решить, что проверять дальше

Итог сессии — это не пересказ всего журнала, а короткий вывод по цели. Для нашего примера он может звучать так: «за 35 минут проверены 6 типов ввода, найден 1 воспроизводимый дефект валидации адреса, зафиксирован 1 вопрос к нормализации пробелов, подготовлены 2 идеи для следующей сессии: проверка повторной отправки на уровне сервера и проверка письма в почтовом ящике». Такой итог даёт команде действие, а не просто архив заметок.

Понять, хороший ли получился чартер, можно по трём признакам. Во-первых, после сессии ясно, на какой вопрос вы отвечали. Во-вторых, другой тестировщик по вашим заметкам сможет продолжить работу без длинных устных пояснений. В-третьих, результат проверяем: есть либо воспроизводимый дефект, либо конкретный вывод, либо сформулированный следующий риск. Если вместо этого остаётся только фраза «посмотрел форму, вроде нормально», чартер был слишком общим.

Ещё один полезный приём — сразу выписать следующий чартер, пока контекст свежий. Исследовательское тестирование ценно тем, что каждая сессия рождает следующую. Если текущая сессия показала риск валидации, следующий шаг может быть уже не про поле, а про серверный ответ, ограничения частоты запросов или текст письма. Так короткие сессии складываются в управляемую проверку, а не в бесконечное блуждание по продукту.

Если хотите сравнить самостоятельную практику с учебной программой, посмотрите внутреннюю карточку курса «Ручное тестирование (Manual QA)». В сохранённой программе и на официальной странице перечислены темы «исследовательское тестирование», «тестирование форм и полей», техники тест-дизайна и тестовые артефакты. Для выбора обучения полезно спросить себя: будет ли у вас практика коротких сессий, кто проверит журнал наблюдений и по какому результату вы поймёте, что чартер действительно рабочий.