Ответ.

История вопроса:

С развитием массового выпуска программного обеспечения возникла необходимость быстро и качественно проверять функциональность продуктов без доступа к их внутренней реализации. Так появился метод "черного ящика", при котором тестировщик работает только с публичным интерфейсом приложения.

Проблема:

Без понимания кода можно пропустить некоторые внутренние ошибки или не протестировать определенные ветки выполнения. Тем не менее "черный ящик" позволяет тестировать глазами пользователя и выявлять проблемы с точки зрения пользователя.

Решение:

Метод "черного ящика" заключается в следующем:

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

Ключевые особенности:

Обеспечивает независимую оценку с точки зрения конечного пользователя
Покрывает только внешнее поведение системы
Не позволяет проверить внутренние ошибки реализации

Вопросы с подвохом.

Нужно ли знать программирование для тестирования по "черному ящику"?

Нет, для применения этого метода не требуется знание кода, главное — понимание функциональных требований.

Гарантирует ли метод "черного ящика" полное покрытие всех ошибок?

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

Можно ли применять только "черный ящик" при тестировании сложных корпоративных сервисов?

Нет, желательно комбинировать с другими методами ("белого ящика"), чтобы достичь максимально возможного покрытия.

Типовые ошибки и анти-паттерны

Тестирование только по UI без проверки API
Полное игнорирование документации (спецификаций)
Отсутствие креативных негативных сценариев

Пример из жизни

Негативный кейс

Тестировщик проверял банковское приложение только по "черному ящику", вводя стандартные данные через интерфейс и не обращал внимания на работу с внутренним балансом (API не тестировался).

Плюсы:

Быстрое тестирование по пользовательским сценариям

Минусы:

После запуска выяснилось, что при повторных операциях происходило списание лишних средств (внутренний баг, не проявлявшийся явно на UI)

Позитивный кейс

Тестировщик комбинировал тестирование: сначала провел функциональное тестирование по "черному ящику", описав пользовательские сценарии, а затем, совместно с разработчиком, проверил API и данные в БД.