Работа QA-инженера с требованиями

Я хочу показать, почему работа с требованиями является важным элементом контроля качества на любом проекте; какие бывают разновидности требований; какую пользу QA может оказать при работе с требованиями и показать некоторое количество best practices.

Важность требований для разработки

Почему важна работа с требованиями (как объяснить заказчику)?

1. Исследования 1995–1996 международной организации Standish Group показали причины провала проектов. Звездочками отмечены те из них, которые связаны с требованиями (6 из 9).
2. Согласно исследованиям от Davis (2005) 40–50% дефектов (багов) связаны с недостаточной проработкой требований на этапе разработки требований.
3. Многие эксперты считают, что 30–50% от бюджета разработки уходит на переделку уже готового. Эти затраты можно сократить при правильной работе с требованиями.
4. Требования позволяют обеспечить основу для оценки стоимости и сроков.
5. И самый важный тезис: дешевле всего исправление ошибок на стадии составления требований. Чем позже замечен баг, тем существенней затраты на его исправление!

А также:

1. Разработчику проще вникнуть в задачу и меньше времени уйдет на коммуникацию с аналитиком и тестировщиком;
2. Тестировщику проще будет составлять тестовую документацию и меньше времени уйдет на коммуникацию с аналитиком и разработчиком;
3. Сокращается вероятность разного понимания требований членами команды.

Определение понятия «требования»

Есть много определений требований.

Более формальное (ISO):

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

Менее формальное:

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

Важно изначально согласовать что будет считаться требованиями и в каком виде они будут фиксироваться.

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

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

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

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

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

Виды требований

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

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

Бизнес требования — это самый высокий уровень. В них содержатся ключевые цели, почему заказана данная система. Например — требуется сократить на 25% затраты на оплату кассиров на вокзале и сокращение очередей. Идея — установить терминал, продающий билеты. Результатом этих требований должен является документ концепции и границ.

Пользовательские требования — это то, что пользователь должен иметь возможность делать с системой. Их можно сформулировать в виде пользовательских историй (user story), таблиц событие-отклик, и т.д. Результатом станет документ пользовательских требований.

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

Системные требования — в первую очередь это требования к ПО, подсистемы, оборудование рабочего места. Например, оборудованное место сотрудника современного склада включает в себя сканер штрих-кода, клавиатуру, монитор.

Нефункциональные требования описывают насколько хорошо система что-то делает и включают в себя:

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

Атрибуты качества — под ними подразумевается например, производительность, UI/UX, и т д.

Атрибуты хороших требований

Ниже перечислены атрибуты которыми должны обладать хорошо прописанные требования с кратким обзором (взято из стандарта IEEE-Std-830–1998). Чем большим количеством этих атрибутов обладает спецификация тем лучше.

1. Корректность — точное описание разрабатываемого функционала.
2. Недвусмысленность — требование должно содержать однозначные формулировки.. Желательно после написания оценка требований третьей стороной, чтобы проверить, что избежали противоречивости и двузначных толкований (т.н. «ловушка естественного языка»).
3. Полнота — в требовании должна содержаться вся необходимая для реализации функциональности информация. Необходимо предусмотреть ответы на все возможные и невозможные входные значения.
4. Целостность — требование должно содержать однозначные формулировки. требование не должно содержать внутренних противоречий и противоречий другим требованиям и документам. Например, недопустимо, что какая-то сущность называется по-разному в двух местах. Или логические несоответствия. Важно использование стандартной терминологии.
5. Приоритетность — у каждого требования должен быть приоритет (количественная оценка степени значимости требования). Этот атрибут позволит грамотно управлять ресурсами на проекте. В некоторых случаях можно делить требования на обязательные, желательные и необязательные. Тогда система может быть верифицируема без выполнения части требований.
6. Проверяемость — формулировка требований таким образом, чтобы можно было выставить однозначный вердикт, выполнено все в соответствии с требованиями или нет. QA особенно важно работать над этой частью. Если QA будет строить процесс тестирования параллельно работе над требованиями он может повлиять на этот атрибут.
7. Модифицируемость — в каждое требование можно внести изменение. Для этого каждое требование не должно быть связано с множеством других и должна иметься систематизация и оглавление.
8. Прослеживаемость — каждое требование должно иметь уникальный идентификатор, по которому на него можно сослаться. Различают обратную трассируемость (по которой можно отличить изменение требования) и прямую — когда требования имеют перекрестные ссылки по идентификаторам.

Процесс документирования требований и роль QA

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

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

Ниже несколько принципов, которые помогут улучшить этот процесс.

Пишите просто

Есть хороший принцип из учебника по UX: «Не заставляйте меня думать». Тот кто читает требования должен напрягаться по минимуму.

• Используйте простой слог и слова, избегайте общих формулировок.
• Избегайте сложносочиненных предложений. В идеале, одно предложение = одна мысль.
• Не используйте двойные отрицания.
• Если вы встречаете союзы «но», «или», то, скорее всего, здесь скрыты два отдельных требования. Пример: «Должна быть возможность удалить конкретный товар или сразу все товары из корзины». — это два требования, а не одно. Лучше их разделить.
• Для требований со структурой «если <условие>, то <результат>» пишите сначала результат, а потом — условие. Пример: «Система должна запрещать сохранение заказа, если хотя бы одного товара нет в наличии».
• Нужно детализировать требования, но умеренно. Детализация должна позволять видеть требования в нужном контексте.

Используйте шаблоны

Хороший подход для базового описания требования это шаблон. Разные формулировки в одном документе ухудшают восприятие.

Вот пример хорошего шаблона:

<Тип заинтересованной стороны> должен быть способен: <описание возможности>.

Пример: Пользователь должен быть способен отменить заказ.

или расширенный:

<Тип заинтересованной стороны> должен быть способен: <описание возможности> в пределах <характеристика> приb> <событие> при <условие эксплуатации>.

Если требование-ограничение:

<Тип заинтересованной стороны> не должен попадать в ситуацию, вынуждающую нарушать <действующее правило>.

Водитель не должен попадать в ситуацию, вынуждающую нарушать ПДД.

Также бывают шаблоны для требований к системе:

<Система> должна <описание функции> не менее чем <количество><объект> при <условии эксплуатации>.

Пример: Система связи должна поддерживать телефонные соединения не менее чем 10 абонентов при отсутствии внешнего электропитания.

Используйте форматирование

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

• Списки;
• Абзацы;
• Полужирный шрифт;
• Если используете союз «и» или несколько таких союзов, то лучше каждый писать в отдельной строке.

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

Давайте упростим восприятие этого требования. Получим следующее:

«Необходимо перевести заказ в статус «Доставляется», если:

• Заказ оплачен
• И весь товар есть в наличии на складе.

Что мы сделали? Мы сняли часть когнитивной нагрузки с того, кто будет изучать данное требование. Уже из форматирования становится видно, что:

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

Упрощайте требования

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

Чем короче требование тем больше шансов, что его прочитают.

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

Как можно его упростить:

«Заказ отображается в личном кабинете пользователя, если его статус не равен «Доставлен».

Используйте таблицы

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

Используйте схемы

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

Правила разработки диаграмм:

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

Схема бизнес-процессов (BPMN-диаграмма) и диаграмма состояний тоже хорошие инструменты для этой цели.

Мы часто используем в работе CJM и USM. Это очень эффективные инструменты, которые можно иногда использовать даже вместо чек-листов.

Тестирование требований

Тестирование требований — это их проверка, чтобы найти ошибки до начала разработки.

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

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

Почему важно тестирование требований для тестировщика:

• Возможность влиять на проект в самом начале. Часто тестировщики знают, как продукт работает на самом деле и какие есть подводные камни
• Меньше багов на этапе тестирования продукта
• Понятнее, что должно получиться и как это проверять. Следовательно, проще разрабатывать план тестирования и тестовую документацию

Почему важно тестирование требований для других участников проекта:

• Качественные требования, из которых понятно, что нужно сделать
• Меньше новых требований, которые появляются уже после разработки. И меньше усилий, чтобы вписать их в систему
• Дополнительная информация о краевых случаях и рисках
• Увеличивается скорость разработки — меньше одинаковых вопросов к автору требований, меньше переделок после разработки
• Выше качество продукта — некоторые ошибки требований очень дорого или невозможно исправить после разработки.

Какие риски несет в себе отсутствие тестирования требований:

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

Best practices при тестировании требований:

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

Best Practices

Тут собраны несколько советов при работе с требованиями.

Осуществимость требований

Очень важно перед началом работы оценить осуществимость требований.

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

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

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

Для наглядного примера такой ситуации можно посмотреть смешное видео.

Метод 3 Amigo

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

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

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

«Амигосов» необязательно три. Если нужно больше, не проблема.

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

За встречу лучше прорабатывать небольшую пользовательскую историю — из примерно 10 acceptance criteria.

В результате получаем следующее:

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

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

Фиксация требований

Очень важный вопрос касается фиксации требований.

Для финального утверждения желательно заручится следующими подтверждениями:

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

Часто просят поставить свою подпись какое-то заинтересованное лицо. Проблема в том, что тот кто ставит финальную подпись часто не имеет возможности тщательно читать их или понимать. Вы услышите от него следующую фразу если возникнут проблемы и расхождения: «Ну да, я подписал эти требования, но у меня не было времени их читать. Я доверял вам, ребята, а вы меня подвели!»

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

Требования на середине итерации

Очень часто в средине итерации заказчик может принести новые требования. Это абсолютно нормально при работе по Agile, но есть одна проблема.

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

Александр Орлов (тренер из школы менеджеров и тимлидов) рекомендует так подходить к подобной ситуации: согласовать с заказчиками, чтобы несрочные и не отменяющие текущей разработки требования копились и появлялись в начале следующей итерации (спринта). За редкими исключениями, решения о которых должен принимать Product Owner, все подобные требования вполне могут подождать 1–2 недели.

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

Требования бантики, Pet-Features и ложные требования

Поговорим о «плохих требованиях».

Есть такое понятие: требования-«бантики», украшательство ~ gold plating — не являющаяся необходимой или избыточно сложная функциональность, запланированная и разработанная для продукта, иногда без одобрения клиента.

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

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

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

Решение проблемы — Impact Mapping. Практика, которую мы активно используем и продвигаем. С помощью нее мы прокладываем путь от решений до цели, расставляем приоритеты, отсекаем Pet Feature, которые идут со стороны бизнеса и со стороны команды, убираем требования бантики и отчищаем от ложных требований.

Полезные ссылки

1. Статья Ольги Назиной чек-лист тестирования требований
2. Тестирование требований из Teamlead Roadmap
3. IEEE-Std-830–1998-RU Рекомендации IEEE по разработке требований к программному обеспечению
4. Статья 3 Amigo — техника работы над требованиями.