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

В работе по уточнению критериев приемки нам помогает Triforce.

Что такое Triforce?

Triforce — это встречи, на которых мы создаем и оттачиваем пользовательские истории, с целью обеспечить общее и полное понимание того, что должно быть создано. Возможно, вы сталкивались с ними под названием Three Amigos или Power of Three; я называю их Triforce, потому что 1) нет привязки к гендеру и 2) звучит забавно. Triforce предполагает совместную работу членов проектной команды из разных подразделений, каждый из которых отстаивает свою точку зрения: Бизнес, Разработка и Тестирование.

• Бизнес — определяет контекст требований и потребностей пользователей (например, владелец продукта / разработчики продукта).

• Разработка — предоставляет информацию о деталях реализации и возможностях.

• Тестирование — обеспечивает тестируемость и готовность тикетов к разработке; гарантирует, что все требования учтены.

Приставка Tri относится не к количеству людей на сессии, а к количеству перспектив (или «шляп»), которые должны быть на этой встрече представлены. Учитывая, что в сессии могут участвовать люди с разным объемом знаний о домене или опытом работы с фронтендом/бэкендом, вполне вероятно, что эти точки зрения могут представлять несколько человек.

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

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

Зачем дорабатывать критерии приемки?

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

1. Расширение объема работ из-за неполного понимания, что мы строим и как далеко нужно зайти.

2. Создание не того, что нужно, из-за неправильной интерпретации запроса.

3. Замедление скорости работы команды из-за недостатка информации для начала работы.

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

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

6. Тестирование не тех частей, из-за чего нет понимания, правильно ли мы все сделали или же нет.

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

Написание качественных критериев приемки

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

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

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

1. Какие требования были у пользователя, как мы их выполняем?

2. Какие нефункциональные требования или соглашения у нас есть?

3. Можем ли мы это выполнить в ближайшем спринте?

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

Каждый критерий должен быть независимо тестируемым.

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

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

Используйте короткие утверждения, которые покрывают один момент, например:

1. Показывает текущую оценку студента.

2. Предоставляет возможность печати.

3. Предоставляет возможность совместного использования.

4. Выводит сообщение об ошибке, если сервис не отвечает.

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

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

Критерии приемки должны иметь четкий результат «прошел/не прошел».

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

Используйте что-то конкретное и измеримое, например:

1. Отображение баланса в выписке при аутентификации.

2. Отображение общего баланса в рублях.

3. Отображение даты платежа, подлежащего оплате в формате ДД/ММ/ГГГГ.

Вместо чего-то общего и неконкретного:

1. Взаимодействие с эндпоинтом сервиса отображения баланса для возврата данных.

2. Страница доступна и удобна в использовании.

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

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

Используйте «что» в поведении:

1. Пользователь должен иметь возможность ввести заголовок.

         1.1 Пользователь может вводить название с помощью символов A-z, 0-9 и специальных символов.

2. Пользователь должен иметь возможность ввести описание.

Как реализовать:

1. На экране под заголовком главной страницы располагается текстовое поле с заголовком "title".

2. Под полем заголовка располагается текстовое поле с названием «описание».

3. Под этим полем отображается горизонтальная линия.

Критерии приемки должны включать нефункциональные критерии (где это применимо).

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

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

Используйте конкретные и тестируемые нефункциональные требования:

1. Система должна отвечать на все поисковые запросы в течение 10 секунд после получения запроса.

2. Система должна быть способна обслуживать одновременно 50 пользователей, которые создают, редактируют и просматривают информацию.

3. Страница должна соответствовать минимальному стандарту WCAG 2.1 AA по доступности всех полей и элементов управления.

Критерии приемки должны покрывать идеальные (happy), негативные (negative) и пограничные (edge) случаи.

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

1. Что произойдет, если сеть выйдет из строя?

2. Что произойдет в случае ошибки?

3. Пользовательский параллелизм: что произойдет, если другой пользователь отредактирует или просмотрит то же самое, что и другой?

4. Существуют ли ограничения или границы для вводимых данных?

5. Существуют ли какие-либо логические ограничения функциональности (может ли все сопоставляться со всем?).

6. Обратитесь к другим фичам и функциональности, чтобы мыслить целостно.

Критерии приемки должны быть четко сформулированы.

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

Как я участвую в Triforce сессии

В качестве тестировщика на сессии Triforce я привношу идеи, связанные с качеством. Моя роль заключается в том, чтобы попытаться дополнить тикет критериями приемки, которые позволят нам исправить баги еще до того, как они возникнут — путем покрытия крайних и негативных случаев. Я также помогаю направлять понимание, задавая уточняющие вопросы, чтобы выяснить «что» в пользовательской истории.

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

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

3. Убедитесь, что рассматриваемая часть поддается тестированию, задавая вопрос: «Как мы узнаем, что это сделано?»

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

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

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