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

# Описание

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

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

# Почему ветка важна?

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

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

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

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

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

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

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

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

# Что будет, если её не делать?

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

# На кого может быть делегирована?

Аналитики, тестировщики

# Примеры поведения

# Примеры плохого поведения

Замкнутый круг «У тестировщиков много работы, потому что требования низкого качества → У тестировщиков нет времени на тестирование требований → У тестировщиков много работы, потому что требования низкого качества»
Новые требования не фиксируются в общем документе, а остаются на словах или в переписках

# Примеры хорошего поведения

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

# Способы прокачки

# Практика

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

Опирайтесь на критерии качества требований и выбирайте из них те, которые важны для вашего проекта. Наталья Желнова в статье Нефункциональные требования к программному обеспечению.Часть 1 приводит основные характеристики хороших требований:

Полнота
Однозначность
Корректность
Непротиворечивость
Необходимость
Осуществимость
Проверяемость

Полный список критериев качества требований можно посмотреть в IEEE Std 830-1998.

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

Проверьте каждый объект по CRUDL (Create, Read, Update, Delete (или Deactivate), List)
Подумайте о том, что может пойти не так, какие негативные сценарии и граничные условия могут быть. Хорошая техника — составление сценариев использования
Проверьте, что в сложных условиях «если — то», описаны все варианты. Хорошей помощью может быть таблица решений
Подумайте о заинтересованных лицах — не забыли ли учесть чьи-то интересы, например спросить техподдержку
Проверьте, что нет отсылок на неопределённую информацию. Если в требованиях автор пишет «Спроси об этом Машу», то когда дойдёт дело до разработки Маша может быть недоступна

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

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

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

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

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

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

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

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

Чтобы проверить требования на проверяемость можно разработать набор тестов. Это может быть программа приёмо-сдаточных испытаний, автотесты в TDD, набор тест-кейсов и т. д.