Пользовательские истории (User stories)

Пользовательская история (user story): Высокоуровневое пользовательское или бизнес-требование, обычно использующееся в гибких методологиях разработки программного обеспечения. Обычно состоит из одного или нескольких предложений на разговорном или формальном языке, описывающих функциональность, необходимую пользователю, любые нефункциональные требования и включающих в себя критерии приемки. (ISTQB)

В индустрии разработки ПО слово «требование» определяет нашу цель, что именно нужно клиентам и что заставит нашу компанию развивать свой бизнес. Будь то продуктовая компания, которая производит программные продукты, или сервисная компания, которая предлагает услуги в различных областях программного обеспечения, основной базой для всех из них является требование, а успех определяется тем, насколько хорошо эти требования выполняются. Термин «требование» имеет разные названия в разных методологиях проекта. В Waterfall это называется Requirement/Specification Document, в Agile или SCRUM требования документируются в виде «Epic» и «User Story». В модели Waterfall документы с требованиями представляют собой огромные документы на сотни страниц, поскольку весь продукт реализуется за один этап. Но это не относится к Agile / SCRUM, потому что в этих случаях требования предъявляются к небольшим функциям или фичам, поскольку продукт готовится поэтапно.

Пользовательская история определяет требования к любой функциональности или фиче, в то время как критерии приемки (Acceptance Criteria) определяют критерии готовности (Definition of done) для пользовательской истории или требования.

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

Формат:

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

Например, “Как пользователь WhatsApp, я хочу, чтобы значок камеры в поле ввода чата позволял захватывать и отправлять изображения, чтобы я мог щелкнуть и поделиться своими фотографиями одновременно со всеми своими друзьями. ”

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

Job Stories

В целом Job Stories — схожая с US техника. Можно назвать их приёмом-субститутом, ведь обычно они не используются вместе и выполняют максимально похожую функцию. Job Stories представляют требование в виде действия, которое выполняет пользователь. Они не описывают саму функцию, а лишь концентрируют внимание команды на потребности. Job Stories концентрируются на психологической части фичи, на эмоциях, тревогах и прочем, что может возникнуть во время использования функции.

“Тело” JS делится на три части:

● Situation: дает контекст обо всей JS, который помогает dev-команде придумать возможное решение;

● Motivation: описывает невидимую руку, которая ведет юзера к использованию данной функции;

● Expected Outcome: описывает, что получит юзер после использования функции.

Job Stories могут писаться по двум форматам:

● В одну строку: When X I want to Y so I can Z" или "When X, actor is Y so that Z;

● В три строки:

○ When X

○ I want to Y

○ So I can Z.

Пример: When I want to withdraw money from my bank account, I want to know I have enough money in my account to withdraw some now so that I can go out to dinner with my friends.

Источники:

● What Is User Story And Acceptance Criteria (Examples)

● Гайд по User Stories

Доп. материал:

● 10 советов для написания хороших пользовательских историй

● Гайд по Job Stories в помощь к написанию user stories

● Юзер-стори идеальная, а багов 100500? Как мы тестируем документацию

● Job Stories Offer a Viable Alternative to User Stories

● 25 sample user stories

● User Stories

Критерии приемки (Acceptance Criteria)

Критерии приемки (acceptance criteria): Критерии выхода, которым должны соответствовать компонент или система, для того, чтобы быть принятыми пользователем, заказчиком или другим уполномоченным лицом. (IEEE 610)

Критерии приемки - это условия, которым должен удовлетворять программный продукт, чтобы быть принятым пользователем, заказчиком или, в случае функциональности системного уровня, потребляющей системой. Проще говоря - это список деталей (также известных как требования) о том, как новая функция (feature) программного обеспечения должна работать / выглядеть. Это гарантирует, что:

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

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

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

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

Формат / макет / шаблон критериев приемки (Acceptance Criteria Format/Layout/Template): существует два основных типа критериев приемки, основанные на сценариях и правилах:

● Критерии приемлемости, основанные на сценариях (Scenario-based acceptance criteria), используют шаблон для подробного описания конкретного поведения / последовательности действий пользователя;

● Критерии приемлемости на основе правил (Rule-based acceptance criteria) - это скорее простой список того, как функция должна выглядеть / работать;

Scenario-based acceptance criteria соответствует формату “Дано/Когда/Тогда” (“Given/When/Then”) (основан на BDD - behavior driven development):

● Given / какой-то аспект, связанный с поведением пользователя /

● When / пользователь выполняет определенное действие /

● Then / происходит определенный результат /

Между ними в случае нескольких условий можно добавлять “И” (“AND”).

Rule-Based Acceptance Criteria - это простой список «правил» о том, как функция должна выглядеть / работать:

● Все кнопки должны быть определенного цвета;

● Кнопка входа должна перенаправлять пользователя в определенный раздел;

● Кнопка регистрации должна находиться в определенной области;

● Все кнопки должны быть серыми, если не выполняются определенные требования;

● и многое другое;

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

Кто пишет критерии приемки? Обычно в создании критериев приемки участвуют несколько человек или команд. Тем не менее, это в первую очередь делает product manager (или “product owner”). Разработчики несут ответственность за обеспечение функциональности функции, а QA - за подтверждение ее удобства использования. Но критерии приемки создаются человеком или командой, ответственной за решение, какие новые функции добавить в продукт (независимо от типа приложения или веб-сайта).

Большая часть Agile включает внесение изменений по мере развития проекта. Так могут ли критерии приемки измениться в середине спринта? Ответ: «Это зависит от обстоятельств». Если спринт начался, но разработчики еще не завершили эту функцию, можно изменить требования. Но важно всегда сначала согласовывать с разработчиками и держать других (например, QA) в курсе. Тестировщики могли написать test cases, которые больше не актуальны после изменений. Кроме того, новый объем работы может оказаться слишком большим, чтобы разработчики могли завершить его вовремя.

User Stories vs Acceptance Criteria: пользовательские истории и критерии приемки идут рука об руку. Пользовательская история описывает основную цель новой функции - обзор того, как она поможет пользователям. Критерии приемки перечисляют способы работы функции с технической точки зрения. Обычно в тикетах (например, в Jira или Trello) вверху указывается пользовательская история, за которой следуют критерии приемки

Definition of Done: чтобы заявка (или функция) считалась «выполненной», все критерии должны работать. Например, предположим, что пользовательская история была: “Как пользователь, я хочу иметь возможность войти в систему, чтобы получить доступ к панели управления моей учетной записи”. Как уже упоминалось, пользователь может войти в систему, чтобы получить доступ к панели управления своей учетной записи. Но тикет не считался бы «done», если бы он также содержал следующие критерии приемки: “Кнопка входа должна быть бирюзовой”, а фактически кнопка входа была бы, например, желтой. Иногда команда решает запустить функцию даже с незначительными несоответствиями. Таким образом, они могут пометить тикет как выполненный (или создать отдельный для решения оставшихся аспектов), даже если не все критерии работают. Но с точки зрения технического определения, это не «готово», пока не пройдут все критерии приемки.

Источник: What is Acceptance Criteria?

Виды отчетов (Reports)

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

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

Ниже перечислены наиболее известные варианты отчетов в тестировании.