Практическая ситуация: user story вызывает разные трактовки у аналитика и тестировщика. Как провести Example Mapping, чтобы согласовать поведение?
Проведите короткую совместную сессию Example Mapping: зафиксируйте историю, связанные бизнес-правила, конкретные примеры поведения и открытые вопросы. Согласованными примерами уточните критерии приёмки, а нерешённые вопросы превратите в задачи на исследование, а не в скрытые допущения.
Example Mapping появился как практический способ применять идеи Specification by Example и BDD до разработки. Исходная проблема заключалась в том, что текстовые требования часто выглядят согласованными, но разные участники по-разному понимают условия, исключения и ожидаемый результат.
Подход переносит обсуждение с абстрактных формулировок на примеры поведения. Это помогает обнаружить расхождения до реализации и тестирования.
Одна user story может быть понятна бизнесу, но неоднозначна для команды. Например, фраза о возврате платежа не отвечает на вопросы о сроке возврата, частичном возврате, повторном запросе и действиях при отказе внешней системы.
Если такие вопросы не выявить заранее, аналитик может описать один вариант, разработчик реализовать другой, а тестировщик проверить третий. Исправление расхождений после разработки обычно дороже, чем согласование нескольких примеров на этапе анализа.
Сессию проводят участники, которые совместно влияют на результат: представитель бизнеса, аналитик, разработчик и тестировщик. В центре размещают user story, затем добавляют четыре типа сведений:
Сначала команда уточняет цель истории и границы сценария. Затем для каждого правила формулирует несколько примеров: основной успешный случай, граничный случай и существенное исключение. Пример должен описывать входные условия, действие и наблюдаемый результат, а не внутренний способ реализации.
Открытые вопросы нельзя молча закрывать предположениями. Их фиксируют отдельно, назначают ответственного и определяют, блокируют ли они разработку. После согласования примеры можно преобразовать в критерии приёмки, сохранив связь с исходными правилами.
Часто используют ограниченную по времени сессию, например около 25 минут, но это не обязательный стандарт. Если обсуждение не укладывается в ограничение, это сигнал, что история слишком велика, содержит скрытые правила или требует отдельного исследования.
Главный результат — не сама схема карточек, а общее понимание проверяемого поведения. Example Mapping не заменяет приоритизацию, моделирование процесса или формальное согласование требований; он помогает качественно уточнить одну конкретную историю.
История звучала так: «Как клиент, я хочу вернуть оплату, чтобы получить деньги за отменённую услугу». На встрече выяснилось, что бизнес считал возврат доступным только до начала оказания услуги, а тестировщик предполагал возможность возврата после частичного оказания.
Рассматривались два варианта. Можно было сразу записать общее правило «возврат выполняется по условиям договора», но оно оставляло бы слишком много трактовок. Можно было описать все детали в большой спецификации, однако это увеличило бы объём документа и затруднило проверку.
Команда выбрала Example Mapping. Она зафиксировала отдельные примеры для полной отмены до начала услуги, частичного оказания и повторного запроса возврата. Вопрос о сроке фактического перечисления денег вынесли владельцу продукта, поскольку участники встречи не имели права самостоятельно принимать это решение.
В результате историю разделили на реализуемую часть с согласованными условиями и отдельное исследование по спорному сценарию. Тестировщик получил однозначные критерии, а команда избежала реализации поведения, которое бизнес ещё не утвердил.
Пример — это конкретная иллюстрация правила: определённые условия, действие и ожидаемый результат. Критерий приёмки — согласованное условие, по которому решают, принята ли история; он может быть сформулирован через один или несколько примеров.
Набор примеров не всегда покрывает всё правило. Поэтому нельзя автоматически считать историю полной только потому, что приведён один успешный сценарий. Нужно проверить граничные случаи, исключения и наличие условий, при которых правило не действует.
Его нужно явно зафиксировать как открытый вопрос и не подменять ответ догадкой. Если решение действительно необходимо для реализации, историю следует задержать до получения решения либо разделить так, чтобы независимую часть можно было делать без спорного поведения.
Так сохраняется прозрачность неопределённости. Иначе команда создаст скрытый риск: реализованное предположение может позже выглядеть как уже согласованное требование.
Разделение оправдано, если в ходе обсуждения обнаруживаются независимые бизнес-правила, разные цели пользователя, отдельные варианты ценности или большой набор несвязанных исключений. Особенно сильный сигнал — когда одна история требует нескольких самостоятельных решений и не может иметь единый понятный критерий готовности.
Делить следует по самостоятельной пользовательской ценности или поведению, а не просто по слоям реализации. При этом общие правила можно вынести в отдельный согласованный контекст, чтобы не дублировать их в каждой истории.