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

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

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

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

• Можно ли протестировать это требование?

• При каких условиях оно не будет выполнено?

• Какие сценарии обработки исключений и ожидаемые варианты поведения предусмотрены?

• Все ли варианты требования определены достаточно ясно?

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

---

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

Для создания пользовательских историй широко используется принцип INVEST: Independent, Negotiable, Valuable, Estimable, Small и Testable — независимая, обсуждаемая, ценная, оцениваемая, небольшая и тестируемая история. Последний атрибут, Testable (T), означает, что пользовательская история может считаться полной только в том случае, если ее можно протестировать. Но возникает важный вопрос: действительно ли аналитики последовательно проверяют все пользовательские истории по этому критерию?

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

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

Требования и тестирование — две опоры SDLC

Инженерия требований и тестирование в жизненном цикле разработки ПО (Software Development Life Cycle, SDLC) тесно связаны друг с другом. ISTQB рекомендует несколько техник проектирования тестов, включая анализ граничных значений, таблицы решений и тестирование переходов между состояниями, чтобы системно покрывать требования тестами.

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

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

Документация в Agile: принцип, который часто понимают неправильно

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

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

Рассмотрим простую пользовательскую историю и связанные с ней критерии приемки.

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

Критерии приемки:

• Система должна позволять пользователю заполнить данные профиля во время регистрации.

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

• Адрес электронной почты должен автоматически формироваться на основе имени пользователя, указанного при регистрации.

На первый взгляд эти критерии передают основную идею, но в них не хватает нескольких важных деталей:

• Какие поля нужно заполнить?

• Какие из них обязательны?

• Какие проверки нужно выполнять?

• Какие сообщения должна показывать система?

• Как должна выполняться проверка на дублирующийся адрес электронной почты?

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

Agile-манифест подразумевал совсем не это. Его принцип призывает поддерживать достаточный уровень документации — ровно такой, чтобы пользовательскую историю можно было разработать и протестировать, а аналитики, разработчики и тестировщики понимали ее одинаково.

Решать эту проблему нужно еще в процессе инженерии требований. Для этого аналитику стоит расширить взгляд на требования и учитывать еще одно измерение — обеспечение качества.

Мышление тестировщика: новое измерение в инженерии требований

Свод знаний по бизнес-анализу (Business Analysis Body of Knowledge, BABOK) подчеркивает важность ясных и однозначных требований. Учет тестирования в процессе инженерии требований дополняет принципы BABOK, связанные с четкостью и качеством формулировок. Мышление тестировщика в инженерии требований — это не тестирование самих требований, а применение принципов тестирования на этапе их проработки, чтобы сделать их яснее. Такой взгляд помогает аналитику формулировать надежные требования: четкие, точные, полные и тестируемые.

Раннее статическое тестирование

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

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

Использование техник проектирования тестов

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

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

Итоговый чек-лист проверки

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

• Можно ли протестировать это требование?

• При каких условиях оно не будет выполнено?

• Какие альтернативные сценарии и сценарии обработки исключений нужно учесть?

• Какие граничные значения и ограничения применимы к этому требованию?

• Все ли критически важные варианты требования описаны явно?

Такой чек-лист дает дополнительную уверенность в том, что требования готовы к передаче командам разработки и QA.

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

На этой схеме показаны основные шаги по применению мышления тестировщика в процессе инженерии требований.

Кейс со сбросом пароля

Рассмотрим типичное требование к сбросу пароля и посмотрим, как оно меняется, если взглянуть на него глазами тестировщика.

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

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

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

Шаг 1. Статический анализ

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

1. Не указано, сколько предыдущих паролей нельзя использовать повторно.

2. Не задан срок блокировки после неудачных попыток сброса пароля.

3. Не описаны сообщения об успешном и неуспешном выполнении операции.

Шаг 2. Применение техник проектирования тестов

Выбираем техники проектирования тестов, подходящие для этого сценария.

• Анализ граничных значений: не указана максимальная длина пароля.

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

С учетом вопросов, выявленных на шагах 1 и 2, критерии приемки дополняются следующим образом.

Шаг 3. Итоговый чек-лист проверки

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

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

Преимущества мышления тестировщика в процессе инженерии требований

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

Подведем итоги

Принцип Agile «работающий продукт важнее исчерпывающей документации» часто ошибочно воспринимают как разрешение ограничиться минимальным описанием требований. Это приводит к неоднозначности и потере важных деталей. На самом деле смысл принципа в том, чтобы документировать требования полно, кратко и так, чтобы все участники понимали их одинаково.

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

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

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

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

• 6 августа в 20:00. «Пользовательские сценарии (Use Cases) на реальном примере: от бизнес-требования заказчика до формулирования задачи для разработчика». Записаться

• 11 августа в 20:00. «Практическое собеседование системного аналитика». Записаться

Системно освоить профессию с нуля можно на курсе «Системный аналитик. Базовый уровень»: от работы с требованиями и пользовательскими сценариями до проектирования систем, интеграций и приёмки решений.