Home

Автор: Виктория Соковикова, тренер курса «Тестирование без требований: выявление и восстановление информации о продукте»

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

Распространенные возражения, как правило, сводятся к двум пунктам:

• У нас нет ТЗ, но проект-то есть, и тестирование ведется.
• Мы работаем по agile — функциональный продукт важнее документации, которая бы описывала его исчерпывающим образом.

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

Что такое неявные требования?

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

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

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

Такой документ создается в три этапа, подразумевающих формирование следующих перечней:

1.     Реестр потенциальных источников неявных требований.

2.     Реестр источников неявных требований к проекту.

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

Реестр потенциальных источников неявных требований

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

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

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

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

Реестр источников неявных требований (РИНТ) к проекту

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

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

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

●      Уникальный идентификатор источника.

●      Тип источника (НПА, регламент, реклама, исследования, чат и т. п.).

●      Необходимость актуализации.

●      Ссылка на актуальную версию.

Реестр неявных требований (РНТ)

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

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

Поэтому РНТ должен содержать конкретные факты и ограничения, влияющие на функционирование программы. Если описание слишком велико для занесения в таблицу (когда речь, например, идет о процессе или перечне фактов), достаточно будет и ссылки, но не на весь документ, а лишь на определенную его часть — раздел или пункт.

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

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

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

Обсудить в форуме