Покупатель собрал заказ на 3000 рублей и списал 500 бонусов. На экране «к оплате 2500», с карты ушло 3000, а бонусы исчезли. Вы заводите задачу «списывается больше, чем показано», разработчик отвечает: «у нас сумма считается правильно, покажи, где именно ломается».
Что вы сможете ответить, зависит от того, что вам видно: только экран — опишете симптом; есть журнал приложения и база — за пять минут видно, какая сумма ушла на оплату; читаете код — найдётся конкретная строка. Эти три режима и называют ящиками — чёрный, белый и серый: «ящик» тут не про должность и не про уровень мастерства, а про то, сколько слоёв продукта вам открыто в момент поиска причины.
Слова «дымовой набор» (smoke), «регресс» и «санитарная проверка» с ящиками часто путают: они отвечают не на «сколько видно», а на «зачем сейчас запускают этот набор», и разобраны в статье про виды тестирования.
Режим — это не звание, а то, сколько слоёв вам открыто. Снаружи причина может быть в любом месте пути заказа; журнал и база сужают её до одного шага; код — до строки. Средняя строка и есть обычный рабочий день ручного тестировщика.
Чёрный ящик: работаем с тем, что видит человек
Доступ к журналу ещё не выдали, база закрыта, код вы не читаете — так выглядят первые недели почти у всех, и большую часть находок приносит именно такая работа. Проверка, опирающаяся только на вход и выход продукта, и называется чёрным ящиком (black box): что ввели, куда нажали — и что получили.
Идеи берутся из двух источников. От требований: каждое обещание превращается в проверку — «бонусами можно оплатить не больше половины заказа» даёт проверку на ровно половину, на половину плюс рубль и на попытку списать всё. От поведения: требований часто нет вовсе, и тогда вы идёте от того, что продукт позволяет сделать — в поле для бонусов можно ввести ноль, дробное число, сумму больше остатка, буквы, минус; выбрать из этого десяток осмысленных значений помогают техники тест-дизайна.
Слепая зона у режима честная: снаружи видно, что результат неверный, но не видно, где он испортился. Один экран скрывает три причины — не посчитали; посчитали, но не показали; показали, но не сохранили. В задаче вы напишете одну фразу «сумма неверная», а чинить их будут в трёх разных местах.
Белый ящик: смотрим в сам код
Снаружи не видно ветвлений. Функция, которая считает скидку, может содержать пять условий «если — то», и до двух снаружи почти не добраться: они срабатывают, когда сервис бонусов ответил ошибкой или когда бонусы начислены и списаны в одну секунду. Проверка от текста программы, а не от экрана, называется белым ящиком (white box); занимаются им в основном разработчики — модульные тесты и есть белый ящик.
Видны все ветки и то, какие строки выполнялись во время прогона. Последнее называют покрытием, и это самое опасное слово в теме: строка выполнилась — не значит, что кто-то сравнил результат с требованием.
Главная грабля — посмотрел код и проверил только то, что там написано. Код перестаёт быть предметом проверки и становится эталоном, а эталон обязан быть требованием: забыл разработчик случай «бонусов на счету больше, чем стоит заказ» — в коде его нет, в ваших проверках тоже, и все они зелёные. Лечится порядком действий: сначала проверки от требований и от поведения, потом код — и только на добавление. Вычёркивать на основании «в коде этого случая нет» нельзя: это и есть находка.
Серый ящик: снаружи проверяем, внутрь заглядываем
Между симптомом снаружи и чтением кода лежит режим, в котором ручной тестировщик проводит почти всё рабочее время: вы проверяете продукт снаружи, но вдобавок видите часть внутренностей. Это серый ящик (grey box), и заглядывают обычно в четыре места.
Вкладка «Сеть» в браузере показывает, что ушло на сервер и что он ответил, — дешёвая проверка версии «экран показывает не то, что отправляет». Журнал приложения на стенде — что сервис записал сам о себе: принял запрос, обратился к соседу, ждал ответа тридцать секунд. База данных — что в итоге сохранилось: заказ со статусом «черновик», бонусы списаны, а сумма прежняя; пары запросов хватает, чтобы отличить «не сохранили» от «сохранили и не показали». Прямой запрос мимо экрана через Postman: если напрямую сумма верная, дело не в расчёте, а в том, что отправляет экран.
Вы перестаёте описывать симптом и начинаете указывать место: «на экране 2500, в запросе на оплату уходит 3000, бонусы в базе списаны» — такой баг-репорт попадает к нужному человеку сразу. От режима зависит и то, что вы обещаете в отчёте: «проверено снаружи, в базу не смотрел» и «данные в базе сходятся» — разные обещания.
Грабля тут одна, зато дорогая: не посмотрел в журнал и час гадал. Экран крутит колесо после «Оплатить», тестировщик меняет карту, перезаходит, чистит кэш, зовёт соседа — час работы, а в журнале первая же строка: «сервис бонусов не ответил за 30 секунд». Правило: пять минут снаружи — и, если причина не очевидна, идём внутрь, не наоборот.
Смотреть внутрь можно свободно, менять — осторожно: правка данных прямо в базе даёт состояние, которого продукт сам сделать не умеет, и полдня уходит на баг, которого нет. Вывод из журнала — наблюдение, а не диагноз: «в журнале ошибка сервиса бонусов» — факт, «причина в сервисе бонусов» — уже догадка.
Одна ошибка, три режима: заказ с бонусами
Вернёмся к заказу: на экране 2500, с карты ушло 3000, 500 бонусов исчезли.
Снаружи. Вы повторяете путь, меняя по одному условию. Другая сумма — то же самое. Бонусы, введённые в поле вручную, — ошибки нет. Бонусы, списанные кнопкой «списать все», — воспроизводится каждый раз. Кода вы не видели, в базу не заглядывали, но нашли главное: разные пути дают разный результат, и задача не вернётся со словами «у меня не воспроизводится».
Изнутри. В «Сети» видно, что в запросе на оплату стоит 3000, хотя на экране 2500. В журнале есть успешная строка о списании 500 бонусов. В базе у заказа сумма 3000 и отметка о применённых бонусах. Вывод: бонусы списались, а сумма к оплате не пересчиталась — место поиска сузилось с «весь путь заказа» до одного шага.
Насквозь. Разработчик открывает код: пересчёт вызывается в обработчике поля ввода, а кнопка «списать все» подставляет значение мимо этого обработчика. Одна ветка, до которой не добрались ни модульные тесты, ни проверки по требованиям.
Полезная находка появилась уже в чёрном ящике: серый ящик не обязателен, он экономит команде сутки и снимает разбор с разработчика.
Коротко
- Ящик — не должность и не уровень мастерства, а количество слоёв продукта, которые вам видно: чем больше видно, тем уже место поиска.
- Чёрный ящик работает от требований и от поведения. Он приносит симптом, но не место: «не посчитали», «не показали» и «не сохранили» выглядят снаружи одинаково.
- Белый ящик — проверка от текста программы; покрытие означает только то, что строка выполнилась. Опасность в том, что код становится эталоном вместо требования: забытый случай не найдётся никогда.
- Серый ящик — обычный рабочий режим: экран плюс «Сеть», журнал, база и прямой запрос к сервису. Правило пяти минут: снаружи не очевидно — идём внутрь.
- Смотреть внутрь можно свободно, менять — осторожно: правка данных в базе ломает условия воспроизведения, а строка из журнала — наблюдение, а не диагноз.
Что почитать дальше
- Виды тестирования: функциональное и нефункциональное — дымовой набор, регресс, санитарная и повторная проверки.
- Уровни тестирования — где живут проверки белого ящика и почему зелёный модульный прогон не спорит с вашей находкой.
- DevTools браузера для тестировщика — как за минуту увидеть, что экран отправил на сервер.
- SQL для тестировщика — пара запросов, которые отличают «не сохранили» от «сохранили и не показали».