Тестирование документации и требований

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

что необходимо заказчику без деталей реализации (принцип «what, not how»). Правда, бывают исключения в виде ограничений, например, на операционную систему.

Требования

основе работ Вигерса и стандарта IEEE Standard Glossary of Software

Engineering Terminology, 1990): 1. Условие или возможность, требуемая пользователем для решения задач или достижения целей. 2. Условие или возможность, которые должны удовлетворяться системой/компонентом системы или которыми система/компонент системы должна обладать для обеспечения условий контракта, стандартов, спецификаций или др. регулирующими документами. 3. Документальная репрезентация (зафиксированное определение, описание) условий или возможностей, перечисленных в предыдущих пунктах.

Определение

и процесса, с помощью которого продукт будет создаваться. Отметим, что

ряд требований может быть заложен неявно и программные требования могут порождать требования к процессу, например: работа в режиме 24×7 (как бизнес-требование) наверняка  приведёт к ограничению выбора тех или иных программных средств, платформ развёртывания и архитектурных решений.

Требования к продукту и процессу

Цель, которую он преследует — получить хороший конечный продукт: функциональный

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

Требования к продукту

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

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

Требования к процессу

на который сложно ответить однозначно. Ответ на него зависит от

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

Требования к процессу

физически находятся в разных государствах). В этой ситуации заказчику требуется

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

Пример

что на каждом следующем шаге процесса разработки продукта стоимость обнаружения

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

Важность требований

требованиях закрадывается больше всего багов, а не в коде, как

думают многие.

Важность требований

к программному продукту (functional specifications).
Архитектуру (architecture) и дизайн (design).
План проекта

(project plan) и тестовый план (test plan).
Тестовые случаи и сценарии (test cases, test scenarios).

Сопроводительную документацию (и документацию для пользователей):
Интерактивную помощь (on-line help).
Руководства по установке (Installation guide) и использованию программного продукта (user manual).

Виды документации, подвергаемой тестированию

называемые бизнес-требования (business requirements). Пример бизнес-требования: система должна сократить срок оборачиваемости

обрабатываемых на предприятии заказов в три раза. Бизнес-требования обычно формулируются топ-менеджерами, либо акционерами предприятия. 2. Следующий уровень — уровень требований пользователей (user requirements). Пример требования пользователя: система должна представлять диалоговые средства для ввода исчерпывающей информации о заказе, последующей фиксации информации в базе данных и маршрутизации информации о заказе к сотруднику, отвечающему за его планирование и исполнение.
Требования пользователей часто бывают плохо структурированными, дублирующимися, противоречивыми. Поэтому для создания системы важен третий уровень, в котором осуществляется формализация требований. 3. Третий уровень — функциональный (functional requirements). Пример функциональных требований (или просто функций) по работе с электронным заказом: заказ может быть создан, отредактирован, удалён и перемещён с участка на участок.
Функциональные требования определяют «что система должна делать», нефункциональные – «как система это должна делать? С соблюдением каких условий» (например, скорость отклика при выполнении заданной операции).

Уровни требований

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

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

Функциональные требования

– заказчика разрабатываемого программного обеспечения.
Пользовательские требования (user requirements) – описывают цели/задачи

пользователей системы, которые должны достигаться/выполняться пользователями при помощи создаваемой программной системы.
Функциональные требования (functional requirements) – определяют функциональность (поведение) программной системы, которая должна быть создана разработчиками для предоставления возможности выполнения пользователями своих обязанностей в рамках бизнес-требований и в контексте пользовательских требований.

Группа функциональных требований

платформы,
расширяемость,
надёжность и т.д.
Под надёжностью понимаются такие характеристики,

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

Нефункциональные требования

политиками, стандартами, законодательными актами, внутрикорпоративными инициативами (например, стремление достичь зрелости

процессов по CMMI 4-го уровня), учётными практиками, алгоритмами вычислений и т.д. В контексте управления проектами такие правила обладают высокой значимостью и, именно они, определяют ограничения использования бизнес-проектов, для автоматизации которых создается соответствующее программное обеспечение.
Внешние интерфейсы (external interfaces) – часто подменяются «пользовательским интерфейсом». На самом деле вопросы организации пользовательского интерфейса безусловно важны в данной категории требований, однако, конкретизация аспектов взаимодействия с другими системами, операционной средой (например, запись в журнал событий операционной системы), возможностями мониторинга при эксплуатации – все это не столько функциональные требования, сколько вопросы интерфейсов, так как функциональные требования связаны непосредственно с функциональностью системы, направленной на решение бизнес-потребностей.
Атрибуты качества (quality attributes) – описывают дополнительные характеристики продукта в различных измерениях, важных для пользователей и/или разработчиков. Атрибуты касаются вопросов портируемости, интер-операбельности (прозрачности взаимодействия с другими системами), целостности, устойчивости и т.п.
Ограничения (сonstraints) – формулировки условий, модифицирующих требования или наборы требований, сужая выбор возможных решений по их реализации. В частности, к ним могут относиться параметры производительности, влияющие на выбор платформы реализации и/или развёртывания (протоколы, серверы приложений, баз данных, …), которые, в свою очередь, могут относиться, например, к внешним интерфейсам.

Группа нефункциональных требований

группы как:
Потребности (needs) – отражают проблемы бизнеса, персоналии или процесса, которые

должны быть соотнесены с использованием или приобретением системы.
Системные требования (system requirements) – иногда классифицируются как составная часть группы функциональных требований (не путайте с как таковыми «функциональными требованиями»). Описывают высокоуровневые требования к программному обеспечению, содержащему несколько взаимосвязанных подсистем и приложений. При этом, система может быть как целиком программной, так и состоять из программной и аппаратной частей. В общем случае, частью системы может быть персонал, выполняющий определенные функции системы, например, авторизацию выполнения определенных операций с использованием программно-аппаратных подсистем.
Независимые свойства (emergent properties) – требования, которые не могут быть адресованы тому или иному компоненту программной системы, но которые должны быть соблюдены, например, в контексте сетевой инфраструктуры или регламентов работы пользователей.
Требования с количественной оценкой (quantifiable requirements) – требования, поддающиеся количественному определению/измерению, например, система должна обеспечить пропускную способность «столько-то запросов в секунду».

Другие требования

будет делать» (варианты использования)
Уровень функциональных и нефункциональных требований: «что конкретно

должна выполнять система и как она должна это выполнять» (набор требований)

Уровни требований

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

- разработка программного кода
Тестировщик - составление тест-плана, тестовых сценариев
Менеджер проекта - планирование и контроль исполнения работ

Кто создаёт и использует требования

(регламенты, положения, уставы, приказы)
Текущая организация деятельности объекта автоматизации
Модели деятельности (диаграммы

бизнес-процессов)
Представления и ожидания потребителей и пользователей системы
Журналы использования существующих программно-аппаратных систем
Конкурирующие программные продукты

Источники требований

экспертов и т.д.)
Артефакты, описывающие предметную область
«Лучшие практики» («best practices»)

Источники требований

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

в виду «Какой должна быть система?»
Нужно «увидеть», как программный продукт

впишется в организационные процессы предприятия
Какие ключевые выгоды он даст
Какие проблемы позволит разрешить
Обсуждаются:
Высокоуровневые требования (возможности, свойства) продукта
Наиболее существенные ограничения

Видение продукта

вопросы для обсуждения:
Границы системы и среды
Требуемые ресурсы на создание системы

(бюджет, календарное планирование, подбор персонала)
Сроки (ключевые даты)

Границы проекта

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

1.4. Границы проекта.

Здесь содержится ссылка на документ "Концепция", если таковой имеется, либо краткое резюме продукта.

1.5. Ссылки.

Документирование требований. Секции документа “Требования” на основе IEEE Standard 830-1998

- является ли описываемый продукт новым членом растущего семейства продуктов,

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

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

2.3. Классы и характеристики пользователей. Документируется процесс поиска акторов, в котором выявляются все пользователи системы и осуществляется обобщение (выделение классов) пользователей. Найденные классы описываются (например - уровень квалификации, доступный функционал и т.д.).

2.4. Операционная среда. Рассматривается среда функционирования АИС, включая аппаратные средства, операционные системы, для распределенных систем - географическое расположение пользователей и серверов, топология сети.

Документирование требований. Секции документа “Требования” на основе IEEE Standard 830-1998

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

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

2.6 Документация для пользователей.

2.7 Предположения и зависимости

Документирование требований. Секции документа “Требования” на основе IEEE Standard 830-1998

i-й функции системы.

З.i.1 Описание и приоритеты. Приводится краткое описание функции

и указывается ее приоритет (степень важности/очередности реализации).

З.i.2 Последовательности "воздействие - реакция". Необходимо перечислить последовательность воздействий, оказываемых на систему (действия пользователей, сигналы внешних устройств и др.), и отклики системы, определяющие реакцию конкретной функции.

З.i.З Функциональные требования. Необходимо дать детализацию i-й функции, перечислить детализированные функциональные требования, включая реакцию на ожидаемые ошибки и неверные действия. Каждому детальному функциональному требованию присваивается уникальный идентификатор.

Документирование требований. Секции документа “Требования” на основе IEEE Standard 830-1998

разделов этого параграфа, согласно:

4.1 Интерфейсы пользователя
Основные характеристики UI:

ссылки на стандарты

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

Документирование требований. Секции документа “Требования” на основе IEEE Standard 830-1998

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

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

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

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

Документирование требований. Секции документа “Требования” на основе IEEE Standard 830-1998

не относящиеся к требованиям к интерфейсу, которые представлены в разделе

4, и к ограничениям, описываемым в разделе 2.5.

5.1 Требования к производительности
Указываются специальные требования к производительности для различных системных операций. Обосновывается их необходимость для того, чтобы помочь разработчикам принять правильные решения, касающиеся дизайна.
Приложение А. Словарь терминов (глоссарий).
Приложение Б. Модели анализа. В этот раздел помещаются все модели, построенные в процессе анализа требований.
Приложение В. Список вопросов.
Это динамический список еще не разрешенных проблем, связанных с требованиями. Это могут быть элементы, помеченные как "ТВD" (To Be Determined - необходимо определить), отложенные решения, необходимая информация, неразрешенные конфликты и т.п.

Документирование требований. Секции документа “Требования” на основе IEEE Standard 830-1998

общего понимания между заказчиком и разработчиком
Определить рамки проекта
Более точно определить

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

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

включены. Ничто не должно быть оставлено «для будущего определения» (TBD

– to be defined).
Непротиворечивым (consistent). Требование не должно содержать противоречий как внутри себя, так и с другими требованиями.
Корректным (correct). Требование должно чётко указывать на то, что должно выполнять приложение. Недопустимо при написании требования предполагать, что что-то окажется очевидным. Каждый человек понимает это «очевидное» по-своему, и в итоге система получится не такой, как задумывалось.
Недвусмысленным (unambiguous). Требование не должно допускать разночтений.
Проверяемым (verifiable). Требование должно быть сформулировано так, чтобы существовали способы однозначной проверки – выполнено требование или нет.

Характеристики хорошего требования

должны быть такими, чтобы набор требований можно было легко модифицировать.

Должна отсутствовать избыточность. Должно быть построено корректное содержание всего документа.
Прослеживаемыми (traceable). У каждого требования должен быть уникальный идентификатор, по которому на это требование можно сослаться.
Проранжированными по важности, стабильности и срочности (ranked for importance, stability and priority). Для каждого требования должен быть указан уровень его важности (насколько оно важно для заказчика), стабильности (насколько высока вероятность, что это требование ещё будет изменено в процессе обсуждения деталей проекта) и срочности (как быстро требование должно быть реализовано).

Характеристики хорошего набора требований

немодифицируемости
Проблема непрослеживаемости
Проблема непроранжированности




Проблемы с требованиями

а как можно найти то, чего нет, но должно быть?

Как догадаться, что что-то отсутствует?
Следует обратить внимание на такие типичные случаи.
Отсутствуют нефункциональные требования или нефункциональные составляющие требования. Мы знаем, что система должна делать. А про то, как (как быстро, как безопасно) в лучшем случае узнаём только в самом конце.
Итак, мы уточнили какие-то требования, и заказчик высказал свои предпочтения. Например, ему нужно, чтобы приложение работало «надёжно и быстро».
Думаем, как мы сможем проверить эти требования? Проверить, что приложение работает быстро. А как проверить? И что проверять?
Вывод: кроме самого нефункционального требования, нам обязательно нужны критерии – как это требование проверить (и измерить). Чем важнее требование для заказчика, тем точнее должны быть эти критерии.

Проблема незавершённости (неполноты)

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

имеющихся вариантов.

Хорошая аналогия – вопросы репортера (или маленького ребёнка): «А что?», «А зачем?», «А почему?»

Проблема незавершённости (неполноты)

be defined», «будет определено»).

Мы можем успокоиться (на время) , только

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

Также бывает, что стороны, ответственные за закрытие TBD, просто забывают об этом. Вывод? Нужно напоминать.

Проблема «To Be Defined»

таблицами и текстом.
Противоречия между картинкой и текстом.
Противоречия между требованием и

прототипом.

Проблемы противоречивости

наличием «озолочения» («gold plating»);
- наличием технически невыполнимых требований;
- наличием неаргументированных

требований к дизайну и архитектуре.

Проблемы некорректности

разные люди поймут это по-разному.
Например. В требовании сказано, что «функциональность

X» является опциональной.
Что думает отдел разработки? «Чудесно. Опционально – значит необязательно. Можно не реализовывать.»
Что думает отдел маркетинга? «Ага. Мы выпустим две версии продукта. В более дорогой будет эта функциональность.»
Что думает заказчик? «Я за те же деньги получу ещё и вот эту функциональность».

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

Проблемы двусмысленности

том числе к тому, что мы не можем проверить, удовлетворяет

ли продукт требованию.

Как понять, что требование непроверяемо? Попробовать придумать несколько тестов для его проверки. Если тесты не придумываются – вот она, проблема.

А бывает ли «просто непроверямое требование»? Да.
Например: «В приложении должно быть ноль ошибок». «Приложение должно поддерживать все версии всех операционных систем».

Проблемы непроверяемости

появившиеся противоречия

Проблемы немодифицируемости

работающих перекрёстными ссылок – это хаос. А в хаосе ошибки

плодятся с удивительной скоростью.

Проблемы непрослеживаемости

рискуем уделить основное внимание не тому, что на самом деле

важно для заказчика.

Проблемы непроранжированности

конечном итоге именно тестировщики отвечают за то, чтобы требование было

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

Вывод

перепросмотр.
Суть взаимного перепросмотра требований проста: после того, как один человек

создал требование, другой человек это требование проверяет.
Обычно, выделяют три уровня перепросмотра:
Неформальный перепросмотр. Двое коллег просто обмениваются листиками (файликами) и правят найденные ошибки, которые потом обсуждаются за чашкой чая или в любое другое относительно свободное время.
Технический перепросмотр. Это немного более формализованный процесс, требующий подготовки, выделенного времени, участия некоторой группы специалистов (желательно, из различных областей).
Формальная инспекция. Проводится редко и в случае очень больших проектов и крайней необходимости. Описывается специальными стандартами, требует соблюдения широкого спектра правил и протоколирования результатов.

Работа с требованиями (техники и способы)

тест кейсы и рисовать рисунки.
Самый простой и не требующий большого

опыта способ – задавать как можно больше вопросов. Получая разнообразные ответы от разных участников проекта (как наших коллег так и представителей заказчика), мы расширяем, углубляем и уточняем своё представление о том, что и как должно работать.
Второй способ – создавать тест-кейсы (о которых мы поговорим позже). Когда вы видите требование, спросите себя: «Как я буду его тестировать? Какие тесты очевидно покажут, что это требование реализовано в ПС правильно?» Если с придумыванием таких тестов вы испытываете сложность – это тревожный звоночек: скорее всего, в требовании есть проблемы.
Третий способ – рисовать. Чтобы увидеть общую картину требований целиком, очень удобно использовать рисунки, схемы, диаграммы и т.д.

Работа с требованиями (техники и способы)