Нужно прекратить использовать термины «тестирование белого/черного ящика»

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

В книге Дженнифер Эберхардт «Предвзятость: раскрытие скрытых предубеждений, формирующих то, что мы видим, думаем и делаем» (“Biased: Uncovering the Hidden Prejudice That Shapes What We See, Think, and Do”; Jennifer Eberhardt) сказано: «Категоризация — группировка схожих вещей — является не какой-то отвратительной особенностью человеческого мозга, а процессом, в который одни люди вовлечены, а другие нет. Скорее, это универсальная функция мозга, которая позволяет нам организовывать и управлять раздражителями, которые постоянно нас бомбардируют, чтобы не допустить перегрузки». 

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

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

Поддержание стереотипов

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

Почему считается, что во время тестирования белого ящика вы можете «видеть код»? Если подумать, в случае белого ящика вы не увидели бы его содержимое. Поразмышляете вот над чем: обычно потолок выкрашивается в белый цвет. Можно ли сквозь него увидеть небо или своих соседей? Как можно сделать обычным тот факт, что «белый ящик» каким-то образом является прозрачным?

Категория юнит-тестов — хамелеон

Если бы я спросил вас, к какой категории относятся юнит-тесты, могу поспорить, что большинство ответило бы, что к белому ящику, потому что в процессе тестирования «виден код». Однако, если вы думаете в рамках TDD, вы бы написали тесты ДО кода и, таким образом, кода вы бы не видели, что по определению нельзя назвать белым ящиком.

В чем на самом деле разница между юнит-тестами, которые находятся в основании пирамиды тестирования, и другими видами тестов?

В том, что юнит-тесты и код пишет один и тот же человек? Но то же самое можно сказать и о других.

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

Прозрачный vs непрозрачный

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

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

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

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

Как и в примере выше, серый — это тоже (непрозрачный) цвет, и если коробку покрасить в такой цвет, не получится увидеть его содержимое. Даже частично. И что нам использовать взамен этого, чтобы оно соответствовало заявленному термину? Коробка с отверстиями? Частично прозрачная коробка? (например, с пластиковыми «окошками»). Не совсем понятно. Какие именно тесты следует отнести в эту категорию? 

Тестировщики редко работают с белым ящиком

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

Цикломатическая сложность редко рассчитывается вручную, хотя иногда встречается на код-ревью. В основном это часть процесса оптимизации кода.

Тестирование операторов, тестирование граничных значений, тестирование ветвей, циклическое тестирование, тестирование потока данных — это техники, которые редко планируются, проверяются и зачастую автоматизируются. Многие из этих терминов до сих пор неизвестны или не используются многими специалистами в нашей отрасли.

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

Структурность vs логика

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

Определение будет зависеть от того, занимаетесь ли вы тестированием структуры кода (количество ветвей, корректная обработка исключений и т.д.) или бизнес-логики реализуемых фичей (например, логика «в корзине должно оставаться 0 товаров после покупки»).

Что насчет бэкенд-тестирования / интеграционного тестирования или тестирования базы данных? То же самое: в случае если вы тестируете структуру базы данных, тестирование можно назвать структурным, а если на его логику, то тестирование логики.

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

В заключение

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

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

Как сказал Мигель Руис в своей книге «Четыре соглашения: Практическое руководство к достижению личной свободы» (The Four Agreements: A Practical Guide to Personal Freedom, Don Miguel Ruiz), вы должны быть «безупречны в своих словах». Не будет ли хорошим стартом начать использовать термины структурного тестирования и тестирования логики вместо тестирования методами черного и белого ящика?

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