В статье про тестирование по требованиям мы выяснили главное: требования — отправная точка всей работы, и их тоже нужно проверять. Теперь два инструмента, которые делают эту проверку системной: понимание уровней требований (чтобы знать, чего ожидать от каждого документа) и список свойств хорошего требования (чтобы проверять не «нравится / не нравится», а по критериям).

Три уровня требований

Требования пишутся для разных читателей и с разной степенью детализации. Обычно выделяют три уровня.

Бизнес-требования отвечают на вопрос «зачем вообще этот продукт». Их пишут языком бизнеса, без технических деталей: «нужно вдвое сократить время обработки заявки оператором», «нужен инструмент, который показывает выгодный курс валют в реальном времени». Здесь нет кнопок и полей — здесь цель и польза.

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

Продуктные требования — самый детальный уровень: как именно система себя ведёт. Здесь живут:

  • функциональные требования — что система делает: «адрес почты при регистрации проверяется на корректность формата»;
  • нефункциональные требования — какой система должна быть: скорость, надёжность, удобство. «При 1000 одновременных пользователей время ответа — не более 2 секунд»;
  • бизнес-правила — ограничения предметной области: «публикация статьи возможна только после утверждения редактором»;
  • ограничения — рамки реализации: «клиентская часть должна работать без установки дополнительных программ».

Зачем это тестировщику: анализ должен соответствовать уровню. Требовать от бизнес-требования технических деталей — ошибка: ему положено быть общим. И наоборот: продуктное требование «система должна работать быстро» — недоработка, на этом уровне обязана быть конкретика. Половина бессмысленных споров о требованиях — это претензии не к тому уровню.

Свойства хорошего требования

Когда вы «тестируете» требование, вы проверяете его на конкретный набор свойств. Вот главные, с типичными проблемами.

Полнота. В требовании есть вся нужная информация, ничего не опущено из соображений «это и так понятно». Проблема: «пароли хранятся в зашифрованном виде» — каким алгоритмом? «Экспорт в PDF, PNG и т. д.» — что прячется за «и т. д.»?

Атомарность. Одно требование описывает одну ситуацию, его нельзя разбить на части без потери смысла. Проблема: «кнопка Restart не отображается при остановленном сервисе, а окно Log вмещает не менее 20 записей» — два никак не связанных требования склеены в одно; при изменении одного придётся трогать оба.

Непротиворечивость. Требование не спорит ни с самим собой, ни с соседями. Проблема: в одном месте «кнопка Close всегда красная», в другом — «всегда синяя». Или внутри одного: «после успешного входа пользователя, не имеющего права входить…» — так вошёл он или нет?

Недвусмысленность. Требование понимается всеми одинаково. Главные враги — оценочные слова: быстро, удобно, эффективно, как минимум, при необходимости, обычно, большой, гибкий, простой. Каждое такое слово — сигнал: проверить требование нельзя, реализовать «правильно» — тоже. Встретили — задавайте вопрос.

Проверяемость. По требованию можно построить объективную проверку — тест-кейс, однозначно показывающий, выполнено оно или нет. Это свойство-итог: если нарушено что-то из предыдущих, проверяемость страдает первой. Мы разбирали её в статье про требования — «страница загружается быстро» против «не дольше 3 секунд».

Выполнимость. Требование реализуемо технически и вписывается в сроки и бюджет. Проблема-классика — «озолочение»: дорогие в реализации украшательства, которыми никто не будет пользоваться.

Актуальность и нужность. Требование всё ещё кому-то нужно. Требования, добавленные «на всякий случай» или устаревшие, но не удалённые, — мусор, который путает и разработку, и тестирование.

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

Проранжированность. У требований проставлены приоритеты. Когда всё «важно одинаково», команда тратит силы на второстепенное, а ключевое приезжает последним.

Как этим пользоваться

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

Практический приём: попробуйте по требованию придумать проверку. Если тест-кейс сочиняется легко — с проверяемостью, полнотой и недвусмысленностью, скорее всего, порядок. Если идей нет вовсе — вы нашли проблему, и это повод для вопроса автору.

Где это применяется

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

Где спотыкаются начинающие:

  • Предъявляют претензии не к тому уровню. «В бизнес-требовании не указан формат даты» — и не должен быть указан; формат живёт на продуктном уровне.
  • Пропускают оценочные слова. «Быстро», «удобно», «при необходимости» читаются гладко — и именно поэтому проскакивают. Тренируйте на них глаз.
  • Замечают проблему, но молчат. Найденное нарушение свойства — не повод для галочки, а повод для вопроса. Как его правильно задать — следующая статья.

Что учить дальше. Как устроено ревью требований и как формулировать вопросы, на которые отвечают по существу, — в статье про ревью требований.