Соберите доступные основания для ожиданий
Источниками могут быть описания задач, демонстрации, обращения пользователей, существующие договорённости и разговоры с ответственными участниками команды. Для каждого сведения фиксируйте происхождение и актуальность. Старый макет и действующее решение могут расходиться. Представим форму записи на событие. Надпись на кнопке предполагает отправку заявки, но не объясняет, должна ли она сразу подтверждать участие. Это хороший вопрос к продукту. Полезно записать его до теста, чтобы затем не назвать ошибкой любое поведение, отличающееся от личного ожидания.
Отделите фактическое поведение от желаемого
Наблюдение после повторного нажатия появились две заявки описывает факт. Утверждение повторное нажатие должно создавать одну заявку уже содержит правило, которое нужно обосновать. Возможно, оно следует из задачи пользователя или согласованной логики, но источник стоит обозначить. Также нельзя считать текущее поведение правильным только потому, что приложение давно так работает. Старый дефект способен выглядеть привычной особенностью. В записи удобно держать рядом действие, результат, предполагаемое ожидание и вопрос. Это помогает обсуждать несоответствие без спора о том, кто лучше угадывает намерение продукта.
Исследуйте небольшой участок с понятной целью
Исследовательское тестирование сочетает изучение продукта, создание проверок и оценку результатов. Чтобы работа не превратилась в случайные клики, выберите конкретную область и цель. Например, выяснить, как форма обрабатывает повторную отправку и восстановление после ошибки связи. Работайте в разрешённой тестовой среде с подготовленными данными. Записывайте важные шаги, наблюдения и новые вопросы. Ограниченная сессия может завершиться не только дефектами, но и уточнённой моделью поведения. Отдельно отметьте, что не проверялось. Честная граница исследования полезнее общей фразы всё протестировано.
Превратите находки в согласованные знания
Обсудите вопросы с теми, кто отвечает за поведение продукта, и сохраните подтверждённые решения в доступном команде месте. Если обнаружено расхождение, опишите условия воспроизведения, фактический результат и основание ожидания. Степень влияния тоже объясняют через последствия для пользователя. После уточнения важные сценарии можно превратить в повторяемые проверки. Но сначала нужно понять, какое поведение считается желаемым: автоматизация неверного ожидания лишь закрепляет неопределённость. Полезно сохранять связь между решением и его причиной, чтобы будущая команда могла пересмотреть правило при изменении задачи.
Попробуйте на практике
На бумаге исследуйте вымышленную форму записи на мастерскую с кнопкой отправки и сообщением об успехе.
- Перечислите известные сведения и отметьте, что предполагается, но ещё не подтверждено.
- Выберите одну цель исследования, например поведение при повторной отправке.
- Опишите три проверки и для каждой укажите наблюдение, ожидаемое поведение и источник ожидания либо открытый вопрос.
- Составьте короткий итог для команды: что выяснено, что нужно согласовать и какие области пока не изучены.
Как проверить результат. Факты отделены от предположений, проверки связаны с целью, а отсутствие документа не привело к выдумыванию требований.
Частые вопросы
Нужно ли ждать полной спецификации, прежде чем начать?
Не всегда. Можно изучать разрешённый участок, собирать сведения и задавать вопросы, явно отмечая неопределённость.
Если сценарий работает как раньше, это доказательство правильности?
Нет. История поведения является одним источником информации, но может содержать старую ошибку. Нужна связь с задачей и согласованными ожиданиями.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.