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

Заменяют ли пользовательские истории документ с требованиями?

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

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

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

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

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

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

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

Критерии приемлемости

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

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

Часто задаваемые вопросы (FAQ)

Недостатки пользовательских историй

• Не объясняет «как?»

• Не включает нефункциональные требования (например, отказоустойчивость, производительность, удобство использования, модифицируемость)

• Пользовательские истории не заменяют бизнес-требования.

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

• Может быть неправильно понят и неправильно использован.

• Может утратить свою первоначальную суть/цель (особенно в компаниях и командах, которые используют Agile только для целей соответствия).

Написание сценариев с шагами первого уровня

Очень важный этап. Именно на этом этапе происходит та самая магия BDD по модели «Three Amigos», когда заказчик, программист и QA начинают говорить на одном языке, а скромный автор этих строк является переводчиком на этот язык. Что важно на этом этапе? Самое важное — это абстрагироваться от конечной реализации, от интерфейса, от всех этих кнопочек, надписей, полей ввода, динамических списков etc. Мы должны формулировать шаги в терминах бизнес-пользователя, рассчитывая на то, что этот сценарий может быть реализован в любом другом учётном продукте, либо стать основой для разработки нового продукта. Такой уровень абстракции позволяет придать сценариям универсальность и независимость от конечной реализации, что, в свою очередь, приводит к тому, что наши требования будут достаточно долговечными. Всю зависимость от конечной реализации мы стараемся уносить на второй уровень шагов.

Шаги первого уровня — это формализация критериев приёмки посредством языка Gherkin. Наша цель состоит в том, чтобы трансформировать критерий приёмки в простую, линейную, короткую последовательность действий. Идеальный сценарий с шагами первого уровня состоит из трёх предложений, начинающихся с «Дано, Когда, Тогда». В «Дано» мы описываем какие данные поступают на вход сценария (элементы справочников, документы, регистры сведений/накопления), в «Когда» — каким воздействиям мы будем подвергать эти входные данные (создание/проведение документов, выполнение обработок, запуск регламентных заданий), в «Тогда» — во что должны трансформироваться входные данные (сформированные документы, движения регистров, содержимое отчётов). Но вот эти подробности — они будут уже на втором уровне, первый — максимально от этого абстрагируется (но мы должны держать в голове, что в конечном итоге придём к этому).

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

На что нужно обратить внимание. Общий подход — это использование раздела «Контекст» для выполнения действий общих для всех сценариев: указание названия вышестоящей пользовательской активности в качестве эпика (используется для группировки сценариев в Allure), подключение тест-клиента с полными правами, чтобы иметь возможность выполнять вспомогательные действия (загрузка и проведение документов, старт фоновых заданий и т.д.) по ходу выполнения сценариев, загрузка данных или установка настроек общих для всех сценариев.

Далее вы видите, что используется конструкция «Структура сценария». Для тех, кто не в курсе, «Структура сценария» — это тот же сценарий, но дополненный блоком примеров. Каждая строчка примера приводит к выполнению сценария с подстановкой значений из этой строчки. Эта «структура сценария» несовершенна. В примеры не вынесены загружаемый макет из блока «Дано», а также макет отчёта, используемый для проверки в строке 32 (они захардкожены в шагах второго уровня). Поэтому это просто заготовка под «структуру сценария», но рабочий вариант — это только одна строчка примеров. Для возможности использовать несколько строчек примеров нужно доработать напильником. Но мне важно донести вам принцип, оставим перфекционизм занудам.

Посмотрите, как я постаралась сгладить формулировки, чтобы уйти от деталей реализации. «Я инициирую создание отчёта» — не «нажимаю на кнопку», не «выбираю из пункта меню», не «даблкликаю на строчку». Это даёт программисту определённую свободу действий, но при этом ограничивает его наличием некого списка, в котором будет выбираться заказ, прежде чем отчёт будет сформирован. Программист понимает последовательность действий пользователя, понимает какие данные на входе, и чего от него ждут на выходе — в принципе этого достаточно для реализации данного функционала. Если функционал требует замысловатости интерфейса, то я вместе с заказчиком делаю набросок, ссылку на который вставляю в feature-файл. Шаг в строке 33 — технический, а не бизнесовый. Похоже его нужно будет вынести в обработчик «ПередОкончаниемСценария», также как туда уже вынесены шаги по очистке данных, созданных в ходе выполнения сценария.

Следующий пример уже с реально рабочей «структурой сценария». Это пример сценария интерактивного взаимодействия пользователя с интерфейсом «АРМ кладовщика», так называемый «негативный сценарий», когда мы отрабатываем кейс, где система не должна позволять пользователю выполнять определённые действия:

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

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

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

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

Похожи ли пользовательские истории на псевдокод?

Они используются по-разному.

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

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

Составление критериев приёмки пользовательских историй

Следующий шаг находится на стыке SM и BDD. С одной стороны, критерии приёмки (acceptance criteria) — это инструмент конкретизации пользовательской истории, когда мы фиксируем ключевые моменты, которые важны заказчику при реализации данной пользовательской истории, с другой стороны (и это надо чётко осознавать!), критерии приёмки — это будущие сценарии приёмочного тестирования. В начальном своём виде критерии приёмки — это некий чеклист, каждый пункт которого озвучивается заказчиком, то есть он их просто называет: «вы когда будете делать учтите вот этот момент, и ещё очень важно чтобы было вот так-то, и обязательно чтобы не было возможности сделать», а я их просто записываю 😉. Если заказчик не готов сходу формулировать критерии приёмки, то я его подбадриваю вопросом: «А как вы будете проверять, что мы вам всё сделали правильно?».

Теперь о том, как зафиксировать критерии приёмки в StoryMapper. Как вы, наверное, уже успели заметить, все объекты, создаваемые в StoryMapper — это feature-файлы (всё в рамках концепции «документация — это код»). Стало быть вы вольны записывать критерии приёмки в свободной форме. Например, немногие из тех, кто пишет фичи в курсе, что в рамках синтаксиса Gherkin, можно писать свободный текст после блока «Функция/Функционал» или после блока «Сценарий» вплоть до ближайшего ключевого слова, написанного с начала строки:

То есть практическая идея такая: если у вас критерии приёмки не сформулированы, а есть сырой текст от заказчика — смело его вставляйте после блока «Функция/Функционал». Если дошли руки до кристаллизации критериев приёмки — фиксируйте их блоком «Сценарий/Структура сценария», а наброски примеров — опять же свободным текстом после блока «Сценарий».

Итак, критерии приёмки в рамках UF «Ecom»: 

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

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

Подтверждение

Наконец, «Подтверждение» в пользовательской истории определяет, завершена она или нет. Это относится к Критериям приемлемости, которые декларируют требования истории.

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

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

В отличие от предыдущих плохих примеров, вот пользовательские истории, которые работают хорошо:

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

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

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

Эти пользовательские истории хорошо работают, потому что они обладают характеристиками INVEST:

• Их функциональность не зависит от других историй.

• Они оставляют место для различных вариантов реализации.

• Они добавляют пользовательскую ценность проекту.

• Их размах и размер точно могут быть оценены разработчиками.

• Они достаточно малы, чтобы их можно было спланировать и/или перераспределить по сравнению с другими историями.

• Их можно проверить.

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

Следующие типы приемочного тестирования

1. Пользовательское приемочное тестирование (UAT)
2. Бизнес Приемочные испытания (BAT)
3. Приемочные испытания по контракту (CAT)
4. Приемочные испытания правил/соответствия (RAT)
5. Приемочные испытания при эксплуатации (OAT)
6. Альфа-тестирование
7. Бета-тестирование

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

#1. Приемочное тестирование пользователей (UAT)

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

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

#2. Приемочное тестирование бизнеса (BAT)

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

# 3. Приемочное тестирование контракта (CAT)

При приемочном тестировании по контракту продукт тестируется со всеми примерами приемочного тестирования в течение срока действия контракта, который указан в контракте (Соглашение об уровне обслуживания (SLA)). Оплата будет произведена компанией клиентом только в том случае, если продукт прошел все приемочные варианты использования.

#4. Приемочные испытания правил/соответствия (RAT)

Приемочные испытания правил также известны как приемочные испытания на соответствие.

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

#5. Эксплуатационное приемочное тестирование

В STLC – эксплуатационное тестирование или эксплуатационное приемочное тестирование (OAT)делается для оценки операционной готовности программного приложения перед его выпуском в производство. Он обеспечивает бесперебойную работу системы в стандартной операционной среде (SOE). Основное внимание уделяется совместимости, восстановлению, надежности, ремонтопригодности и т. д. Оно также известно как приемочное тестирование продукта.

Ознакомьтесь с нашим подробным руководством по эксплуатационному приемочному тестированию здесь

#6. Альфа-тестирование

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

Ознакомьтесь с нашим подробным руководством по альфа-тестированию здесь

#7. Бета-тестирование

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

Просмотрите наше подробное руководство. о бета-тестировании здесь

Пример

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

Тип пользователя отвечает на вопрос «кто», функция указывает на «что» и, наконец, преимущество объясняет «почему» в пользовательской истории.

Беседа

«Разговор» — это совместное взаимодействие, обычно личное, при содействии Владельца Продукта. В этом взаимодействии участвуют все заинтересованные стороны и команда. Он поощряет постоянное постепенное сотрудничество между членами Agile-команды, позволяя им иметь общее понимание проблемы.

Команда внесет коррективы в «Карточку» на основе информации, полученной в ходе «Разговора». Хотя эти разговоры обычно устные, их поддерживают автоматические тесты и документация.

Резюме

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

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

• Для полноты картины следует использовать все способы моделирования пользовательских ролей.

• Персона (persona) – воображаемое представление пользовательской роли (её очеловечивание), помогает членам команды лучше представлять пользовательскую роль.

• Само моделирование пользовательских ролей уже позволяет выявить новые пользовательские истории (или требования).

Михайлова Анна

Начальник отдела интеллектуального анализа данных, главный системный аналитик,
Консорциум «Кодекс»

Как проходит тестирование ПО

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

• Анализ поставленных требований
• Дизайн и, собственно сама разработка проекта
• Имплементация кода и получение конечного продукта

Дізнайтеся, як утримувати work-life-баланс, від топменеджерки з досвідом в NPR, Microsoft, IBM та Amazon Alexa.

Этап тестирования – обязательный этап жизненного цикла ПО. Это очень важный процесс работы над проектом, на котором определяется что сделано правильно и хорошо, а что – нет. В интернете можно встретить определение термина «тестирование» как процесс поиска ошибок. На самом деле это утверждение верно лишь частично. Одна из аксиом software development гласит о том, что найти все баги невозможно. И, если в результате подробного тестирования не было выявлено ни одной ошибки, это еще не означает, что их нет.

Инструменты UAT, примеры тестирования

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

Прежде всего это FitNesse tool, написанный на Java, который предназначен для автоматизации процесса тестирования. Он поставляется в виде единственного исполняемого jar файла, который включает вики движок, встроенный веб-сервер, тестовый движок и прочие ресурсы. FitNesse позволяет пользователям разрабатываемой системы осуществлять ввод данных в специальном формате (понятном для не-программистов). На основе этого ввода автоматически генерируются тесты, которые  исполняются системой, с последующим возвратом результатов. 

Watir: другой инструментарий для приемочного тестирования на основе браузера. Это – библиотека языка Ruby, которая позволяет создавать свои сценарии тестирования веб-приложений.

Скрипт для тестирования может выглядеть, например, вот так:

# Пример небольшого скрипта для проверки последовательности действий 

 require 'watir'                          # подключаем инструмент Watir

 testing _site = 'http://www.some_adress.com'      # определяем переменную

 ie = Watir::IE.new                       # запускаем веб-обозреватель Internet Explorer

 ie.goto(testing _site)                   # переходим по ссылке

 ie.text_field(:name, "search").set("Picasso") # в текстовое поле с именем "search" помещаем слово "Picasso"

 ie.button(:name, "Knopka").click           # нажимает на кнопку с именем "Knopka"

 if ie.text.include?("Programming Ruby")  # описание условия теста

   puts "Test Passed. Found the test string: 'Programming Ruby'." # заключение по успешному прохождению

 else

   puts "Test Failed! Could not find: 'Programming Ruby'" # тест не пройден

 end

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

Пользовательская история завершена, когда она соответствует критериям приемлемости и определению готовности (DoD).

Написание шагов второго уровня

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

В самом начале я вручную набиваю входные данные для примеров и сохраняю макеты данных (те самые fixtures). Я по старинке выгружаю в формате mxl, хотя на сегодняшний день сериализатор поддерживает формат json более выгодный при хранении макетов в git. При этом в сериализаторе есть возможность сохранять в файл настройки выбора выгружаемых в макет данных, что позволяет мне актуализировать макеты после обновления базовой конфигурации или изменения структуры метаданных выгруженных в макет объектов. Знаете эту проблему? Когда ваши макеты перестают загружаться, потому что какие-то реквизиты документов были удалены или переименованы. Это та цена, которую приходится платить за скорость подготовки и очистки тестовых данных.  Так вот сохранение в файл настроек выгрузки в сериализаторе для каждого сценария и последующее помещение их в git позволяет эту проблему слегка нивелировать. Выгруженные макеты данных я также складываю в git в отдельную папку Examples. Дальше в разделе «Дано» каждого сценария мне нужно эти макеты загружать. К сожалению, в стандартной библиотеке VA нет шага по загрузке макета из внешнего файла (ну или я не нашла). Тот, что есть, грузит данные только из макета обработки со step definitions. Ну и поскольку «я не настоящий сварщик», я обратилась к нашим программистам, и добрые программисты мне сделали шаг «И я загружаю макет из внешнего файла ‘./Examples/US42договор.mxl’ » для нашей внутренней библиотеки шагов. Файл ищется относительно каталога проекта. Кроме того, я столкнулась с такой проблемой, что несмотря на установленную галку «выгружать движения», движения ни в какую не выгружаются. Разбираться мне было некогда, поэтому я после загрузки макетов провожу документы в нужном мне порядке: сначала ввод остатков, затем заказы клиентов в с резервом и только потом РТиУ. Собственно этот порядок делает весьма затруднительным автоматическое проведение документов после загрузки, поскольку непонятно в каком порядке нужно проводить документы, а так, конечно, добрые программисты пришли бы мне на помощь. Шаги проведения документов я сначала записывала «кнопконажималкой», но потом узнала, что в библиотеке есть волшебный шаг » И Я открываю навигационную ссылку ‘e1cib/data/Документ.ЗаказКлиента?ref=bacaba6e71f047c911e9610fc4adcbf5’ » — и моя жизнь наладилась. Итак, вот пример написания шагов второго уровня для шага загрузки входных данных:

Остальные шаги второго уровня я пишу при помощи кнопконажималки, кнопки «Добавить известный шаг» в VA и такой-то матери. Разработчики StoryMapper обещают в ближайшем будущем добавить в редактор фич контекстную подсказку из предопределенного набора библиотечных шагов — и тогда дело пойдёт веселее. На чём бы я хотела заострить внимание. Иногда мне снова-таки приходилось прибегать к помощи добрых программистов. В частности, когда была необходимость сравнить значение некоего реквизита на форме документа со значением ячейки табличного документа (то есть печатной формы). Мне приходилось выкручиваться вот так:

То есть я складывала в Контекст значение поля формы, ВСЮ печатную форму, адрес ячейки в табличном документе. После чего добрые программисты написали мне странную конструкцию со словом «Найти», чтобы можно было найти вхождение переменной контекста в тексте ячейки табличного документа. Это на случай, если в этой ячейке будет длинная строка, в которой одним из слов будет искомое мной значение. По словам создателя VA в последних версиях в контекст уже можно складывать значение конкретной ячейки табличного документа, что позволит избежать помещения в контекст целой печатной формы.

Ну и очень полезным шагом проверочной части сценария является «И Табличный документ ‘ТекущаяПечатнаяФорма’ равен макету ‘/examples/US292/ПФ_ТОРГ-12.mxl’ «. Его прелесть заключается в том, что я могу предварительно сохранить макет печатной формы или отчёта, которым собираюсь проверять корректность разработанного функционала, и потом одним шагом сравнить сохранённый макет со сформированным на этапе выполнения сценария табличным документом. Очень рекомендую.

Ещё один момент, как корректно формировать отчёты и печатные формы для последующей проверки. Когда я была ещё совсем зелёной неофиткой культа огуречного монстра, тогда по неопытности позволила себе написать такое:

Увидев этот набор шагов, мой Господин очень разнервничался, топал ногами и кричал слова «асинхронность» и «аяяяй». Потом успокоился и объяснил, что «Паузу» надо использовать только в тех случаях, когда другого выхода нет и нужно просто подождать. В случае же ожидания формирования отчётов или печатных форм нужно пользоваться асинхронными шагами типа «И я жду, что в табличном документе ‘ТекущаяПечатнаяФорма’ ячейка ‘R2C1’ станет равна ‘ТОРГ-12’ в течение 20 секунд». В этом случае мы задаём верхний предел ожидания, но если формирование печатной формы закончится раньше, то выполнение сценария успешно продолжится. Но ждать нужно в любом случае — иначе печатная форма или отчёт ещё не сформируются, а шаги по проверке результата начнут выполняться и падать.

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

Кто пишет пользовательские истории?

Каждый может писать пользовательские истории. В среде Agile/Scrum владелец продукта несет ответственность за невыполненные работы по всем пользовательским историям.

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

Заключительные замечания

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

• Написано с точки зрения пользователя.

• Определите пользователя, функцию и выгоду (или ответьте «кто, что и почему?»).

• Иметь характеристики INVEST.

• Не слишком ограничительный с точки зрения реализации.

• Иметь критерии приемки и определение готовности (DoD).

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

Пользовательская история — это наименьшая функциональная единица в Бэклоге Продукта Agile/Scrum. Большинство современных команд разработчиков программного обеспечения потребуют от вас его использования, поэтому его определенно стоит изучить.

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

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

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

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

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

Пользовательские роли, персоны

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

Для разделения историй по разным типам пользователей придуманы пользовательские роли.

Кроме описания группы пользователей аналитики часто задают некоторый образ, дают роли имя, возраст, профессию, это часто помогает команде представить, для кого делается продукт, также помогает и выявить упущенные истории. Такое описание называется персоной или личностью (persona).

Существует несколько способов выявить, смоделировать роли пользователей.

Способ 1. Реальные пользователи

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

Идеально, если представители разных категорий пользователей входят в команду заказчика. Чаще всего это называется рабочей группой, и очень многое зависит от того, как она была сформирована. Здесь кроется опасность упустить некоторых пользователей, поэтому для охвата всех групп стоит прибегать и к моделированию.

Способ 2. Мозговой штурм

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

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

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

В ходе мозгового штурма были сгенерированы следующие роли, которые расположили по близости и пересечению:

После обсуждения каждой роли было принято решение оставить следующие (розовые стикеры):

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

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

Пример — описание роли «Мама»:

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

Способ 3. Сегментирование

Лично мне нравится другой способ моделирования ролей – от целевой аудитории. В данном случае также можно (даже рекомендуется) использовать мозговой штурм, но не сразу для названия ролей, а для определения критериев по разделению ЦА.

Способ рассмотрим так же на примере определения пользователей приложения для планирования домашних дел.

Изначально необходимо определить целевую аудиторию (в нашем примере – люди, которые делят обязанности по ведению хозяйства), само описание может немного меняться в ходе исследования, так как можно находить новые, неучтенные изначально, сегменты ЦА.

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

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

После этого с помощью критериев необходимо определить категории целевой аудитории, и для каждой категории задать название или сразу описать персону. То есть необходимо придумать роль, человека, который сочетает в себе разные значения критериев для разделения ЦА. Например, член семьи, который распределяет и контролирует обязанности по дому – мать Анжела. Сосед в съемной квартире или общежитии, который заинтересован в понимании, кто когда что делает по дому – Санёк. Человек, который не заинтересован в наведении порядка, но вынужден что-то делать по дому – подросток Володька.

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

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

Можно заметить, что в ходе такого способа моделирования был найден неучтенный ранее пользователь – хозяин фермы с наемными работниками (во время мозгового штурма по придумыванию ролей он не пришел никому в голову, а вот критерий размера дома помог сформулировать и такую роль).

Способ 4. Экстремальные персонажи

Что еще? Еще есть дополнительная методика – использование экстремальных персонажей (extreme characters). Вместо проектирования продукта для типичного пользователя предлагается подумать о пользователях с неординарными личностными качествами. Так, при проектировании персонального цифрового помощника предлагается подумать не о бизнес-консультанте в костюме, а о наркоторговце и о папе римском. Это может помочь нащупать новые полезные фичи, но не факт, что их целесообразно будет включать в продукт. Во всяком случае, это интересный инструмент развития креативности.

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

Разработка карты пользовательских историй

1. Goal→Activity/Feature→Task/Epic→User Story
2. User→Goal→Journey→Activity→Story
3. NFR(non-functional requirement)→Requirement→Story

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

Я созванивалась с ИТ-директором заказчика, и он мне рассказал свою грустную историю своё видение нового направления деятельности его предприятия. В рамках этого направления: каталог товаров выгружается на сайт, довольные клиенты заказывают эти товары на сайте (за рамками системы), заказы с сайта загружаются в учётную систему. После этого ответственный работник изучает хватает ли на предприятии товаров под этот заказ и обеспечивает его товарами (с центрального склада и магазинов). Когда товары приезжают, кладовщик группирует их под каждый заказ. Когда приезжает машина службы доставки, кладовщик печатает этикетки и сопроводительные документы и передаёт заказы службе доставки. По мере доставки товаров клиентам, учётная система службы доставки меняет статусы заказов и товаров, система получая эти статусы либо фиксирует факт продажи, либо формирует возврат товаров. После того, как цикл доставки завершён, служба доставки присылает информацию об оплате с разбивкой по каждому заказу — и в системе должны сформироваться документы по корректировке задолженности. По ходу общения я составляла карту активностей в рамках UF «Ecom», и вот что получилось:

Я продолжила разговор. В результате мы выяснили, что UA195 и UA196 — это типовой функционал модуля обмена с сайтом, про него пока думать не нужно, будем считать, что он заработает «из коробки». По поводу UA279 мне сказали, что здесь достаточно будет построить отчёт с информацией о наличии товаров из заказа на всех складах предприятия, заказы на перемещение и сами перемещения менеджер и кладовщик будут формировать вручную. UA286 подразумевает, что когда товары будут перемещены на склад электронной коммерции, то они должны автоматически зарезервироваться под соответствующие заказы, без необходимости заходить в каждый из них. UA289 оказался проще, чем казался: заказчик не хотел, чтобы сборка под заказ проходила через сканирование штрихкодов, поскольку товары и так сканировали при приёмке на склад, соответственно, достаточно просто указать в заказе признак его собранности. Конечно, по мере роста количества заказов — всё может поменяться, но пока так. Кроме того, по факту сбора товаров необходимо распечатать и наклеить этикетки и сборочные листы по шаблону службы доставки, а также ТОРГ-12 или УПД. В рамках UA296 необходимо под каждый заказ, передаваемый службе доставки, сформировать пакет документов учётной системы, так, чтобы можно было учитывать какие товары сейчас находятся у службы доставки. Кроме того, необходимо распечатать ТТН по всем заказам, которые передаются водителю. UA303 подразумевает, что у службы доставки есть API (веб-сервис) и нужно организовать его периодический опрос с целью уточнения состояния доставки наших товары. Если товары отгружены клиенту, то необходимо сформировать документ отгрузки. Если клиент отказался от товаров, то надо отработать возврат товаров на склад хранения. И вот получилась такая карта пользовательских историй:

Истории пользователей в средах Agile/Scrum

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

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

В отличие от Элемента Бэклога Продукта (PBI), пользовательская история описывает больше, чем просто конкретное требование, изменение или исправление ошибки.

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

Определение готовности (DoD)

Определение готовности (Definition of Done, DoD) — это список требований, которым должна соответствовать пользовательская история или инкремент, чтобы команда могла считать его завершенным.

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

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

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

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

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

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

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

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

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

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

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

1. Проанализируйте бизнес-требования
2. Разработайте UAT план
3. Определите тестовые сценарии и кейсы
4. Подготовьте тестовые данные
5. Проведите тест
6. Подтвердите достижение бизнес-целей

Кто проводит приемочное тестирование?

Приемочное тестирование проводится заказчиками, клиентами заказчика, тестировщиками из организации, бизнес-аналитиками и экспертами в предметной области.

Искусство написания гибких пользовательских историй

8 мая 2022 г.

Когда выполняется приемочное тестирование?

Приемочное тестирование – четвертый уровень тестирования и выполняется в следующих условиях

• Выполняется после завершения тестирования системы
• Выполняется перед предоставлением продукта для фактического использования

Атрибуты критериев приемки

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

• Правильность и полнота функциональности
• Целостность и преобразование данных
• Конфиденциальность и доступность
• Установка и возможность обновления
• Удобство использования
• Производительность
• Масштабируемость
• Документация
• Своевременность

Вынесение шагов второго уровня в экспортные сценарии

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

Итак, что я делала для того, чтобы избавиться от шагов второго уровня. Первый вариант был таким: оставить в сценарии только шаги первого уровня, сгенерировать epf с определениями шагов, а потом шаги второго уровня перенести в обработчики шагов  с обрамлением вида Ванесса.Шаг(«И я нажимаю на кнопку ‘Записать’ «).

Этот вариант имеет право на существование. Но я вижу такие минусы: для редактирования, при необходимости, шаги второго уровня, нужно заходить в Конфигуратор (а мне ох как не хочется), связь шага в фиче с его определением не очевидна и не интерактивна, дополнительные усилия по обрамлению шагов (особенно это чувствуется, когда шаг с параметрами в виде таблицы), и самое неприятное — при таком подходе шаги второго уровня в отчёте Allure никак не будут фигурировать (то есть если будет ошибка — то нужно будет снова таки открывать Конфигуратор, и смотреть на каком же шаге упало выполнение). Но если вы больше программист, чем аналитик, возможно такой вариант вам подойдёт — и вы настроите сборку epf с определениями шагов, а редактировать будете исходники в VSC с плагином BSL.

Дальше совсем техника — в VBParams нужно дополнить список тегов-исключений тегом ExportScenarios. Запускаете прогон сценариев и проверяете в Allure, что всё выполнилось корректно, экспортные сценарии подхватились в бизнес-фичах, и можно переходить к следующему этапу.

Что дальше

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

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

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

Документы, необходимые для приемного тестирования

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

Приемное тестирование требует несколько рабочих документов:

• План приемных испытаний – то есть список проводимых тестов. Он составляется еще на этап разработки при формировании архитектуры проекта 
• Формат UAT – описание с требованиями тестирования – предмет тестирования и сценарии тестирования, с учетом требований
• Реестр комментариев к процессу тестирования 

Существуют разные подходы к приемному тестированию. Чек-лист с наиболее частыми формами проверки проекта выглядят следующим образом:

1. Альфа-бета тестирование – задействование группы реальных пользователей.
2. Контрактное тестирование – проверка соответствия продукта ТЗ.
3. Операционное тестирование – вариант тестирования, при котором анализируются процессы, необходимые для функционирования продукта. Это могут быть, например, системы защиты, различные сервисы для резервного копирования и восстановления информации и др.
4. Законодательное тестирование – определяет насколько программный продукт соответствует действующему законодательству. Особое внимание уделяется в том случае, если проект имеет отношение к финансовой деятельности или сфере здравоохранения.

3C пользовательских историй

Пользовательская история Agile состоит из трех основных компонентов, каждый из которых начинается с буквы «C», отсюда и «3C»:

• Карта

• Беседа

• Подтверждение

«Карточка» относится к написанному тексту пользовательской истории и служит приглашением к разговору.

Наиболее распространенный формат пользовательской истории «Карточка»:

Как (n) <тип пользователя>, я хочу <функцию>, чтобы я мог <выгода>

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