Всем привет! Меня зовут Вадим, и я QA-инженер в IT-компании Intelsy. С техническим заданием, и в частности с требованиями, лично я имею дело постоянно, поэтому собрал полезную для начинающих и продолжающих специалистов информацию по требованиям к IT-продукту,  их видам, техникам и метрикам тестирования требований. На эту инфу стоит ориентироваться не только аналитикам и тестировщикам, но и остальным членам команды.

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

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

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

• существенно снизить итоговую стоимость проекта;

• повысить качество продукта;

• сохранить нервы всей команде.

Что же включает в себя процесс тестирования требований?

Виды требований

При разработке продукта выделяют следующие виды требований:

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

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

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

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

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

Тестирование требований в жизненном цикле разработки ПО

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

1. Анализ требований

2. Подготовка к тестированию

3. Создание тестовой документации

4. Настройка тестовой среды

5. Выполнение тестирования

6. Завершение цикла тестирования

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

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

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

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

• Однозначность: требования должны быть сформулированы так, чтобы исключить возможность разночтений и различий в понимании среди всех участников процесса. Пример: если для поля с суммой дохода нужно установить значение по умолчанию, это должно быть четко указано. В противном случае аналитик может предположить, что значение будет равно 0, в то время как разработчик оставит его пустым, считая, что требования не уточняют это. Это может привести к ошибкам. Лучше избегать ситуаций, которые могут быть истолкованы по-разному.

• Непротиворечивость: требования должны быть согласованными и не противоречить друг другу, даже если их много. Например, возникает инцидент, когда автор неоднократно упоминает один и тот же параметр, но в разных контекстах и с разным поведением. Или наличие общего требования без возможности исключений: например, требование 1 (из раздела функциональности спец-кнопок): когда активен режим «Mute», телефон не должен издавать никаких звуков. Требование 245 (из раздела интерфейса): когда пользователь снимает трубку, телефон должен издавать тоновые гудки. Имеем противоречивость в случае активного режима Mute и снятой трубки.

• Атомарность: каждое требование должно быть самостоятельным, полным и описывать только один аспект функционала.

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

• Тестируемость: подразумевает конечную и разумную по стоимости возможность провести ручную или автоматизированную проверку на предмет соответствия программного обеспечения требованию. Например, требование нельзя проверить на тестовом стенде, т.к. у него мало мощности и нет реальных (боевых) данных, а установка такого стенда будет дороже, чем потенциальная прибыль от разработки данного требования.

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

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

1. Взаимный просмотр (PEER REVIEW):

Рецензирование или взаимный просмотр — одна из самых используемых техник при тестировании требований. Эта техника представляется в одной из следующих форм (по мере увеличения сложности и цены):

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

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

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

2. Тест-кейсы и чек-листы

• ПРОДУМЫВАНИЕ ТЕСТ-КЕЙСОВ И ЧЕК-ЛИСТОВ

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

• ИССЛЕДОВАНИЕ ПОВЕДЕНИЯ СИСТЕМЫ

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

• ГРАФИЧЕСКОЕ ПРЕДСТАВЛЕНИЕ

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

• ПРОТОТИПИРОВАНИЕ

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

Метрики покрытия требований

Метрики используются для отслеживания усилий по обеспечению качества выпускаемого программного кода. С их помощью удаётся в численном выражении получить представлении о достижении заданного уровня качества или поставленных целей. Существуют следующие метрики:

• Тестовое покрытие требования

• Матрица трассировки

• Степень взаимосвязанности

• Коэффициент стабильности требований

Выводы

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

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

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