Этот день настал 🔥
Записывайтесь ✨
Будет всего 10 мест

Какими должны быть требования?

(Этот вопрос уже несколько раз попадался моим ученикам на собеседованиях)

Давайте разбираться вместе
👇👇👇

Ключевые концепции тестирования требований

Что такое требования к продукту?

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

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

Цель состоит в том, чтобы создать документ c требованиями или спецификацию с соответствующей детализацией.

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

Требования - первое, на что обращает внимание команда проекта, это основа для проектирования и разработки продукта.

Стив Макконнелл в своей книге "Сколько стоит программный проект" указывает, что около 30 % ошибок вносится в продукт при разработке требований.

Очевидно, что гораздо проще и дешевле исправить дефект в паре строк требований, чем потом переделывать несколько сотен (или даже тысяч) строк кода.

Почему тестирование требований важно?

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

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

Ключевыми характеристиками хороших требований являются:

*️⃣Полнота.
Все ли описано? Ничего ли не забыли? Что, если у нас все еще есть неописанный функционал или пользовательский сценарий? Документация должна предоставлять максимально четкую информацию о том, как должен работать каждый отдельный модуль и весь продукт в целом.


*️⃣Корректность и согласованность.
Все утверждения должны быть правильными, правдивыми и иметь смысл.

*️⃣Последовательность. Требования не должны противоречить сами себе. Обычно это происходит, когда требований много. Аналитик просто забывает, что уже писал о параметре, и снова придумывает его поведение. Иногда он придумывает что-то немного другое.

*️⃣Ясность.
Требования должны быть прозрачными и понятными для всех, с возможностью только одной интерпретации.

*️⃣Тестируемость.
Можно ли протестировать эту функциональность? Подумайте об этом заранее. А бывает, что разработчик уже все сделал, и только тогда тестировщик понимает, что задачу никак нельзя проверить. Или можно проверить вручную, но нельзя написать автотесты, фреймворк под новую функциональность не заточен. Это может быть проблемой, если в компании все проверки автоматизируются.

*️⃣Прослеживаемость. Требование полностью или частично соответствует потребностям бизнеса, заявленным заинтересованными сторонами, и это задокументировано.

*️⃣Атомарность. Требование не может быть разделено на несколько более детальных требований без потери полноты.

*️⃣Выполнимость. Требование может быть реализовано в рамках данного проекта.

*️⃣Актуальность.
Требование не устарело по прошествии времени.

*️⃣Модифицируемость.
Упорядочены по важности, стабильности и срочности.