Как вы считаете, можно ли тестировать ПО без требований? Ответ прост — нет!

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

[highlight dark=”no”]Без подобных требований ни одно программное обеспечение не может быть создано.[/highlight]

Но есть парочка популярных возражений, которые можно свести к двум аргументам:

1. На проекте нет никакого технического задания, тестирование как-то, но ведется;
2. Команда трудится по Agile — функциональность ПО важнее документации, которая могла бы самым исчерпывающим образом его описывать.

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

Хотя данная информация и не содержится в спецификации, в ней как раз и указаны главные требования к разрабатываемому программному обеспечению.

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

Понятие неявных требований и когда их уместно использовать

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

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

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

Он являет собой список всех заявленных системой ограничений и факторов, которые из-за определенных причин не были внесены в спецификацию.

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

Документ такого содержания разрабатывается в три этапа, которые подразумевают создание следующих важных компонентов:

• Реестр возможных источников неявных требований клиента;
• Реестр неявных данных к проекту;
• Реестр неявных требований.

Разберем каждый из вышеперечисленных пунктов по отдельности.

Реестр возможных источников неявных требований клиента

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

1. Регламенты;
2. Руководство пользователя;
3. Реклама;
4. Тестовые данные;
5. Макет;
6. Чит-лист;
7. Руководство;
8. Общение с техподдержкой;
9. Опыт и рабочие наработки.

Рекомендуется вести общий документ подобного плана для каждой тестовой команды или всей продуктовой компании в целом.

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

Реестр неявных данных к проекту

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

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

На данной стадии крайне важно собрать исчерпывающий список конкретных источников.

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

Полученная информация систематизируется в виде таблицы.

Для того, чтобы с данным реестром было удобно работать, учитывайте такие параметры:

1. Оригинальный идентификатор источника;
2. Вид источника информации;
3. Ссылка на актуальную версию (если подобная присутствует).

Реестр неявных требований

Если оперировать только реестром неявных данных, то максимум, который будет у вас — базовые данные, на основе которых выстроена вся реализация ПО.

В больше чем половине случаев она не несет никакой информационной практичности для достигаемой цели.

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

Если блок описания достаточно велик для занесения в таблицу, достаточно всего лишь наличия ссылки на определенную часть требований.

Абсолютно все требования внутри реестра должны содержать оригинальные ID и дополняться ссылкой на их источник.

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