Всем привет! Меня зовут Вадим, и я QA-инженер в IT-компании Intelsy. С техническим заданием, и в частности с требованиями, лично я имею дело постоянно, поэтому собрал полезную для начинающих и продолжающих специалистов информацию по требованиям к IT-продукту, их видам, техникам и метрикам тестирования требований. На эту инфу стоит ориентироваться не только аналитикам и тестировщикам, но и остальным членам команды.
Что такое требования?
Требования служат фундаментом для каждого проекта и необходимы для глубокого понимания командой всех аспектов предстоящей работы. Ошибки и неточности в документации требований могут привести к проблемам в самый неожиданный момент. Внести пару правок в требования на первоначальном этапе гораздо проще, нежели вносить изменения в тысячи строк кода. Поэтому тщательное тестирование требований является критичным элементом процесса разработки, который помогает оптимизировать работу команды, предотвратить недопонимания и оценить выполнимость требований в установленных рамках времени, бюджета и доступных ресурсов.
Благодаря высокому качеству сформулированных требований достигается высокое качество конечного программного продукта. Процесс тестирования требований направлен на выявление и исправление потенциальных ошибок на ранних этапах проектирования, что в долгосрочной перспективе позволяет:
существенно снизить итоговую стоимость проекта;
повысить качество продукта;
сохранить нервы всей команде.
Что же включает в себя процесс тестирования требований?
Виды требований
При разработке продукта выделяют следующие виды требований:
Бизнес-требования определяют цели, ради которых разрабатывается продукт. Они устанавливают, какую ценность должен принести продукт и каковы пути получения прибыли с его помощью. Эти требования фиксируются в документе, который представляет общее видение и границы проекта, без детального описания системы или других технических характеристик.
Пользовательские требования описывают взаимодействие конечных пользователей с продуктом и выгоды, которые они получают. Пользовательские требования описывают, что пользователь может делать с продуктом и какие преимущества он получает (рабочие сценарии, реакция системы). Они часто представлены в форме пользовательских историй (user stories) и сценариев использования (use cases).
Бизнес-правила включают в себя набор ограничений и правил, которые регулируют определённые процессы в рамках выбранной области деятельности. Это могут быть корпоративная политика компании, государственные законодательные акты, отраслевые стандарты и т.д.
Функциональные требования описывают функциональные возможности продукта, а также поведение системы в различных ситуациях.
Нефункциональные требования описывают качественные характеристики продукта: удобство использования, безопасность, надежность, производительность, масштабируемость и другие атрибуты, а также различные технологические и эксплуатационные ограничения.
Тестирование требований в жизненном цикле разработки ПО
Жизненный цикл тестирования ПО — это процесс выполнения различных действий в ходе проведения тестирования. Каждая модель жизненного цикла тестирования программного обеспечения состоит из следующих шести ключевых этапов:
Анализ требований
Подготовка к тестированию
Создание тестовой документации
Настройка тестовой среды
Выполнение тестирования
Завершение цикла тестирования
Анализ и тестирование являются важнейшим и в то же время наименее затратным по времени этапом работ. По этой причине важно начинать тестирование с момента разработки технической спецификации. Задача тестирования требований – устранить как можно больше ошибок на ранних стадиях проектирования системы.
Тестирование требований
Для обеспечения высокого качества разработки программного обеспечения важно точно и ясно сформулировать требования к нему. Основные критерии, по которым тестировщики проводят анализ требований:
Полнота: все необходимые для реализации продукта детали должны быть включены в требования. Хорошей практикой является написание чек-листа проверок сразу при прочтении документа, чтобы не пропустить ничего важного.
Однозначность: требования должны быть сформулированы так, чтобы исключить возможность разночтений и различий в понимании среди всех участников процесса. Пример: если для поля с суммой дохода нужно установить значение по умолчанию, это должно быть четко указано. В противном случае аналитик может предположить, что значение будет равно 0, в то время как разработчик оставит его пустым, считая, что требования не уточняют это. Это может привести к ошибкам. Лучше избегать ситуаций, которые могут быть истолкованы по-разному.
Непротиворечивость: требования должны быть согласованными и не противоречить друг другу, даже если их много. Например, возникает инцидент, когда автор неоднократно упоминает один и тот же параметр, но в разных контекстах и с разны�� поведением. Или наличие общего требования без возможности исключений: например, требование 1 (из раздела функциональности спец-кнопок): когда активен режим «Mute», телефон не должен издавать никаких звуков. Требование 245 (из раздела интерфейса): когда пользователь снимает трубку, телефон должен издавать тоновые гудки. Имеем противоречивость в случае активного режима Mute и снятой трубки.
Атомарность: каждое требование должно быть самостоятельным, полным и описывать только один аспект функционала.
Корректность: требования должны точно отражать потребностям заинтересованных сторон, предметную область и пользовательские ожидания.
Тестируемость: подразумевает конечную и разумную по стоимости возможность провести ручную или автоматизированную проверку на предмет соответствия программного обеспечения требованию. Например, требование нельзя проверить на тестовом стенде, т.к. у него мало мощности и нет реальных (боевых) данных, а установка такого стенда будет дороже, чем потенциальная прибыль от разработки данного требования.
Техники тестирования требований
Тестирование документации и требований является частью общего процесса нефункционального тестирования, для чего применяются разнообразные методики:
1. Взаимный просмотр (PEER REVIEW):
Рецензирование или взаимный просмотр — одна из самых используемых техник при тестировании требований. Эта техника представляется в одной из следующих форм (по мере увеличения сложности и цены):
Беглый просмотр — это показ автором своей работы коллегам с целью установления общего понимания, получения обратной связи и обмена результатами работы между несколькими авторами, чтобы они выразили свои вопросы и замечания. Он является наиболее быстрым, экономичным и часто используемым видом просмотра.
Технический просмотр — группа специалистов осуществляет технический осмотр, в рамках которого каждый член команды представляет свою сферу компетенции, включая аналитика, разработчика и тестировщика. Продукт, который проходит такой технический осмотр, не может считаться достаточно высококачественным, пока у хотя бы одного из участников остаются замечания.
Формальная инспекция — это структурированный, систематизированный и документируемый метод исследования документации. Он требует участия большого количества экспертов и занимает много времени, поэтому его используют редко, например, когда другая компания была ответственна за первоначальный этап работы над проектом, и необходимо внести изменения или улучшения.
2. Тест-кейсы и чек-листы
ПРОДУМЫВАНИЕ ТЕСТ-КЕЙСОВ И ЧЕК-ЛИСТОВ
Хорошее требование должно быть проверяемым, то есть должен быть объективный способ определить, выполнено ли оно. Создание чек-листов или полноценных тестовых сценариев в процессе анализа требований помогает убедиться в их проверяемости. Наличие нескольких пунктов в чек-листе еще не означает, что требование выполнено полностью (например, возможно наличие противоречий с другими требованиями). Рекомендуется сначала убедиться, что вы полностью понимаете требование (включая чтение соседних требований и обсуждение с коллегами). Изучение других требований поможет лучше понять конкретное требование. Однако, если это не работает, требование должно быть пересмотрено.
ИССЛЕДОВАНИЕ ПОВЕДЕНИЯ СИСТЕМЫ
Этот метод является продолжением предыдущего и предполагает проверку не одного требования, а группы. Тестировщик создает модель поведения пользователя с системой для выявления возможных проблем или недоработок. Этот метод требует высокой квалификации и опыта от тестировщика, однако позволяет обнаружить ошибки, которые могли бы остаться незамеченными при проверке каждого требования по отдельности.
ГРАФИЧЕСКОЕ ПРЕДСТАВЛЕНИЕ
Для обобщенного представления требований эффективно использовать графические э��ементы, такие как рисунки, схемы, диаграммы, интеллект-карты и другие. В этом случае на помощь к тестировщикам приходят аналитики. Текстовое описание базы данных может быть громоздким и сложным для восприятия. Графическое представление упрощает понимание, позволяет быстро выявить несоответствия и недостающие элементы. Использование общепринятых нотаций, таких как язык UML, обеспечивает дополнительное преимущество: схема становится доступной для понимания и доработки коллегами, и в результате может стать ценным дополнением к текстовым требованиям.
ПРОТОТИПИРОВАНИЕ
После создания графического представления и анализа поведения системы часто создается прототип. Используя специальные инструменты, можно быстро создать наброски пользовательского интерфейса, оценить различные решения и даже создать основу для дальнейшей разработки. Возможно, прототип после небольших доработок будет удовлетворять требованиям заказчика.
Метрики покрытия требований
Метрики используются для отслеживания усилий по обеспечению качества выпускаемого программного кода. С их помощью удаётся в численном выражении получить представлении о достижении заданного уровня качества или поставленных целей. Существуют следующие метрики:
Тестовое покрытие требования
Матрица трассировки
Степень взаимосвязанности
Коэффициент стабильности требований
Выводы
Важным аспектом в тестировании требований является единое их понимание всеми участниками проектной команды, что предотвращает лишние правки уже реализованного функционала. В этом случае рекомендуется использовать метод технического просмотра. Это снизит риск возникновения внутренних разногласий, связанных с расхождениями в трактовании требований между разработчиками, аналитиками и тестировщиками, а также ускорит написание тестовой документации.
Качество проверки документации в значительной степени определяется квалификацией проверяющего. Поэтому целесообразно выделить опытного специалиста с экспертизой в области тестирования требований на данную роль. Кроме того, предпочтительно, чтобы документацию проверяли представители и других направлений: тестировщики, разработчики. Это позволит им задавать ��олее точные и профессиональные вопросы, что повысит шансы на успешную реализацию требований.
Аналитикам полезно чаще пользоваться методами графического представления при разработке требований, чтобы улучшить процесс понимания требований разными членами команды. Это, в свою очередь, способствует ускорению процессов разработки и тестирования функционала.
