Большинство QA-автоматизаторов не вписываются чисто ни в одну категорию: тестируют видимое поведение с точки зрения пользователя (чёрный ящик), но при этом знают структуру API, читают код чтобы понять граничные случаи, и смотрят отчёты о покрытии чтобы найти пробелы (элементы белого ящика). Различие важно потому что каждый подход оптимизирован для разных багов: чёрный ящик ловит несоответствия требованиям и сбои поведения UI, белый ящик ловит непроверенные пути в коде и ошибки внутренней логики. Здесь разобрано что покрывает каждый подход, какие техники к нему относятся, и как все три режима появляются на одной фиче в типичном спринте.

Тестирование чёрного ящика

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

Тестирование строится исключительно на требованиях («когда пользователь вводит X, должно произойти Y»), спецификациях («поле принимает от 1 до 100 символов») и ожиданиях пользователей («это должно работать как любая стандартная форма входа»).

В код не смотришь. Не знаешь, или по крайней мере не опираешься на знание, какой фреймворк используется, как хранятся данные, или какой алгоритм выполняет вычисление.

Как выглядит тестирование чёрного ящика

  • Тестирование формы входа путём ввода валидных и невалидных данных
  • Проверка что клик «Добавить в корзину» добавляет правильный товар
  • Проверка что API возвращает нужные данные для корректного запроса
  • Подтверждение что сообщение об ошибке появляется при пустом обязательном поле
  • Запуск end-to-end тестов в Playwright

Техники тестирования чёрного ящика

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

Преимущества

  • Тестируешь то что реально видят пользователи, а не то что, по мнению разработчиков, они видят
  • Не требует знания программирования (для функционального тестирования чёрного ящика)
  • Ловит несоответствия требованиям: когда спецификация говорит одно, а реализация делает другое
  • Работает с первого дня, ещё до того как система построена (можно писать тест-кейсы из требований)

Недостатки

Можно пропустить пути в коде которые явно не покрыты никаким требованием (мёртвый код, ветки ошибок). Без знания кода можно многократно тестировать одну и ту же логику и полностью упустить другие пути. Нельзя проверить то что не видно снаружи (утечки памяти, внутреннее повреждение данных).

Тестирование белого ящика

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

Также называется: стеклянный ящик, прозрачный ящик, структурное тестирование, тестирование на основе кода.

Как выглядит тестирование белого ящика

  • Написание юнит-тестов которые вызывают функции напрямую и проверяют их поведение
  • Просмотр условной ветки в коде и написание теста для каждой ветки
  • Анализ какие пути в коде не покрыты ни одним существующим тестом
  • Проверка что конкретный SQL-запрос выполняется корректно
  • Тестирование внутренних API или методов которые не раскрываются в UI

Техники тестирования белого ящика

  • Покрытие операторов: каждая строка кода выполняется хотя бы раз тестами
  • Покрытие ветвей: каждая ветка if/else выполняется хотя бы раз
  • Покрытие путей: каждый возможный путь через код тестируется
  • Мутационное тестирование: намеренное изменение кода чтобы проверить что тесты это замечают

Кто это делает

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

Как QA-автоматизатор ты находишься на этом спектре: не пишешь юнит-тесты, но читаешь код чтобы понять что тестировать, и смотришь отчёты о покрытии чтобы найти пробелы.

Преимущества

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

Недостатки

  • Требует знания реализации: нужны навыки программирования
  • Может привести к тестированию реализации вместо требований (предвзятость подтверждения: тестируешь что код делает, а не что он должен делать)
  • Не поймает корректную реализацию неверного требования
  • Затратно по времени для достижения высокого покрытия

Тестирование серого ящика

На практике большинство QA-автоматизаторов работают в серой зоне: знают часть внутренностей, но тестируют с точки зрения пользователя.

Тестирование серого ящика означает:

  • Знаешь архитектуру (REST API, база данных, фронтенд) но тестируешь внешнее поведение
  • Читаешь базовый код чтобы понять настройку тестовых данных, но не пишешь юнит-тесты
  • Используешь тестирование на уровне API (зная структуру эндпоинтов) в поддержку UI-тестирования
  • Смотришь в код чтобы понять граничные случаи, но проектируешь тесты с точки зрения пользователя

Здесь живёт большинство современных QA-инженеров. Не чисто чёрный ящик (знаешь стек технологий) и не чисто белый ящик (не пишешь юнит-тесты для внутренних функций).

Сравнение

| | Чёрный ящик | Белый ящик | Серый ящик |

|-|-------------|------------|------------|

| Нужные знания | Только требования | Полный доступ к коду | Архитектура + базовый код |

| Тесты основаны на | Спецификациях, пользовательских флоу | Логике кода, покрытии | И том и другом |

| Кто делает | QA-тестировщики, пользователи | Разработчики, QA-инженеры | QA-автоматизаторы |

| Ловит | Несоответствия требованиям, UI-баги | Логические баги, непокрытый код | Обе категории |

| Пропускает | Баги внутренней логики | Неверные требования | (минимизировано) |

| Пример | Тестирование формы входа | Юнит-тесты логики аутентификации | API-тестирование + E2E |

Как это выглядит в реальном проекте

День 1. Фича пришла: Получаешь пользовательские истории и критерии приёмки. Пишешь тест-сценарии на их основе (чёрный ящик: кода ещё нет). Фаза разработки: Разработчики пишут юнит-тесты покрывающие пути в коде (белый ящик). Фаза тестирования: Выполняешь свои тест-сценарии на построенной фиче (чёрный ящик). Также вызываешь API напрямую чтобы настроить тестовые данные (серый ящик: знаешь структуру эндпоинта). Найден баг: Смотришь в код чтобы понять почему возникает граничный случай (знание белого ящика), но заводишь баг против поведения, а не реализации (репорт чёрного ящика). Ревью покрытия: Проверяешь какие области не имеют автотестов и сигнализируешь команде (перспектива белого ящика применённая к планированию).

Все три режима на одной фиче, в одном спринте.

На собеседованиях по QA

Классический вопрос: «Объясните разницу между тестированием чёрного и белого ящика.»

Ожидаемый ответ. Чёрный ящик: тестирование без знания внутренностей, на основе требований и поведения пользователя. Белый ящик: тестирование со знанием кода, на основе покрытия логических путей. Серый ящик (опционально): сочетание обоих, типично для автоматизаторов которые знают архитектуру но тестируют с точки зрения пользователя.

Уточняющий вопрос: «Что делаете вы?»

Честный ответ для большинства QA-автоматизаторов: преимущественно чёрный ящик (E2E-тестирование видимого поведения) с элементами серого (знание API, чтение кода чтобы понять настройку тестовых данных, просмотр отчётов о покрытии).

→ See also: Пирамида тестирования: объяснение для QA-инженеров | Верификация vs валидация в тестировании ПО: в чём разница? | Исследовательское тестирование: навык, который не заменит ИИ