что такое acceptance testing и зачем его используют

Формальное тестирование в отношении потребностей, требований и бизнес-процессов пользователя, проводимое для определения того, удовлетворяет ли система критериям приемки, и для того, чтобы пользователь, клиенты или другой уполномоченный орган могли определить, принимать ли систему.

Испытание дыма может быть использовано в качестве приемочного испытания перед введением сборки программного обеспечения для основного процесса тестирования.

СОДЕРЖАНИЕ

Обзор

Тестовые примеры UAT и OAT идеально подходят для совместной работы с бизнес-клиентами, бизнес-аналитиками, тестировщиками и разработчиками. Важно, чтобы эти тесты включали как тесты бизнес-логики, так и условия операционной среды. Бизнес-клиенты (владельцы продуктов) являются основными участниками этих тестов. Поскольку условия испытаний успешно достигают своих критериев приемлемости, заинтересованные стороны уверены, что разработка идет в правильном направлении.

Процесс

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

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

Ожидаемый результат успешного выполнения теста:

Приемочное тестирование пользователей

Пользовательское приемочное тестирование (UAT) состоит из процесса проверки того, что решение работает для пользователя. Это не тестирование системы ( проверка того, что программное обеспечение не дает сбоев и соответствие задокументированным требованиям), а скорее гарантия того, что решение будет работать для пользователя (т. Е. Проверка того, что пользователь принимает решение); поставщики программного обеспечения часто называют это «бета-тестированием».

Это тестирование должно проводиться профильным экспертом (SME), предпочтительно владельцем или клиентом тестируемого решения, и предоставлять сводку результатов для подтверждения, чтобы продолжить после испытания или обзора. При разработке программного обеспечения UAT как один из заключительных этапов проекта часто происходит до того, как клиент или заказчик принимает новую систему. Пользователи системы проводят тесты в соответствии с тем, что происходит в реальных сценариях.

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

UAT действует как окончательная проверка требуемой бизнес-функциональности и надлежащего функционирования системы, имитируя реальные условия от имени платящего клиента или конкретного крупного клиента. Если программное обеспечение работает должным образом и без проблем при нормальном использовании, можно разумно экстраполировать тот же уровень стабильности в производственной среде.

UAT следует выполнять по тестовым сценариям. Сценарии тестирования обычно отличаются от системных или функциональных тестов тем, что они представляют собой путь «игрока» или «пользователя». Широкий характер сценария тестирования гарантирует, что основное внимание уделяется путешествию, а не техническим или системным деталям, избегая этапов тестирования «щелчок за щелчком», чтобы учесть различия в поведении пользователей. Сценарии тестирования можно разбить на логические «дни», в которые обычно меняются субъект (игрок / заказчик / оператор) или система (бэк-офис, клиентская часть).

В промышленности обычным UAT является заводское приемочное испытание (FAT). Этот тест проводится перед установкой оборудования. В большинстве случаев тестировщики проверяют не только соответствие оборудования спецификации, но и его полную работоспособность. FAT обычно включает проверку полноты, проверку соответствия контрактным требованиям, подтверждение функциональности (путем моделирования или обычного функционального теста) и окончательную проверку.

Результаты этих тестов вселяют в клиентов уверенность в том, как система будет работать в производственной среде. Также могут быть юридические или договорные требования для принятия системы.

Оперативно-приемочные испытания

Приемочное тестирование по экстремальному программированию

Виды приемочных испытаний

Типичные типы приемочных испытаний включают следующие

Приемочное тестирование пользователей Это может включать заводские приемочные испытания (FAT), т. Е. Тестирование, проводимое поставщиком перед перемещением продукта или системы на место назначения, после чего приемочные испытания сайта (SAT) могут быть выполнены пользователями на сайте. Оперативно-приемочные испытания Также известное как тестирование эксплуатационной готовности, это относится к проверке, выполняемой в системе, чтобы гарантировать, что процессы и процедуры существуют, позволяющие использовать и поддерживать систему. Это может включать проверки, выполняемые для средств резервного копирования, процедуры аварийного восстановления, обучение конечных пользователей, процедуры обслуживания и процедуры безопасности. Приемочные испытания контрактов и нормативных документов При приемочных испытаниях по контракту система проверяется на соответствие критериям приемки, задокументированным в контракте, прежде чем система будет принята. При приемочных испытаниях в соответствии с нормативными требованиями система проверяется на соответствие государственным и юридическим стандартам и стандартам безопасности. Заводские приемочные испытания Приемочные испытания, проводимые на объекте, на котором разрабатывается продукт, и выполняются сотрудниками организации-поставщика, чтобы определить, удовлетворяет ли компонент или система требованиям, обычно включая аппаратное обеспечение и программное обеспечение. Альфа- и бета-тестирование Альфа-тестирование проводится на сайтах разработчиков и включает тестирование операционной системы внутренним персоналом, прежде чем она будет передана внешним клиентам. Бета-тестирование проводится на объектах клиентов и включает тестирование группой клиентов, которые используют систему в своих местах и ​​предоставляют отзывы, прежде чем система будет передана другим клиентам. Последнее часто называют «полевыми испытаниями».

Источник

Пользовательское приемочное тестирование: руководство по успешному запуску новых продуктов

Как бы банально это не звучало, но большинству людей нравится, чтобы все было просто. Особенно, когда дело касается новых продуктов. По сути, потенциальная ценность, которую ваш продукт или сервис может привнести в жизни в ваших клиентов, не имеет никакого значения, если люди не смогут использовать его так, как этого хочется им, они почти наверняка пройдут мимо и обратят внимание на другие решения.

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

Именно здесь вам может пригодиться пользовательское приемочное тестирование (User Acceptance Testing, UAT). В сегодняшней статье мы расскажем вам, что это такое, когда и как вам следует использовать данный метод и почему он играет столь важную роль при выводе продукта на рынок.

Содержание статьи

Что такое пользовательское приемочное тестирование?

Пользовательское приемочное тестирование — процесс, в ходе которого вы просите группу людей использовать продукт, сервис или часть софта с его полным функционалом.

Известное также как бета-тестирование, UAT служит трем основным целям:

Далее в статье мы еще поговорим о важности UAT, но сперва давайте быстро разберем разные типы такого тестирования.

5 типов пользовательского приемочного тестирования

1. Первый тип, на котором мы и будем фокусироваться в этом посте, — альфа/бета-тестирование. При альфа-тесте роль пользователей на себя берут штатные сотрудники и члены команды разработчиков. А вот бета-тест проводится с участием реальных, специально отобранных пользователей. Ниже — пример лендинга с предложением зарегистрироваться для бета-тестирования Division 2, анонсированного на E3:

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

2. Контрактное приемочное тестирование (contractual acceptance testing) нацелено на то, чтобы проверить, соответствует ли разработанный продукт контрактным требованиям, согласованным всеми заинтересованными сторонами. Обычно такое тестирование используют, дабы убедиться в том, что сторонняя команда разработчиков выполнила свои договорные обязательства.

3. Законодательное приемочное тестирование (regulation acceptance testing) позволяет убедиться в том, что продукт соответствует всем законам и предписаниям своей отрасли и юрисдикции. Такое тестирование следует проводить в сферах здравоохранения и финансов, кроме того, с внедрением GDPR на нем должны акцентировать внимание все европейские компании.

4. Операционное приемочное тестирование (operational acceptance testing) сосредоточено на определении эффективности закулисных процессов внутри организации, которые гарантируют людям полноценное использование продукта. С помощью этого типа тестирования оцениваются такие процессы, как онбординг, сбор данных и защитные механизмы.

5. Тестирование по стратегии черного ящика (black box testing) ориентировано на анализ причинно-следственной связи между взаимодействием пользователя с продуктом и результатом, полученным за счет этого взаимодействия. Этот тип тестирования связан с UAT тем, что здесь людям говорят, для чего предназначен продукт, но изучать, как именно он работает, они могут самостоятельно.

Почему пользовательское приемочное тестирование играет столь важную роль

Итак, UAT является неотъемлемой частью процесса создания продукта. Тем не менее, вы должны фокусироваться на таких тестах не только при их фактическом проведении, но и на всех этапах разработки:

Как видно из диаграммы выше, пользовательское приемочное тестирование нацелено на то, чтобы все изначальные требования к продукту были соблюдены.

Думайте о конечном пользователе

Ценность вашего продукта определяется только людьми, которые будут с ним работать.

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

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

Кроме того, это поможет вам сделать процесс разработки менее произвольным, поскольку каждое изменение или улучшение будет сопровождаться вопросом: «Как эта функция поведет себя в ходе пользовательского приемочного тестирования?».

Подтвердите product/market fit

Положительные результаты, полученные бета-тестерами во время вашего UAT, могут подтвердить не только наличие рынка для вашего продукта, но и то, что потребители в рамках этого рынка будут успешно использовать ваше решение.

Когда продукт готов к проведению UAT?

Прежде чем начинать UAT, команда разработчиков должна соблюсти ряд предварительных условий.

Остановимся на этих критериях более подробно.

Бизнес-требования должны быть готовы

Согласно iSixSigma, главным образом документы по бизнес-требованиям создаются, чтобы:

Продукт должен функционировать на своих предельных возможностях

Пользовательское приемочное тестирование не является синонимом функционального теста. UAT не предназначено для выявления сбоев, ошибок, зависаний и прочих проблем.

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

Проблемы должны фиксироваться, исправляться и тестироваться

По ходу разработки продукта вы почти наверняка столкнетесь с перечисленными выше проблемами. Чтобы подготовить свое решение к UAT, ваша команда должна не только исправлять эти просчеты, но и фиксировать их в специальном лог-файле.

Этот лог-файл должен содержать следующую информацию:

Такой подход обеспечивает максимальную прозрачность и наглядность в контексте разработки продукта для всех заинтересованных сторон.

Команда по тестированию системы должна дать добро

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

Зачем нужно пользовательское тестирование: кейс от Feedly

6 шагов успешного пользовательского приемочного тестирования

Процесс UAT включает в себя следующие этапы:

1. Проанализируйте бизнес-требования

Как было сказано ранее, прежде чем переходить к разработке продукта, вам необходимо позаботиться о документации по бизнес-требованиям. Но помимо этих документов, вам нужно собрать следующее:

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

2. Разработайте UAT план

На этой стадии вы определяете такие логистические критерии UAT, как:

3. Определите тестовые сценарии и кейсы

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

По сути, вы должны разрабатывать такие тестовые сценарии так же, как и свой onboarding-процесс. Таким образом вы убедитесь в том, что ваше бета-тестирование соответствует тому, как продукт будет использоваться в реальных условиях.

4. Подготовьте тестовые данные

Разумеется, вы также должны наладить процесс, который бы позволял вам эффективно собирать и подготавливать тестовые данные. Кроме этого, вам нужно быть уверенными в том, что используемая вами информация всегда будет оставаться конфиденциальной (особенно учитывая то, что GDPR уже вступил в силу в Европе).

5. Проведите тест

В ходе тестирования члены QA команды работают с бета-пользователями, чтобы завершить обозначенные тестовые задачи. Как только юзер достигает точки выхода, его просят оценить полученный опыт как позитивный или негативный.

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

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

6. Подтвердите достижение бизнес-целей

Как только бета-пользователи дадут вам положительную обратную связь, вам нужно будет подготовить документацию, которая послужит официальным сигналом для вывода вашего продукта на рынок.

Эта документация включает:

Затем эти документы представят на встрече по UAT, где будут присутствовать все заинтересованные стороны. Помимо рассмотрения самих документов, участники собрания должны будут убедиться в том, что продукт действительно готов к запуску и что закулисные бизнес-процессы компании гарантируют его стабильную работу.

Источник

UAT-тестирование

Перед продажей продукта целевым клиентам важно проверить, что люди смогут работать с ним так, как им хочется. Именно для этого проводится UAT-тестирование. Во время него проверяют эффективность сервиса, лично оценивают функционал. Данный процесс также называется бета-тестированием и User Acceptance Testing. По итогам проверки производителю станет ясно, есть ли какие-либо ошибки, которые заметят другие пользователи. Также удастся выяснить, насколько продукт готов к продаже. В данном материале мы разберёмся: UAT-тестирование – что это такое, как проводится и для чего полезно это исследование.

Общая информация

Бета-тестирование выполняет одновременно несколько функций. Главная его задача – подробно изучить сервис, проверить его эффективность и функционал. Этим занимается группа людей, которая обращает внимание на удобство использования продукта.

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

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

Типы тестирования

Тестирование продукта бывает разных типов, и каждый из них имеет свои особенности.

Каждый вид по-своему важен, и многие сервисы проходят каждый этап. Приёмочное тестирование позволит понять, нужно ли что-то менять и дорабатывать.

Когда можно запускать пользовательское тестирование

Разобравшись в определении термина UAT-тестирование, нужно уточнить следующий момент. Запрещено запускать пользовательское тестирование исключительно по своему желанию. Важно убедиться, что продукт к нему готов, а для этого придётся соблюсти ряд условий.

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

Также это необходимо для того, чтобы:

Пользовательское тестирование можно проводить тогда, когда продукт уже полностью работоспособен. Данный этап используется не для поисков багов и сбоев в функционале продукта. Он нужен для оценки того, как работает сервис/товар, отвечает ли он задумке. Перед проведением исследования стоит учесть все погрешности измерения, возможные сбои и особенности функционала. Если проект ещё нуждается в доработке, тогда данный вид тестирования не проводится.

Все допущенные ошибки необходимо отмечать, исправлять и затем снова выполнять проверку. Во время разработки проекта создатели не смогут избежать проблем. Все неисправности нужно фиксировать и указывать, как они были устранены. Тогда заинтересованные стороны смогут наглядно понять, как проходила работа.

Тестовая команда должна одобрить продукт. Разработчики обязаны подтвердить, что проект готов к бета-запуску среди ограниченного круга юзеров.

Как проводится пользовательское тестирование

Важно соблюдать определённые правила, чтобы всё прошло успешно.

Пользовательское тестирование – это непростой процесс, но он необходим для подготовки проекта к выпуску. Если соблюсти все правила, удастся предоставить заказчикам качественный продукт, который будет действительно полезным и востребованным

Источник

Разработка через приемочные тесты (ATDD). Что это такое, и с чем его едят

Разработка через тестирование (TDD) – отличный способ повысить качество и надежность кода. Этот же подход может быть распространен и на разработку требований. Он называется «Разработка через приемочные тесты» – acceptance test driven development (ATDD). Сначала я присматривался к этому подходу, потом пробовал применить, потом долго тюнинговал, чтобы приспособить его под мои нужды, и теперь хочу поделиться мыслями. И для себя еще раз разложить все по полочкам.

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

Вместо введения

Когда я работал программистом в аутсорс компании на один банк, то мне приходилось изучать спецификации требований и оценивать трудоемкость задач. Оценивать нужно было как можно точнее, мы работали по модели оплаты за проект (Fixed Price), и все промахи в сроках были на нашей стороне и не оплачивались. Каждый раз, когда я читал спецификации, мне было все понятно, я не замечал в них нелогичные моменты, упущения, странности. Но как только начиналась разработка, то все косяки требований вылезали наружу, и было удивительно, как я их пропустил в начале. Несмотря на все усилия, я так и не мог придумать способ, как читать спецификации и находить в них проблемы до реализации.

Потом я перешел на работу в крупную компанию, которая занималась разработкой большого и сложного коробочного продукта, над которым работала огромная команда. Аналитики общались с партнерами и клиентами и записывали их пожелания. Потом эти спецификации, прежде чем быть взятыми в работу, проходили процедуру ревью, в которой участвовали и разработчики. Чтобы не тратить время на самой встрече, надо было сначала прочитать требования и подготовить вопросы. Как и в предыдущем проекте, большинство вопросов к содержимому документов возникали позднее – во время разработки, а не тогда, когда должны были возникнуть, то есть на этапе ревью.

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

Что такое ATDD

Acceptance test driven development (ATDD) является развитием идеи test driven development (TDD). Общий смысл в том, что прежде чем что-то делать, надо придумать критерий выполненной работы и критерий того, что работа сделана правильно. Почему это важно? Потому что эти критерии позволяют на самом раннем этапе понять, что именно требуется сделать, как это сделать, что именно считать хорошим результатом. Т.е. не выяснять детали по ходу дела, строя прототипы, а сразу приближаться к цели, так как цель уже определена, причем вполне формально.

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

Несмотря на общее название, этот подход относится ко вполне определенной части процесса – той, где происходит разработка требований и их формализация в спецификации. В данном процессе часто участвуют люди как со стороны бизнеса, так и с технической стороны, т.е. люди, обладающие разными компетенциями и взглядами на мир. Заказчики на интуитивном уровне понимают, что именно они хотят видеть в продукте, но сформулировать и перечислить требования кратко (и полно) могут далеко не все. Разработчики (представители исполнителя), в свою очередь, часто не знают, что именно забыл рассказать заказчик, и как это выяснить.
Для решения этих задач используется фреймворк Given – When – Then.

Фреймворк Given – When – Then

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

В юнит тестах используется шаблон Arrange – Act – Assert (AAA). Это означает, что в тестах должны быть явные части, отвечающие за подготовку данных — arrange, само действие, результат которого надо проверить – act, и собственно проверка, что реальность совпала с ожиданиями – assert. Для приемочных тестов используется подход Given – When – Then (GWT). Суть та же, только с другого ракурса.

Given часть может содержать в себе как одно, так и набор состояний. В случае, когда их несколько, эти состояния должны читаться через «И». Объединять какие-то состояния через «ИЛИ» можно, но тогда это будут два разных теста. Такое возможно для упрощения записи. Я рекомендую избегать этого до того момента, как все возможные комбинации состояний не будут описаны. Тогда можно быть уверенным, что ничего не забыто и слить несколько тестов в один для упрощения чтения и понимания. Это же справедливо и для Then — исходов, которые надо проверить может быть несколько. When должен быть один. Взаимовлияния триггеров лучше избегать.

GWT тесты вполне можно читать вслух: «Пусть (given) A и B, и C. Когда (when) случается D, то (then) получается E и F.». Их вполне можно использовать для документации или формулирования требований. Когда я говорю «читать», я не имею ввиду, что именно так они и должны быть записаны. В реальности такие тесты получаются очень масштабными. Если их записать простым текстом, то потом взглянуть на них системно очень тяжело. А без системы легко пропустить какие-нибудь важные сценарии.

Очень важный момент: формат записи нужно выбирать тот, который наиболее подходит к вашей задаче, с которым удобнее работать. Никаких ограничений тут нет. Given, when, then — это общая структура записи, то есть то, что обязательно должно быть в тесте, а непосредственное представление может быть любым – хоть предложения, хоть таблицы, хоть диаграммы.

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

Пример

Для примера возьмем что-нибудь простое и понятное, например, светофор. Как можно описать требования к разработке светофора с помощью GWT нотации? Для начала нужно понять, что именно в светофоре можно назвать Given, что является When, а что Then.

За состояние светофора можно принять информацию о том, какая секция сейчас горит. Светофор переключается (меняет состояние) через какие-то промежутки времени. Значит триггером является таймер, точнее, срабатывание таймера. Результатом срабатывания триггера является переход в одно из состояний. Т.е. можно считать, что в примере со светофором Given и Then – один и тот же набор:

Опишем поведение светофора в нотации GWT:

Вот 5 сценариев, прочитав которые, можно понять, как работает светофор. Естественно, у светофора есть еще куча режимов, например, режим желтого мигающего (когда он неисправен), или ручной режим управления (например, в случае ДТП) и т.д. Но не будем усложнять иллюстрацию.

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

Пример показывает один из основных преимуществ приемочных тестов: они позволяют общаться с бизнес пользователями практически на их языке. Приятным бонусом идет готовый набор сценариев для тестирования и последующей автоматизации.

Обеспечение полноты

Нотация Given — When — Then структурирует процесс составления тестов и дает уверенность в том, что тесты описывают все аспекты поведения системы. Не нужно сидеть и постоянно спрашивать себя: «А какой сценарий я еще не описал?».
Итак, алгоритм такой:

На каждом из этих этапов требуется участие заказчика или человека, который играет его роль, потому что именно он лучше всех представляет, что и как в итоге должно работать.

Почему полезно

Как уже было сказано, подобный подход, несмотря на свою избыточность, дает уверенность в том, что ни один из сценариев не будет пропущен. Это, пожалуй, главное преимущество такой формализации. Зачастую бизнес-пользователь видит процесс только в общих чертах и ему не видны детали. Я уверен, что вы постоянно слышите от заказчика или даже аналитика фразы типа: «Нам нужна такая-то фича, я все придумал, вот, смотри картинку», или «Тут нам нужна такая-то кнопка, у нас уже есть похожая функциональность в другом месте, сделай как там». Если до того, как начать разработку, сесть и прикинуть возможные варианты развития событий, то сразу всплывет очень много деталей, в которых, как известно, и кроется дьявол.

Подобный подход так же полезен и в случае, когда от аналитика приходит спека и ее нужно прочитать, дать свои оценки сложности и трудозатрат. При прочтении все детали ускользают, но если по ходу чтения вести конспект по форме GWT, то сразу становится понятно, какие сценарии плохо или неточно покрыты в требованиях и требуют уточнений.

Помимо анализа требований с целью разработки решения, GWT сценарии можно применять и для сбора требований. Предположим, что есть какая-то функциональная область и человек, который в ней разбирается, но время на общение с ним очень ограничено. Если подготовиться заранее и разобрать сценарии с помощью GWT фреймворка, то на самом интервью нужно будет узнать только то, что мы ничего не забыли из раздела Given, When и уточнить, что именно должно быть в разделе Then.

Есть специальные инструменты для автоматизации GWT сценариев, записанных в том числе и на естественных языках. Пример — cucumber. Я с ними не работал, поэтому ничего кроме факта их существования рассказать не могу.

Подводные камни

Обратная сторона мощности GWT — избыточность. Предположим, что вы определили N штук given, M штук when и K штук then. В худшем случае количество тестов будет огромным – N M K. И с этим надо как-то жить. Это верхняя оценка сложности; в реальности далеко не все эти сценарии будут осуществимы, а часть из них будет дублировать друг друга, а еще часть можно пропустить ввиду низкого приоритета или очевидности.

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

Следующий недостаток объясняет, почему ATDD скорее относится к области формализации требований с бесплатным бонусом в виде тестовых сценариев, а не собственно тестирования. Такие сценарии не могут описать композитные (большие и сложные) сценарии. Тестирование идеального черного ящика в первую очередь основано на аксиоме его идеальности. В реальности ящики черными не бывают, они всегда взаимодействуют с чем-то снаружи себя, являясь при этом частью более сложной системы — продукта. Легко можно переусложнить требования, если попытаться включить в один документ сразу все связи внутри продукта. Такой набор приемочных тестов будет настолько огромным и сложным, что мало чем сможет помочь. Поэтому, в реальной жизни сквозные сценарии в качестве приемочных тестов не применяются.

Немного исторической справки

Если верить Википедии, то идея формулировать спецификации через конкретные сценарии была впервые описана Ward Cunningham в 1996 году, а сам термин specification by example ввел Martin Fowler в 2004 году. Дальнейшее развитие идеи формулируется в книге «Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing» от Gojko Adzic 2009 года. В 2011 он же выпустил еще одну книгу на эту тему: «Specification by Example: How Successful Teams Deliver the Right Software». Рекомендую эти книги для обращения к первоисточнику.

Источник