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

Какие бывают типы требований:

Функциональные - Функциональные требования описывают поведение системы в режиме ее работы (описание невозможности работы без авторизации, валидация EMAIL и тд).

Например: "Пользователь должен иметь возможность войти в систему, используя свое имя пользователя и пароль."

В этом примере функция — «вход», а поведение — «Система должна позволять пользователю входить в систему, используя свое имя пользователя и пароль».

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

Плюсы тестирования требований:

1. Для тестировщика:

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

2. Для разработчика:

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

3. Для автора требований:

• Обратная связь сразу, пока он ещё в контексте задачи
• Дополнительная информация о краевых случаях и рисках
• Меньше одинаковых вопросов

4. Для менеджера:

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

Возможные риски, если не тестировать требования:

• Проблемы в требованиях найдут уже тестировщики или пользователи. Чинить такие проблемы может быть дорого, а иногда и невозможно
• Разработчики будут тратить больше времени, пытаясь прояснить детали
• Разработчикам придётся выкручиваться и придумывать костыли, чтобы вписать пропущенные требования в систему

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

Характеристики качественных требований отмечены на схеме:

Полнота

Требование является полным и законченным с точки зрения представления в нём всей необходимой информации, ничто не пропущено по соображениям «это и так всем понятно».

Автор требований не всегда описывает все необходимое для разработки (например негативные сценарии). Для проверки на полноту требований:

• Проверьте каждый объект по CRUDL (Create, Read, Update, Delete (или Deactivate), List).
• Подумайте о том, что может пойти не так, какие негативные сценарии и граничные условия могут быть. Хорошая техника — составление сценариев использования. Часто в документации попадаются условия, для которых не прописана реакция системы в случае негативных сценариев.

• Проверьте, что в сложных условиях «если — то», «и/или/не» описаны все варианты. Хорошей помощью может быть таблица решений. В текстовом виде просто упустить какие-либо условия. Лучше, если все требования со сложной логикой описываются в виде блок-схем или таблиц.

• Подумайте о заинтересованных лицах — не забыли ли учесть чьи-то интересы, например спросить техподдержку.
• Проверьте, что нет отсылок на неопределённую информацию. Если в требованиях автор пишет «Спроси об этом Машу», то когда дойдёт дело до разработки Маша может быть недоступна.

Непротиворечивость

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

При проверке непротиворечивости, обратите внимание на:

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

Однозначность

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

Все участники команды должны понимать требования однозначно. Если у кого-то возникают вопросы — то они могут появиться и у других членов команды. Все, что может быть понятно неправильно, будет понятно неправильно. Обратите внимание на:

• Терминологию — вся команда должна понимать, что стоит за каждым понятием. Одни и те же вещи должны называться одним и тем же понятием.
  
• Качественные определения — «красиво», «удобно», «быстро». Такие требования надо заменять конкретными параметрами, чтобы все понимали как его проверить
• То, что требования написаны простым языком — понятно «кто что делает». Если читателю приходится разбираться со всей мощью русского языка, то сложно понять, что надо сделать. Например, “покупатель”, “оформить”, “купить”, “подписать”, “согласовать”, “директор” и другие слова, к которым мы привыкли в обыденной жизни и свойственные предметной области. Обращайте на них свое внимание и проверяйте на определенность термина.

Осуществимость

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

Необходимость

Необходимость требования — «а это требование точно нужно?». Это в большей степени работа менеджеров и аналитиков. Но человек, читающий требования, тоже может задать вопрос «Зачем мы это делаем?». Хорошо помогает формат user story.

Проверяемость

Как вы поймёте, что требование реализовано? Как вы поймёте, что проект в целом успешен? Если в требовании нет контрольного примера, либо вы сходу не можете придумать тест — это плохое требование.