Что такое требования к продукту?
Требование — это спецификация того, что должно быть реализовано. В нем описывается поведение и атрибуты системы.
Процесс определения требований имеет огромное значение в процессе разработки требований. Он представляет собой третий этап, следующий за сбором и анализом требований, которым управляют такие роли, как бизнес-аналитики, системные аналитики и дизайнеры продуктов, которые варьируются от проекта к проекту.
Цель состоит в том, чтобы создать документ c требованиями или спецификацию с соответствующей детализацией. Этот документ будет содержать все требования к дизайну, проверке и техническому обслуживанию продукта.
Требования - первое, на что обращает внимание команда проекта, это основа для проектирования и разработки продукта.
Требования служат краеугольным камнем, закладывающим основу для проектирования и разработки продукта. Любой недостаток или неточность в документации может проявиться в самый неподходящий момент. Стив Макконнелл в своей книге "Сколько стоит программный проект" указывает, что около 30 % ошибок вносится в продукт при разработке требований.
Очевидно, что гораздо проще и дешевле исправить дефект в паре строк требований, чем потом переделывать несколько сотен (или даже тысяч) строк кода.
Почему тестирование требований важно?
Тестирование требований - необходимая и очень важная процедура, которая помогает оптимизировать работу команды и избежать недопонимания, а также позволяет понять, могут ли эти требования быть выполнены с точки зрения времени, ресурсов и бюджета.
От качества сформированных требований зависит качество программного обеспечения. Требования формируют blueprient продукта. На их основе создаются тест-кейсы, выявляющие дефекты, когда продукт расходится с требованиями. Проблемы выявляют противоречия и приходится принимать действия по их устранению.
В связи с вышесказанным, при разработке программного обеспечения тестирование должно проводиться уже на этапе разработки спецификации. Тестирование требований направлено на устранение максимально возможного количества ошибок на начальных этапах проектирования системы. В долгосрочной перспективе это позволяет:
Установить взаимопонимание между членами команды при создании продукта.
Значительно снизить затраты на разработку и тестирование продукта.
Снизить риск получения продукта, который не соответствует ожиданиям заказчика или потребностям ��онечного пользователя.
Улучшить качество продукта.
Сократить время доставки готового продукта.
Что произойдет, если не проводить тестирование требований?
Возникнут трудности в процессе разработки.
Проблемы в требованиях будут обнаружены после разработки:
Тестировщиками на этапе тестирования.
Пользователями после выпуска продукта.
Устранение таких проблем может быть дорогостоящим, а иногда и невозможным.
Клиенты и конечные пользователи будут не удовлетворены реализованным продуктом.
Разработчики будут тратить больше времени на уточнение деталей и придумывание решений, чтобы вписать недостающие требования в систему.
Ключевые свойства хороших требований
У каждого проекта свои требования - в одних проектах это могут быть многостраничные документы, а в других - только пользовательские истории или минимальное описание того, что нужно сделать. Поэтому и требования к тестированию будут отличаться. Следовательно, опирайтесь на критерии качества требований и выбирайте то, что важно для вашего проекта.
Ключевыми характеристиками хороших требований являются:
Полнота. Все ли описано? Ничего ли не забыли? Что, если у нас все еще есть неописанный функционал или пользовательский сценарий? Документация должна предоставлять максимально четкую информацию о том, как должен работать каждый отдельный модуль и весь продукт в целом. После прочтения документации не должно оставаться вопросов, но на практике выявляется большое количество недостатков.
Корректность и согласованность. Все утверждения должны быть правильными, правдивыми и иметь смысл.
Последовательность. Требования не должны противоречить сами себе. Обычно это происходит, когда требований много. Аналитик просто забывает, что уже писал о параметре, и снова придумывает его поведение. Иногда он придумывает что-то немного другое.
Ясность. Требования должны быть прозрачными и понятными для всех, с возможностью только одной интерпретации.
Тестируемость. Можно ли п��отестировать эту функциональность? Подумайте об этом заранее. А бывает, что разработчик уже все сделал, и только тогда тестировщик понимает, что задачу никак нельзя проверить. Или можно проверить вручную, но нельзя написать автотесты, фреймворк под новую функциональность не заточен. Это может быть проблемой, если в компании все проверки автоматизируются.
Прослеживаемость. Требование полностью или частично соответствует потребностям бизнеса, заявленным заинтересованными сторонами, и это задокументировано.
Атомарность. Требование не может быть разделено на несколько более детальных требований без потери полноты.
Выполнимость. Требование может быть реализовано в рамках данного проекта.
Актуальность. Требование не устарело по прошествии времени.
Модифицируемость.
Упорядочены по важности, стабильности и срочности.
Основные принципы тестирования требований
Тестирование требований лучше всего проводить до начала разработки. Для этого нужно рассчитать необходимое время на проверку и «заморозить» тестируемую документацию до окончания проверки.
Каждый член команды может помочь в проведении тестирования требований. Однако для достижения наилучшего результата описание и проверка требований должны быть поручены разным людям. Например, во время sprint refinement.
Создание отчета о дефектах документации ничем не отличается от сообщения о дефектах продукта: об ошибках следует сообщать в систему отслеживания ошибок, как обычно.
В случае, когда проверка требований проводится параллельно с разработкой, крайне желательно предупреждать команду разработчиков о найденных дефектах (чтобы они могли вовремя исправить ошибку).
Уровень детализации требований (как и глубина тестирования) сильно зависит от уровня проекта. Нет смысла проверять время отклика на кнопку в проекте, который только начался (если, конечно, это не относится к ключевой функциональности).
Техники тестирования требований
Взаимный просмотр:
Беглый просмотр.
Технический просмотр.
Формальная инспекция.
Вопросы.
Написание тест-кейсов и чек листов.
Исследование поведения системы.
Рисунки (графическое представление).
Прототипирование.
Идеи тестирования требований
Полнота
Проверка полноты требований:
Проверьте каждый объект на соответствие требованиям CRUDL (Create, Read, Update, Delete (или Deactivate), List).
Подумайте, что может пойти не так, какими могут быть негативные сценарии и граничные условия (сценарии использования).
Проверьте, что в сложных условиях "если - то" описаны все варианты (таблица решений).
Корректность
Если требование корректно, значит, оно не содержит неверной и неточной информации. Этот критерий обычно сложно проверить. Помогает, если требования проверяет человек, хорошо разбирающийся в предметной области.
Согласованность
Проверяя согласованность, обратите внимание на:
Одно и то же требование написано несколько раз в разных местах - если вы его измените, то, скорее всего, где-то забудете.
Союз "и" в требованиях — это несколько разных требований, и они могут противоречить друг другу. Например, "быстро, хорошо и дешево".
Ясность
Все члены команды должны понимать требования однозначно:
Терминология - все должны понимать, что стоит за каждым понятием. Одни и те же вещи должны называться одним и тем же понятием.
Кач��ственные определения - "красиво", "удобно", "быстро". Такие требования должны быть заменены конкретными параметрами, чтобы все понимали, как их проверять.
Требования должны быть написаны простым языком – тогда понятно, "кто что делает".
Тестируемость/верифицируемость
Один из самых важных критериев - проверяемость. Как вы узнаете, что требование выполнено? Как вы узнаете, что проект в целом успешен? Если у требования нет тест-кейса или вы не можете сразу придумать тест, это плохое требование. Например, вы можете проверить пользовательскую историю:
Критерии приемки присутствуют в пользовательской истории.
Критерии приемки точны и недвусмысленны.
QA-инженер может написать чек лист или тест-кейсы для этой истории пользователя.
Выполняемость
Когда вы проверяете выполнимость требований, посмотрите, можно ли это вообще сделать в рамках существующих ограничений. Обычно QA-инженеры делают это вместе с разработчиками, поскольку вторые обладают более глубокой технической экспертизой.
