Вопрос «какие бывают виды тестирования» задают почти на каждом собеседовании джуна. Хороший ответ не перечисляет сорок терминов подряд, а раскладывает их по нескольким классификациям.
Уровни тестирования
Уровень отвечает на вопрос «что именно мы проверяем: кусочек или всё целиком».
| Уровень | Что проверяет | Кто обычно |
|---|---|---|
| Модульное (компонентное) | Одну функцию, класс, компонент в изоляции, зависимости заглушены | Разработчики |
| Интеграционное компонентов | Стыки модулей внутри системы | Разработчики, тестировщики |
| Системное | Систему целиком по требованиям | Тестировщики |
| Системное интеграционное | Связь системы с внешними: платёжка, CRM, доставка | Тестировщики |
| Приёмочное | Готовность для заказчика и пользователей: UAT, альфа, бета | Заказчик, пользователи, тестировщики |
Альфа-тестирование проходит внутри компании, бета у части реальных пользователей до широкого релиза.
Функциональное и нефункциональное
- Функциональное: что делает система. Поиск находит товар по артикулу, фильтр отсекает дорогие товары.
- Нефункциональное: как она это делает. Производительность, безопасность, удобство, доступность, совместимость, надёжность, локализация.
Внутри производительности различают:
- нагрузочное: ожидаемая и пиковая нагрузка, держит ли время ответа;
- стресс: за пределами нагрузки, как система деградирует и восстанавливается;
- стабильности (soak): долгая нормальная нагрузка, ищем утечки памяти.
Чёрный, белый и серый ящик
- Чёрный ящик: проверяем по требованиям, не зная устройства.
- Белый ящик: опираемся на код, например, добиваемся покрытия всех ветвей.
- Серый ящик: знаем архитектуру, схему БД, смотрим логи, но проверяем через внешние интерфейсы. Так работает большинство тестировщиков API.
Виды, связанные с изменениями
Здесь больше всего путаницы, разберём на примере. Разработчик исправил баг в расчёте корзины и выложил сборку.
- Smoke: широко и поверхностно. Сборка запускается, логин, каталог и корзина открываются. Если smoke упал, дальше тестировать бессмысленно.
- Ретест (подтверждающее тестирование): повторяем шаги из баг-репорта. Баг исправлен?
- Sanity: узко и чуть глубже вокруг изменения. Корзина считает правильно в соседних случаях?
- Регрессия: не сломалось ли то, что работало. Оформление заказа, промокоды, история заказов.
smoke широко, мелко «можно ли тестировать сборку?»
sanity узко, глубже «работает ли изменённое?»
ретест один баг «исправлен ли он?»
регресс всё затронутое «не сломали ли старое?»
Пирамида тестирования
Внизу много быстрых и дешёвых модульных тестов, выше меньше интеграционных, на вершине немного сквозных UI-тестов. Чем выше, тем медленнее, дороже и хрупче. Перевёрнутая пирамида («рожок мороженого»), где основная масса проверок это UI и ручная регрессия, считается антипаттерном: регрессия идёт днями, а падения трудно диагностировать.
Контрактное тестирование
В микросервисах полезен ещё один вид: потребитель API фиксирует свои ожидания в контракте (например, с помощью Pact), а поставщик проверяет контракты в своём CI. Так ломающее изменение видно до слияния, без подъёма всех сервисов.
Частые ошибки
- Путать ретест и регрессию: ретест про конкретный баг, регрессия про побочные эффекты.
- Называть smoke и sanity синонимами без объяснения разницы.
- Считать, что регрессия это «прогнать все тест-кейсы». На практике её объём выбирают по анализу влияния и рискам.
- Забывать, что приёмочное тестирование это уровень, а альфа и бета его виды.
Что спросят на собесе
- Какие уровни тестирования ты знаешь?
- Чем smoke отличается от sanity, а ретест от регрессии?
- Что такое чёрный, белый и серый ящик?
- Что такое пирамида тестирования и почему «рожок мороженого» плох?
- Как выбрать объём регрессии, если времени мало?