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