Требование проверяют до запуска продукта. Как объяснить, что такая проверка относится к тестированию, хотя программа не выполняется?
Это статическое тестирование: проверяют не работу выполняемой программы, а качество артефакта — требования, архитектуры, дизайна или кода — без его запуска. Цель состоит в раннем обнаружении дефектов, неоднозначностей, противоречий и пропусков.
Статическое тестирование не заменяет динамическое: оно показывает проблемы в описании или структуре решения, но не подтверждает фактическое поведение работающей системы.
Подход развивался как ответ на проблему позднего обнаружения дефектов. Если ошибка попадает из требования в дизайн, код и релиз, её исправление обычно затрагивает больше артефактов и участников, чем исправление на этапе обсуждения требования.
Поэтому в процесс разработки включают обзоры, инспекции, анализ требований и автоматические проверки исходных артефактов. Это позволяет находить часть проблем до появления исполняемого продукта.
Требование может быть формально написано, но оставаться неоднозначным или неполным. Например, фраза «система быстро отвечает» не задаёт измеримый предел, а условие «пользователь может отменить операцию» не описывает момент, после которого отмена невозможна.
Если такую проблему обнаружить только при выполнении сценария, команда уже потратит время на реализацию и тестовые данные. Кроме того, разные участники могут реализовать и проверять требование по-разному, что создаёт риск спора о том, является ли найденное поведение дефектом.
При статическом тестировании анализируют артефакт без запуска программы. Для требования проверяют однозначность, полноту, непротиворечивость, проверяемость и соответствие бизнес-цели. Для кода дополнительно могут искать нарушения правил, недостижимые ветви и подозрительные конструкции с помощью ревью или статического анализатора.
Механизм прост: участники сопоставляют артефакт с критериями качества, другими артефактами и ожидаемым поведением. Например, ревьюер может обнаружить, что требование допускает два разных толкования; это дефект требования, даже если код ещё не написан.
Важно различать статическое и динамическое тестирование. Статическое ищет дефекты в самом представлении решения, а динамическое проверяет наблюдаемое поведение запущенной системы на конкретных входных данных. Статическая проверка не выявит, например, ошибку, возникающую только при определённой последовательности действий во время выполнения.
Основной компромисс — затраты на анализ до реализации против экономии на последующих исправлениях. Статическая проверка эффективна, когда критерии понятны и участники обладают достаточной экспертизой; при этом она не доказывает отсутствие дефектов и должна дополняться динамическими проверками.
В требовании к оплате было указано: «после подтверждения заказа пользователю отправляется уведомление». На ревью выяснилось, что не определены канал уведомления, допустимая задержка и действие при временной недоступности сервиса сообщений.
Рассматривались два варианта. Можно было сначала реализовать основной сценарий и уточнить детали по результатам динамических тестов, но это повышало риск переделки контракта и обработки ошибок. Другой вариант — сразу провести статическое ревью и зафиксировать измеримые условия; он требовал времени до разработки, зато устранял неоднозначность на раннем этапе.
Выбрали второй вариант: уточнили критерии успешной оплаты, момент отправки, допустимую задержку и правила повторной доставки. В результате тестировщики получили однозначные ожидаемые результаты, а команда избежала раздельных трактовок требования; при этом динамические тесты всё равно понадобились для проверки фактического взаимодействия сервисов.
Нет. Оно обнаруживает дефекты и признаки риска в проверяемых артефактах, но не перебирает фактические состояния работающей системы. Даже хорошо проведённое ревью требований не показывает, что реализованный продукт корректно обрабатывает все реальные входные данные и взаимодействия.
Согласование может подтверждать только факт ознакомления или принятия решения. Статическое тестирование использует явные критерии и направлено на поиск дефектов: неоднозначности, пропусков, противоречий, нарушений правил и несоответствия ожидаемому поведению.
Поэтому полезно фиксировать найденную проблему, её влияние и решение, а не ограничиваться отметкой «документ просмотрен». Формат проверки может быть разным — от парного ревью до инспекции или автоматического анализа, но цель остаётся дефектной проверкой артефакта.
Автоматический анализ обычно проверяет формальные свойства: стиль, типичные ошибки, подозрительные конструкции или соответствие заданным правилам. Он не способен надёжно определить, правильно ли бизнес сформулировал цель, достаточно ли полна предметная область или не противоречат ли требования ожиданиям пользователей.
Поэтому автоматические проверки и экспертное ревью дополняют друг друга. Первые масштабируют обнаружение формальных проблем, а второе помогает оценить смысл, применимость и согласованность решения.