Статическое тестирование: ревью и обзоры

Что такое статическое тестирование? #

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

Динамическое тестирование запускает ПО и проверяет его поведение. Статическое тестирование читает ПО (или его документацию) и проверяет корректность.

Представьте это как вычитку рецепта перед приготовлением по сравнению с дегустацией блюда после. Оба подхода находят проблемы, но вычитка дешевле — вы обнаружите «добавить 10 стаканов соли вместо 1 чайной ложки» до того, как испортите продукты.

Почему статическое тестирование важно #

Стоимость исправления дефекта драматически возрастает с поздним обнаружением:

Статическое тестирование обнаруживает дефекты на самой ранней стадии — до написания кода. Исследование IBM показало, что инспекции могут устранить 60-90% дефектов до начала тестирования.

Что можно тестировать статически? #

• Спецификации требований
• User stories и критерии приёмки
• Документы архитектуры и дизайна
• Исходный код
• Тест-планы и тест-кейсы
• Схемы баз данных
• Конфигурационные файлы
• Определения CI/CD пайплайнов

Типы ревью #

Ревью — форма статического тестирования, выполняемая людьми. Они варьируются от неформальных до высокоформализованных.

Неформальное ревью #

Простейшая форма. Один человек просит коллегу посмотреть его работу. Без задокументированного процесса и формального результата.

Характеристики:

• Нет определённого процесса или ролей
• Часто быстрая проверка за столом или «можешь глянуть?»
• Нет задокументированных находок (или только устная обратная связь)
• Низкие накладные расходы, легко делать часто

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

Walkthrough #

Автор проводит рецензентов через рабочий продукт, объясняя содержание и собирая обратную связь. Автор ведёт и направляет сессию.

Характеристики:

• Презентация под руководством автора
• Может быть свободной или сценарной
• Находки могут документироваться или нет
• Фокус на обучении и обмене знаниями наравне с поиском дефектов

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

Техническое ревью #

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

Характеристики:

• Ведёт модератор (не автор)
• Рецензенты готовятся индивидуально перед встречей
• Документируются находки и решения
• Фокус на технических дефектах и соответствии стандартам
• Может использовать чеклисты

Когда использовать: Критические изменения кода, архитектурные решения, компоненты, связанные с безопасностью.

Инспекция (инспекция Фагана) #

Наиболее формальный тип ревью, разработанный Майклом Фаганом в IBM в 1976 году. Следует строгому процессу с определёнными ролями, критериями входа/выхода и метриками.

Роли:

• Модератор — фасилитирует процесс, обеспечивает соблюдение правил
• Автор — создал продукт, отвечает на вопросы, но не защищает
• Рецензенты — изучают артефакт и выявляют дефекты
• Секретарь — фиксирует все дефекты и решения

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

Процесс ревью #

Структурированное ревью следует этим фазам:

1. Планирование. Модератор выбирает рецензентов, распределяет материалы, устанавливает расписание, проверяет критерии входа.

2. Обзор/Kickoff. Автор предоставляет контекст. Модератор объясняет процесс и роли.

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

4. Встреча по ревью. Рецензенты делятся находками. Секретарь фиксирует дефекты. Группа решает по каждому вопросу. Встреча не должна решать проблемы — только выявлять их.

5. Доработка. Автор устраняет все выявленные дефекты.

6. Контроль. Модератор проверяет, что все дефекты устранены.

Чеклисты для ревью #

Чеклист ревью требований #

• Каждое требование имеет уникальный идентификатор (ID)?
• Каждое требование тестируемо (можно ли написать тест)?
• Есть ли противоречия между требованиями?
• Все допущения явно указаны?
• Определены граничные условия (мин, макс, пусто, null)?
• Указаны условия ошибок и их обработка?
• Требование свободно от неоднозначных терминов («быстро», «удобно»)?
• Указаны все форматы данных (даты, валюты, единицы)?

Чеклист ревью кода #

• Код соответствует дизайну/требованиям?
• Все условия ошибок обработаны?
• Ресурсы корректно освобождаются (соединения, файлы, память)?
• Входные значения валидируются перед использованием?
• Есть захардкоженные значения, которые должны быть настраиваемыми?
• Код свободен от уязвимостей безопасности (SQL injection, XSS)?
• Есть юнит-тесты для нового кода?
• Код следует стилевому руководству команды?

Преимущества раннего обнаружения дефектов #

Статическое тестирование даёт преимущества помимо поиска багов:

Обмен знаниями. Ревью распространяет понимание системы по команде.

Соблюдение стандартов. Ревью обеспечивает единообразное применение стандартов кодирования и архитектурных паттернов.

Наставничество. Младшие разработчики учатся, просматривая код старших и получая обратную связь по своему.

Улучшение документации. Ревью требований и дизайна заставляет излагать мысли ясно.

Упражнение: Проведите ревью требований #

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

Спецификация: Сброс пароля

REQ-1: Когда пользователь нажмёт «Забыл пароль», система должна быстро отправить email для сброса.

REQ-2: Ссылка для сброса должна истечь через некоторое время.

REQ-3: Новый пароль должен быть надёжным.

REQ-4: После сброса пользователь должен иметь возможность войти с новым паролем.

REQ-5: Система должна корректно обрабатывать ошибки.

REQ-6: Email должен содержать ссылку на страницу сброса пароля.

REQ-7: Пользователь должен ввести новый пароль дважды для подтверждения.

REQ-8: Если email не найден в системе, не раскрывать это пользователю (требование безопасности).

REQ-9: Токен сброса пароля должен быть криптографически стойким.

REQ-10: Ограничение частоты: пользователь не должен иметь возможность запрашивать слишком много писем для сброса.

Для каждого дефекта укажите: ID требования, тип дефекта и рекомендуемое исправление.

Метрики ревью #

Ключевые выводы #

• Статическое тестирование проверяет рабочие продукты без выполнения кода, обнаруживая дефекты на самой ранней и дешёвой стадии
• Ревью варьируются от неформальных до формальных (инспекция с ролями и метриками)
• Индивидуальная подготовка — самая эффективная фаза, большинство дефектов находят до встречи
• Чеклисты делают ревью систематическими и предотвращают типичные упущения
• Процесс ревью: планирование, kickoff, подготовка, встреча, доработка, контроль
• Преимущества выходят за рамки поиска дефектов: обмен знаниями, соблюдение стандартов и наставничество