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