Почему оба подхода до сих пор существуют? Разве тестирование с доступом к коду не эффективнее? Может существует золотая середина? Давайте разбираться.

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

Черный ящик

Разработка тестов методом черного ящика (black box test design technique) — процедура создания и/или выбора тестовых сценариев, основанная на анализе функциональной или нефункциональной спецификации компонента или системы без знания внутренней структуры. (ISTQB)

________________________________

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

________________________________

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

Получается, что идеи для тестирования идут от предполагаемых паттернов (pattern — образец) поведения пользователей. Поэтому такой подход еще называют поведенческим.

Пример. Заходим в приложение вызова такси и видим возможность привязать карту для автоматической оплаты. Начинаем думать как пользователь:
— Что, если привязать заблокированную карту?
— А если забыть/неверно указать срок действия карты?
— Долларовая карта привяжется?
— А может можно после вызова такси и подачи машины быстро отвязать ее до списания оплаты… Что тогда будет? Спишутся средства? Или водителю придет уведомление, что оплата изменилась с безналичной на наличную?

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

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

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

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

• Тестировщик не обязан обладать (глубокими) знаниями в области программирования.
• Поведение приложения исследуется в контексте реальной среды выполнения и учитывает её влияние.
• Поведение приложения исследуется в контексте реальных пользовательских сценариев.
• Тест-кейсы можно создавать уже на стадии появления стабильных требований.
• Процесс создания тест-кейсов позволяет выявить дефекты в требованиях.
• Допускает создание тест-кейсов, которые можно многократно использовать на разных проектах.

Недостатки:

• Возможно повторение части тест-кейсов, уже выполненных разработчиками.
• Высока вероятность того, что часть возможных вариантов поведения приложения останется непротестированной.
• Для разработки высокоэффективных тест-кейсов необходима качественная документация.
• Диагностика обнаруженных дефектов более сложна в сравнении с техниками метода белого ящика.
• В связи с широким выбором техник и подходов затрудняется планирование и оценка трудозатрат.
• В случае автоматизации могут потребоваться сложные дорогостоящие инструментальные средства.

Белый ящик

Разработка тестов методом белого ящика (white-box test design technique): Процедура разработки или выбора тестовых сценариев на основании анализа внутренней структуры компонента или системы. (ISTQB)

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

________________________________

Основной посыл этого типа тестирования — нам известны все детали реализации тестируемой программы.

________________________________

Тестирование методом белого ящика (прозрачного, открытого, стеклянного ящика, основанное на коде или структурное тестирование) – метод тестирования программного обеспечения, который предполагает, что внутренняя структура/устройство/реализация системы известны тестировщику.

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

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

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

• Показывает скрытые проблемы и упрощает их диагностику.
• Допускает достаточно простую автоматизацию тест-кейсов и их выполнение на самых ранних стадиях развития проекта.
• Обладает развитой системой метрик, сбор и анализ которых легко автоматизируется.
• Стимулирует разработчиков к написанию качественного кода.
• Многие техники этого метода являются проверенными, хорошо себя зарекомендовавшими решениями, базирующимися на строгом техническом подходе.

Недостатки:

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

Серый ящик. Отдельный вид или миф?

Его основной посыл в том, что нам известны только некоторые особенности реализации тестируемой системы.

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

Эту технику тестирования также называют методом полупрозрачного ящика: что-то мы видим, а что-то – нет.

Кто-то говорит, что этот вид тестирования — это симбиоз белого и черного ящика. Кто-то противопоставляет его белому и черному, опираясь на то, что внутренняя структура тестируемого объекта изначально известна частично и выясняется по мере исследования.

ISTQB относит тестирование методами белого и черного ящика к методам проектирования тестов. Поэтому, ни о каком «среднем» или «промежуточном» методе в этом случае конечно и речи быть не может. Мы либо разрабатываем тесты, зная код, либо не зная его. То есть в классификации ISTQB такого вида тестирования не существует.

Думаю, что на собеседовании это явно стоит упомянуть.

Почему все ящики эффективны?

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

Параллельное использование черного и белого ящиков увеличивает покрытие возможных сценариев:

• количественно, потому что появляется большее количество тест-кейсов,
• качественно, потому что ПО тестируется принципиально разными подходами: с точки зрения пользователя («Черный ящик») и с точки зрения “внутренностей”.

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

_______
Напомню, что для каждого ящика тестирования есть свой набор техник тест-дизайна. Ведь это не просто виды тестирования, а методы проектирования тестов. Почитать об этих техниках можно тут https://vk.com/@zapiskisedogotestera-obzor-tehnik-test-dizaina