Проведение Triforce встреч для определения критериев приемки

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

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

Что такое Triforce?

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

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

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

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

Приставка Tri относится не к количеству людей на сессии, а к количеству перспектив (или

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

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

Мы должны удостовериться, что история соответствует

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

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-инженеров, записаться можно бесплатно по ссылке.