Когда новичок только заходит в тестирование, ему часто кажется, что работа тестировщика начинается в тот момент, когда открывается приложение.
Запустил сайт.
Нажал кнопку.
Ввел данные.
Проверил результат.
Нашел баг.
Оформил задачу.
И да, это действительно часть тестирования. Но не всё тестирование работает именно так.
Иногда ошибку можно найти ещё до запуска приложения.
До того, как сборка попала на тестовый стенд.
До того, как тестировщик открыл интерфейс.
И даже до того, как пользовательская функция вообще начала работать.
И вот здесь появляется классификация тестирования по запуску кода на исполнение.
Она отвечает на простой вопрос:
Мы запускаем программу, чтобы проверить её поведение, или анализируем её без запуска?
По этому признаку тестирование делят на два вида:
Статическое тестирование — код не запускается.
Динамическое тестирование — код запускается.
Разберём оба варианта нормально, без заумных определений.
Что такое статическое тестирование
Статическое тестирование — это проверка продукта, кода, требований, макетов или другой документации без запуска программы.
То есть мы не открываем приложение и не выполняем сценарий как пользователь.
Мы смотрим на то, что уже есть: требования, техническое задание, дизайн, код, API-спецификацию, тест-кейсы.
Главная идея статического тестирования:
найти проблему как можно раньше, пока она ещё не превратилась в дорогой баг на позднем этапе.
Например, аналитик написал требование:
Пользователь должен иметь возможность восстановить пароль по номеру телефона.
На первый взгляд всё понятно. Но если начать внимательно читать, появляются вопросы:
А что делать, если номер телефона не подтверждён?
А если номер уже привязан к другому аккаунту?
А сколько раз можно запросить код восстановления?
А через сколько минут код становится недействительным?
А что показывать пользователю, если SMS не пришла?
Приложение ещё не запущено. Код ещё может быть даже не написан.
Но потенциальные проблемы уже найдены.
Это и есть смысл статического тестирования.
Что можно проверять статически
Статическое тестирование — это не только про код.
Проверять можно:
Требования.
Например, нет ли в них противоречий, дыр, неоднозначных формулировок.
Макеты.
Например, есть ли состояния ошибок, пустые состояния, адаптация под мобильный экран.
API-спецификации.
Например, описаны ли коды ошибок, обязательные поля, форматы дат.
Тест-кейсы и чек-листы.
Например, не забыли ли важные сценарии и негативные проверки.
Код.
Например, нет ли подозрительных условий, дублирования, небезопасной обработки данных.
Пример статического тестирования из реальной QA-практики
Представим, что команда делает форму авторизации.
В требованиях написано:
После 5 неправильных попыток входа пользователь должен быть заблокирован.
Если тестировщик читает это требование до разработки, он может сразу задать вопросы:
Что значит «заблокирован» — навсегда или временно?
Блокируется аккаунт, IP-адрес или конкретное устройство?
Через сколько времени можно попробовать снова?
Должно ли приходить уведомление на почту?
Что увидит пользователь на экране?
Если эти вопросы не задать заранее, разработчик может реализовать функцию по-своему, аналитик ожидал другое, а тестировщик потом найдёт расхождение уже на готовой сборке.
В итоге задача вернётся на доработку, команда потеряет время, а баг мог быть предотвращён ещё на этапе чтения требований.
Виды статического тестирования
Статическое тестирование бывает ручным и автоматизированным.
Ручное статическое тестирование
Это когда человек сам анализирует материал.
Например:
ревью требований;
ревью тест-кейсов;
ревью макетов;
ревью кода;
обсуждение спорной логики на командной встрече.
Для junior-тестировщика особенно полезно начинать именно с ревью требований и макетов. Это хорошо развивает мышление: ты учишься видеть не только «что написано», но и «что не написано».
А в тестировании часто ломается не только то, что описали плохо.
Иногда ломается то, что вообще забыли описать.
Автоматизированное статическое тестирование
Это когда специальные инструменты анализируют код без запуска программы.
Например:
ESLint может находить проблемы в JavaScript-коде.
Pylint и mypy помогают проверять Python-код.
Checkstyle и SpotBugs используются в Java-проектах.
SonarQube может анализировать качество кода, дублирование, потенциальные ошибки и уязвимости.
Важно понимать: такие инструменты не проверяют бизнес-логику как пользователь.
Они не скажут: «Кнопка оплаты работает неправильно».
Но они могут подсветить технические проблемы:
неиспользуемый код;
подозрительные условия;
дублирование;
потенциальные ошибки типов;
проблемы стиля;
опасные конструкции.
Это тоже часть качества продукта.
Что такое динамическое тестирование
Динамическое тестирование — это проверка программы во время её выполнения.
То есть приложение нужно запустить.
Мы открываем интерфейс, отправляем API-запрос, запускаем автотест, выполняем сценарий, передаём входные данные и сравниваем фактический результат с ожидаемым.
Если статическое тестирование отвечает на вопрос:
«Есть ли проблемы в том, как это написано или задумано?»
то динамическое отвечает на вопрос:
«А как это реально работает?»
Пример динамического тестирования
Возьмём ту же форму авторизации.
На этапе динамического тестирования тестировщик уже открывает приложение и проверяет поведение:
вводит правильный логин и пароль;
вводит неправильный пароль;
проверяет блокировку после нескольких неудачных попыток;
смотрит текст ошибки;
проверяет восстановление доступа;
отправляет запросы через API;
смотрит, что происходит в базе или логах, если есть доступ.
Здесь уже важно не только то, что написано в требованиях.
Важно, как система ведёт себя на самом деле.
Например, в требованиях указано:
После 5 неправильных попыток входа аккаунт блокируется на 15 минут.
А при проверке оказывается, что аккаунт блокируется уже после 4 попыток.
Или блокируется только в интерфейсе, но через API вход всё ещё возможен.
Или таймер блокировки сбрасывается после обновления страницы.
Вот это уже динамическое тестирование, потому что мы проверяем работающую систему.
Что относится к динамическому тестированию
К динамическому тестированию относится большая часть привычных QA-проверок.
Например:
Функциональное тестирование.
Проверяем, выполняет ли система свои функции.
Регрессионное тестирование.
Проверяем, не сломали ли старую функциональность после изменений.
Smoke-тестирование.
Быстро проверяем, что сборка вообще пригодна для дальнейших проверок.
Sanity-тестирование.
Проверяем конкретную изменённую область после доработки.
E2E-тестирование.
Проходим полный пользовательский сценарий от начала до конца.
API-тестирование.
Проверяем работу системы через запросы без интерфейса.
Нагрузочное тестирование.
Проверяем, как система ведёт себя под большим количеством пользователей или запросов.
Всё это динамическое тестирование, потому что система запускается и выполняет какие-то действия.
Статическое и динамическое тестирование на одном примере
Допустим, команда делает функцию смены email в личном кабинете.
Статическое тестирование
Тестировщик читает требования и замечает вопросы:
Нужно ли подтверждать новый email?
Что делать со старым email?
Можно ли указать email, который уже используется другим аккаунтом?
Нужно ли вводить пароль перед сменой email?
Должно ли приходить уведомление о смене адреса?
Что делать, если пользователь перешёл по старой ссылке подтверждения?
На этом этапе приложение можно даже не запускать.
Мы ищем проблемы в логике и описании.
Динамическое тестирование
Функция уже разработана. Тестировщик открывает личный кабинет и проверяет:
можно ли изменить email;
приходит ли письмо подтверждения;
нельзя ли указать уже занятый email;
что будет при неверном формате адреса;
работает ли подтверждение по ссылке;
сохраняется ли новый email после выхода и повторного входа;
не сломалась ли авторизация после изменения адреса.
Теперь система выполняется, и мы проверяем её реальное поведение.
Главное отличие простыми словами
Разница очень простая.
Статическое тестирование — смотрим и анализируем, но не запускаем.
Динамическое тестирование — запускаем и проверяем в работе.
Если совсем бытовой пример:
статическое тестирование — это когда вы читаете рецепт и замечаете, что в нём забыли указать температуру духовки.
динамическое тестирование — это когда вы уже готовите блюдо и видите, что оно сгорело, потому что температура была выбрана неправильно.
В IT всё примерно так же.
Что лучше: статическое или динамическое тестирование?
Нельзя сказать, что один вид лучше другого.
Они решают разные задачи.
Статическое тестирование помогает находить проблемы раньше.
Динамическое тестирование показывает, как система работает на самом деле.
Хороший процесс тестирования использует оба подхода.
Если полагаться только на динамическое тестирование, команда будет находить много проблем уже после разработки. Это дороже и дольше.
Если полагаться только на статическое тестирование, можно хорошо обсудить требования и код, но всё равно не увидеть реальные ошибки поведения в работающем приложении.
Например, требование может быть написано идеально.
Код может выглядеть аккуратно.
Но при запуске окажется, что кнопка не нажимается в мобильной версии, API возвращает 500, а письмо подтверждения не приходит.
Поэтому статическое и динамическое тестирование не конкурируют.
Они дополняют друг друга.
Почему junior-тестировщику важно это понимать
Новичку часто хочется сразу «кликать приложение». Это нормально. Динамическое тестирование кажется более понятным: вот кнопка, вот поле, вот ошибка.
Но если тестировщик умеет работать только с готовой сборкой, он включается в процесс слишком поздно.
Более сильный QA подключается раньше:
читает требования;
задаёт вопросы;
смотрит макеты;
находит неописанные сценарии;
замечает противоречия;
помогает команде не унести ошибку в разработку.
Это уже не просто «поиск багов».
Это работа с качеством на более раннем этапе.
И именно поэтому рынок всё чаще ждёт не просто тестировщика, который нажимает кнопки, а QA-специалиста, который понимает процесс шире.
Частые ошибки в понимании этой классификации
Ошибка №1. Думать, что статическое тестирование — это только про код
Нет. Статически можно проверять требования, макеты, схемы, документацию, тест-кейсы и API-спецификации.
Для manual QA это особенно важно, потому что тестировщик не обязан быть разработчиком, чтобы находить проблемы до запуска приложения.
Ошибка №2. Думать, что динамическое тестирование — это только ручные проверки
Тоже нет.
Автотесты — это тоже динамическое тестирование.
Например, Playwright, Selenium, Pytest, JUnit или Postman/Newman запускают проверки на работающей системе или её части.
Главный признак не в том, человек проверяет или инструмент.
Главный признак — выполняется код или нет.
Ошибка №3. Думать, что статическое тестирование заменяет динамическое
Не заменяет.
Можно идеально проверить требования, но всё равно получить баг в реализации.
Можно красиво написать код, но ошибиться в настройках окружения.
Можно заранее обсудить сценарии, но при запуске увидеть, что система падает на реальных данных.
Статическая проверка снижает риск.
Динамическая проверка показывает факт.
Как это выглядит в нормальном рабочем процессе
Хороший процесс может выглядеть так:
Сначала команда обсуждает задачу.
QA читает требования и задаёт вопросы.
Дизайнер показывает макеты, QA смотрит состояния ошибок и пустые экраны.
Разработчик пишет код, другой разработчик делает code review.
Статические анализаторы проверяют стиль и потенциальные проблемы.
После этого собирается билд.
QA запускает приложение и выполняет динамические проверки.
Автотесты проходят в CI/CD.
Если всё хорошо, задача идёт дальше.
То есть качество не начинается в момент, когда тестировщик получил готовую сборку.
Качество начинается раньше — когда команда только формулирует, что именно нужно сделать.
Коротко для запоминания
Классификация тестирования по запуску кода на исполнение делит проверки на два вида.
Статическое тестирование — без запуска программы.
Мы анализируем требования, макеты, документацию, тесты или код.
Динамическое тестирование — с запуском программы.
Мы проверяем, как система реально работает при выполнении сценариев.
Статическое тестирование помогает найти проблемы раньше.
Динамическое тестирование помогает убедиться, что продукт работает фактически.
Для хорошего QA важны оба подхода.
Потому что задача тестировщика — не просто найти баг в готовом приложении, а помочь команде сделать так, чтобы часть багов вообще не дошла до пользователя.