Статическое тестирование требований — проверка спецификаций и связанных артефактов аналитика без исполнения программного кода. Для системного аналитика это способ поймать дефекты в описании до разработки: когда исправление — правка текста, а не переделка реализации. Статья фокусируется на объектах вашей работы — SRS, User Stories, Use Cases, контрактах API, моделях, NFR, критериях приёмки — и на том, как выбрать метод проверки и понять, что требование готово к передаче в команду.

1. Суть темы

Статическое тестирование (static testing) в контексте аналитика — анализ рабочих продуктов требований до появления исполняемого кода. Объекты проверки: тексты спецификаций (02.03.03 Спецификация требований (SRS, Use Case, User Story)), спецификации контрактов (03.05.03 Спецификации контрактов (OpenAPI, AsyncAPI, Protobuf)), диаграммы (UML, BPMN, ER), глоссарии, словари данных, матрицы трассировки, нефункциональные требования (08.02 Нефункциональные требования (НФТ) — классификация и стандарты). Ревью кода и статический анализ исходников — смежная практика STLC (00.03 Жизненный цикл ПО и место аналитика (SDLC, STLC)), подробнее в 08.04 Рецензирование и инспекции (техники Фейгана); здесь код не рассматривается как равноправный объект проверки.

В терминологии ISTQB static testing включает не только поиск дефектов в тексте, но и раннее проектирование проверок из требований: можно ли по формулировке вывести проверяемый сценарий (test condition), что уже покрыто AC и моделями, а что останется «дырой» для dynamic testing. Это не запуск тестов, а экспертная оценка тестируемости и полноты покрытия на бумаге — часто через PBR с роли тестировщика (см. раздел 2).

Статическое тестирование отвечает на два класса вопросов — без дублирования теории из 02.04.01 Верификация и валидация (V&V):

Тип проверкиВопросПримеры на статике
Верификация (verification)Правильно ли описано требование для команды?Однозначность, полнота атрибутов, отсутствие противоречий, трассировка, соответствие шаблону
Валидация (validation)Описывает ли требование нужное поведение для стейкхолдеров?Соответствие бизнес-целям, покрытие сценариев пользователя, приемлемость для заказчика

Walkthrough с заказчиком смещает акцент к validation; peer review и инспекция чаще закрывают verification — но на практике одна сессия может затрагивать оба аспекта, если участники и чек-лист это предусматривают.

Цели:

  1. Раннее обнаружение дефектов — на этапах, когда стоимость исправления минимальна (классический тезис о «сдвиге влево»; количественные оценки зависят от процесса и типа дефекта — см. Wiegers в источниках).
  2. Уточнение качества формулировок и снижение неоднозначности.
  3. Единое понимание среди аналитиков, разработчиков, тестировщиков и заказчика.
  4. Подтверждение готовности требования к работе — критерии выхода см. в п. 3.3.

Статическое тестирование — часть верификации в 02.04.01 Верификация и валидация (V&V) и вход для динамического тестирования. Исполняемые спецификации (BDD/Gherkin, executable acceptance tests) уже проверяют поведение, а не только текст — это граница static → dynamic. При этом review feature-файлов и lint/validate Gherkin в CI — гибрид: tool-based static analysis плюс экспертное рецензирование сценариев до прогона step definitions.

Отличие от динамического тестирования:

КритерийСтатическое (требования)Динамическое
ОбъектДокументы, модели, макеты без бэкенд-кодаРаботающее приложение
ЦельДефекты в спецификацииДефекты в поведении системы
МетодыРецензирование, инспекции, обходы, tool-based reviewМодульное, интеграционное, системное тестирование
ЭтапДо и параллельно с кодированиемПосле появления исполняемого кода

Динамическое тестирование отвечает: «правильно ли работает система?» Статическое — «правильно ли описаны требования к системе?»

2. Ключевые понятия

2.1. Методы рецензирования (review)

В терминологии ISTQB static testing объединяет review (экспертная оценка людьми) и static analysis (проверка инструментами). Для требований основной объём — review; static analysis дополняет его (п. 3.4).

МетодФормальностьКогда применять
Peer Review (неформальное рецензирование)НизкаяБыстрая обратная связь, рядовые истории, Agile-refinement
Walkthrough (проход)СредняяОзнакомление команды, сложные сценарии, обсуждение с заказчиком
Inspection (техническая инспекция)ВысокаяКритичный функционал, compliance, контрактные спецификации

Risk-based выбор: чем выше риск ошибки (безопасность, финансы, регуляторика — см. 08.05 Управление рисками на этапе анализа), тем формальнее метод и шире состав рецензентов. Для некритичных инкрементов достаточно peer review; при высоком риске и регулируемых доменах выбирайте inspection — регламент, роли и протокол описаны в 08.04 Рецензирование и инспекции (техники Фейгана).

Peer Review: автор передаёт документ коллегам; процесс гибкий, без обязательных ролей. В Agile — обмен User Stories и 02.04.02 Критерии приёмки (Acceptance Criteria) на refinement, сессии «three amigos» (аналитик, разработчик, тестировщик) — см. 05.02 Scrum и Kanban (аналитик в Agile).

Walkthrough: автор проводит аудиторию по документу; акцент на совместном понимании. Формат воркшопа — 02.02.02 Воркшопы, фасилитация и совместные сессии.

Аудит — отдельная практика: независимая проверка соответствия процесса и выборки артефактов стандартам и шаблонам; итог часто — несоответствие процессу и меры CAPA, а не цикл дефектов одного требования. Оценка зрелости процесса и метрик — в 08.01 Метрики и KPI процесса анализа.

2.2. Техники анализа на уровне требований

  • Perspective-Based Reading (PBR): рецензент читает с роли (пользователь, разработчик, тестировщик, администратор). С позиции тестировщика проверяется тестируемость каждого критерия приёмки и возможность вывести из требования проверяемые условия без доработки формулировки.
  • Чек-листы качества: атрибуты из 02.04.03 Управление качеством требований — атомарность, однозначность, трассируемость, наличие AC, соответствие шаблону (10.01.01 Шаблон User Story, 10.01.02 Шаблон Use Case). Полный перечень — в связанной заметке, здесь достаточно ссылки на чек-лист.
  • Анализ сценариев и граничных условий: альтернативные и исключительные потоки Use Case; переходы на диаграммах состояний; явно ли в UC и AC описаны границы допустимых значений, ошибки и исключения (если нет — дефект incompleteness или non-verifiable).
  • NFR как отдельный объект review: измеримость, метод верификации, связь с архитектурой — не сводите NFR к «проверим на нагрузке потом». Чек-лист и классификация — 08.02 Нефункциональные требования (НФТ) — классификация и стандарты; шаблон оформления — 10.01.12 Шаблон нефункциональных требований (NFR).
  • Трассировка: полнота связей «цель → требование → тест/дизайн» (02.03.04 Трассировка требований (концепция)); практический шаблон — 10.01.15 Шаблон матрицы трассировки.
  • Прототипирование (02.02.04 Прототипирование и UI-UX-исследования): смежный способ проверить понимание UI со стейкхолдерами. Кликабельный макет валидирует ожидания, но не заменяет рецензию текста требований и NFR; в ISTQB это ближе к validation через прототип, чем к классическому static review документа.

2.3. Классификация дефектов в требованиях

ТипСутьТипичное исправление
MissingФункция или ограничение не описаныДобавить требование, обновить трассировку
ExtraОписано лишнее («золотое покрытие»)Удалить или отложить; связь с 02.05.03 Управление объёмом (Scope Creep) и ожиданиями
AmbiguityМножественное толкованиеУточнить формулировку, добавить примеры
IncompletenessНет деталей (AC, приоритет, данные)Дополнить атрибуты
InconsistencyПротиворечие между требованиями или моделямиСогласовать версии, один источник истины
Non-verifiableНельзя объективно проверить («дружественная система»)Переформулировать через измеримые 02.04.02 Критерии приёмки (Acceptance Criteria)
Constraint violationПротиворечие технологическим или регуляторным ограничениямСогласовать с архитектурой и compliance (08.06 Юридические и регуляторные требования РФ (PCI-DSS))
Non-conformanceНарушение шаблона, нет ID, неверный приоритетПривести к стандарту оформления

Классификация — общий язык для протоколов рецензий и метрик (08.01 Метрики и KPI процесса анализа). Атрибуты качества по ISO/IEC/IEEE 29148 — см. 00.04 Основные стандарты и своды знаний (BABOK, SEBoK, ISO 29148).

Серьёзность замечаний в протоколе фиксируйте явно, иначе «нет блокирующих» остаётся предметом спора. Минимальная шкала для команды: blocker (нельзя передавать в разработку), major (существенный риск без немедленной блокировки), minor (косметика, уточнение), question (нужен ответ автора или стейкхолдера). Детали согласования шкалы с метриками — 08.01 Метрики и KPI процесса анализа; формальные inspection и работа с протоколом — 08.04 Рецензирование и инспекции (техники Фейгана).

3. Как применяется в работе аналитика

3.1. Обобщённый процесс

Два независимых контура: рецензирование конкретного артефакта и периодический аудит процесса.

graph TD
    subgraph R ["Рецензирование артефакта"]
        S[Выбор артефакта] --> B{Метод review}
        B --> C[Peer Review]
        B --> D[Walkthrough]
        B --> E[Inspection]
        C --> G[Фиксация замечаний]
        D --> G
        E --> G
        G --> H[Классификация дефектов и severity]
        H --> I[Исправление автором]
        I --> J[Контрольное рецензирование]
        J --> K{Критерии выхода?}
        K -- Да --> L[Готово к передаче]
        K -- Нет --> I
    end
    subgraph A ["Аудит процесса (отдельный контур)"]
        P[Выборка артефактов / период] --> Q[Аудит соответствия процессу]
        Q --> M[Несоответствия / CAPA]
    end

Рис. Review одного артефакта и аудит процесса по выборке — разные входы и исходы.

Роли в review: автор (аналитик), рецензенты (аналитик, разработчик, тестировщик, представитель заказчика); на формальной inspection — по регламенту 08.04 Рецензирование и инспекции (техники Фейгана).

Объём рецензии: полный документ (SRS, релизный пакет) или инкремент (story в спринте). При изменении требования (02.05.05 Жизненный цикл требования) пересматривайте затронутые фрагменты и связанную трассировку — не обязательно весь документ, но явно зафиксируйте scope повторной проверки.

3.2. Контрольные точки в жизненном цикле

  • После черновика — саморецензия: пауза «свежим взглядом», проход по чек-листу 02.04.03 Управление качеством требований, смена роли через PBR (прочитать как тестировщик или разработчик). Автор систематически не видит собственные двусмысленности — см. 01.07 Когнитивные искажения и критическое мышление.
  • Перед передачей коллеге — peer review.
  • Согласование с заказчиком — walkthrough.
  • Передача в разработку — inspection или приёмочный обзор при высоком риске.
  • При change — повторная проверка затронутых частей и анализ влияния на связанные требования.

3.3. Критерии выхода (Definition of Ready для требования)

Перед передачей в разработку зафиксируйте, что выполнено (адаптируйте под процесс команды; сводный чек-лист — 10.04 Чеклист аналитика перед стартом разработки):

DoR на уровне спринта в Agile — см. 05.02 Scrum и Kanban (аналитик в Agile).

3.4. Tool-based static analysis

Ручной review дополняют инструменты (02.05.06 Инструменты управления требованиями (Jama, DOORS, Confluence)):

  • обязательные поля и уникальные ID требований;
  • линтеры документации (Vale, markdownlint) и проверка терминологии;
  • валидация OpenAPI/AsyncAPI и синтаксиса Gherkin в pipeline;
  • правила в RM-системах (нет orphan-требований, обязательная трассировка);
  • рецензирование через Pull Request (07.05 Системы контроля версий (Git) для документации).

Автоматика ловит формальные нарушения; смысловые дефекты — только экспертный review.

3.5. Разрешение споров после рецензии

Если рецензенты по-разному трактуют формулировку, нужен арбитр: владелец продукта, lead-аналитик или архитектор — по регламенту проекта. Зафиксируйте решение в артефакте и глоссарии. Конструктивная критика и переговоры — 09.03 Управление конфликтами и переговоры, 09.01 Техники активного слушания и опросов.

4. Типовые ошибки и ограничения

  • Смешивать static review требований и code review — разные объекты, роли и артефакты; не подменяйте одно другим.
  • Проводить только неформальный peer review для критичного scope — без inspection и расширенного состава остаются логические дыры.
  • Считать прототип заменой рецензии текста — макет не проверяет полноту бизнес-правил и NFR (08.02 Нефункциональные требования (НФТ) — классификация и стандарты).
  • Пропускать отдельный проход по NFR и API-контрактам — story-центричный review не закрывает производительность, безопасность и согласованность контрактов (03.05.03 Спецификации контрактов (OpenAPI, AsyncAPI, Protobuf)).
  • Не определять критерии выхода и шкалу severity — команда начинает разработку при «в целом согласовали», без закрытых blocker и AC.
  • Пересматривать весь SRS при каждом мелком change — тратьте время на impact analysis и точечный re-review (02.05.05 Жизненный цикл требования).
  • Игнорировать tool-based проверки — дубли ID и broken links в трассировке manual review не поймает системно.
  • Путать дефект требования с недостатком процесса — аудит и CAPA не заменяют исправление конкретной story.
  • Оставлять non-verifiable формулировки «на потом» — без AC дефект перейдёт в dynamic testing и UAT.

Связи с другими разделами базы

Источники и дополнительные материалы

Стандарты и методологии

Книги

  • Карл Вигерс, Джой Битти. «Разработка требований к программному обеспечению» (3-е изд.) — главы 16–17 о проверке качества требований и рецензировании.
  • Сюзанна Робертсон, Джеймс Робертсон. «Управление требованиями» (Mastering the Requirements Process) — разделы о статическом тестировании и инспекциях.
  • Том Гилб, Дороти Грэхэм. «Software Inspection» — классическая работа по формальным инспекциям.
  • Гленфорд Майерс, Том Баджетт, Кори Сандлер. «Искусство тестирования программ» — глава о тестировании спецификаций.

Статьи и ресурсы