Как вы считаете, можно ли тестировать ПО без требований? Ответ прост — нет!
Так как именно такие требования определяют, что конкретно должно быть представлено в разрабатываемом программном обеспечении.
Без подобных требований ни одно программное обеспечение не может быть создано.Но есть парочка популярных возражений, которые можно свести к двум аргументам:
- На проекте нет никакого технического задания, тестирование как-то, но ведется;
- Команда трудится по Agile — функциональность ПО важнее документации, которая могла бы самым исчерпывающим образом его описывать.
В любом случае, необходимо понимание того, кто именно будет пользоваться ПО, как оно должно выглядеть, из каких составных частей будет состоять и какими параметрами обладать.
Хотя данная информация и не содержится в спецификации, в ней как раз и указаны главные требования к разрабатываемому программному обеспечению.
Источником такой информации служат не просто банальные документы, а знания команды по тестированию, имеющиеся у клиента представления, короткие диалоги при созвонах — в общем, все то, что может порождать группу неявных требований.
Понятие неявных требований и когда их уместно использовать
Данные касательно необходимого поведения, внешнем отображении и свойствах ПО, которые не были внесены в техническое задание и спецификации, а также те, которые не были включены в постановку задач принято именовать неявными требованиями.
Их природа может проистекать из незадокументированных требований клиента, устных компромиссов между некоторыми членами одной проектной группы и даже личного профессионального опыта сотрудников.
Дополнительно стоит отметить, что в сумму инструментов, которые должны быть призваны структурировать уже имеющуюся информацию о ПО, входит так называемый «реестр неявных требований».
Он являет собой список всех заявленных системой ограничений и факторов, которые из-за определенных причин не были внесены в спецификацию.
Данный инструмент может стать полезным не только тогда, когда нет ТЗ, но и в роли дополнительного источника данных при наличии верифицированной сторонами спецификации.
Документ такого содержания разрабатывается в три этапа, которые подразумевают создание следующих важных компонентов:
- Реестр возможных источников неявных требований клиента;
- Реестр неявных данных к проекту;
- Реестр неявных требований.
Разберем каждый из вышеперечисленных пунктов по отдельности.
Неявные требования в тестировании ПО
Реестр возможных источников неявных требований клиента
Учитывая тот факт, что сумма источников неявных требований может быть безграничной, а любой проект отличается оригинальным набором подобных источников, полезно иметь представление касательно их полного перечня:
- Регламенты;
- Руководство пользователя;
- Реклама;
- Тестовые данные;
- Макет;
- Чит-лист;
- Руководство;
- Общение с техподдержкой;
- Опыт и рабочие наработки.
Рекомендуется вести общий документ подобного плана для каждой тестовой команды или всей продуктовой компании в целом.
В подобном случае, каждый сотрудник сможет не просто им пользоваться, но и вносить собственные идеи и предложения.
Реестр неявных данных к проекту
Первая стадия в разработке реестра неявных требований заключается в создании перечня их фактических источников, которые, в свою очередь, формируются на базе потенциальных.
Часть пунктов вносятся самостоятельно проектной группой на основе собственного опыта, а часть — по завершению собеседования с клиентом и группой потенциальных пользователей.
На данной стадии крайне важно собрать исчерпывающий список конкретных источников.
Например, если группа привлеченных на проект маркетологов делала свои исследования, нужно получить к ним доступ; если требования сформированы в чатах, попросите предоставить вам персональный доступ к таким перепискам.
Полученная информация систематизируется в виде таблицы.
Для того, чтобы с данным реестром было удобно работать, учитывайте такие параметры:
- Оригинальный идентификатор источника;
- Вид источника информации;
- Ссылка на актуальную версию (если подобная присутствует).
Реестр неявных требований
Если оперировать только реестром неявных данных, то максимум, который будет у вас — базовые данные, на основе которых выстроена вся реализация ПО.
В больше чем половине случаев она не несет никакой информационной практичности для достигаемой цели.
Реестр неявных требований обязательно должен содержать факты и ограничения, которые могут повлиять на производительность ПО.
Если блок описания достаточно велик для занесения в таблицу, достаточно всего лишь наличия ссылки на определенную часть требований.
Абсолютно все требования внутри реестра должны содержать оригинальные ID и дополняться ссылкой на их источник.
Оптимальней всего добавлять все неявные требования в техническую документацию проекта.
Оставить комментарий