Есть два набора терминов, которые новичок встречает сразу и часто путает. Первый — про то, сколько вы знаете о внутренностях программы, когда её проверяете (ящики). Второй — про зачем вы запускаете конкретный прогон (smoke, регресс, sanity). Разберём оба, они простые.
Чёрный ящик: проверяем снаружи
Чёрный ящик (black box) — вы не знаете и не смотрите, как программа устроена внутри. Вы работаете с ней как обычный пользователь: есть вход (что ввели, куда нажали) и выход (что получили). Внутренности — «чёрный ящик», не видно.
Пример: проверяете форму входа. Вводите логин и пароль, смотрите, пустили или нет. Как именно код проверяет пароль — вам неважно. Важно поведение снаружи.
Это основной подход ручного тестировщика. Большинство ваших проверок — чёрный ящик: вы смотрите на продукт глазами пользователя, а не в код.
Белый ящик: проверяем изнутри
Белый ящик (white box) — наоборот, вы видите код и проверяете его внутреннюю логику: все ли ветки «если — то» отработали, нет ли забытых случаев. Для этого нужно уметь читать код.
Это в основном работа разработчиков (модульные тесты — как раз белый ящик). Ручному тестировщику глубоко в код лезть обычно не нужно, но полезно знать, что такой взгляд существует и что часть багов ловится именно там, ещё до вас.
Серый ящик: немного знаем внутренности
Серый ящик (grey box) — золотая середина. Вы проверяете снаружи, как пользователь, но при этом кое-что знаете о внутренностях и используете это.
Пример: проверяете оформление заказа как пользователь (чёрный ящик), но заодно заглядываете в базу данных — правда ли заказ там сохранился и с верным статусом. Или смотрите в панель Network браузера, какой запрос ушёл на сервер. Вы не читаете код, но пользуетесь знанием, что и где происходит.
На практике опытный ручной тестировщик почти всегда работает в сером ящике: снаружи проверяет поведение, а внутренними инструментами уточняет, что реально произошло.
Smoke, регресс, sanity — зачем прогон
Эти три слова описывают не что проверяют, а с какой целью запускают набор проверок.
- Smoke (дымовое). Быстрая проверка, что продукт вообще живой и не рухнул: открывается ли, работают ли главные функции. Как «включить прибор и посмотреть, не пошёл ли дым». Делают первым делом на новой сборке: если smoke не прошёл, дальше тестировать бессмысленно — сначала пусть починят.
- Регрессионное (регресс). Проверка, что после новых изменений старое всё ещё работает. Самая частая ловушка в разработке: чинят одно — ломают соседнее. Регресс это ловит. Именно регресс чаще всего автоматизируют, потому что его гоняют снова и снова.
- Sanity (проверка на вменяемость). Узкая быстрая проверка конкретной починки или маленькой функции: работает ли именно то, что только что поправили, без полного прогона всего.
И ещё один термин рядом:
- Повторное тестирование (re-test). Проверка конкретного бага после того, как его пометили исправленным: ушёл ли он. Не путать с регрессом: re-test — «этот баг починили?», регресс — «а не сломалось ли при этом что-то ещё?».
Где это применяется
Эти термины — язык, на котором с вами будут разговаривать в команде. «Прогони smoke на новой сборке», «нужен регресс перед релизом», «сделай re-test по этому багу» — вы должны понимать, что от вас хотят, без переспрашивания. А понимание ящиков определяет, какими инструментами вы пользуетесь: только интерфейсом или ещё базой и сетью.
Где спотыкаются начинающие:
- Путают re-test и регресс. Проверили, что баг ушёл, и решили, что закончили — а рядом уже что-то сломалось.
- Пропускают smoke и начинают детально тестировать сборку, которая в принципе не запускается как надо.
- Ограничивают себя чёрным ящиком, хотя быстрый взгляд в базу или сеть сразу показал бы причину странного поведения.
Что учить дальше. Теория закончилась — переходим к практике. Дальше как писать тест-кейс: как превратить «надо проверить регистрацию» в конкретные пошаговые проверки.