К списку уроков
Блок 3 · Теория тестирования

Урок 7. Виды тестирования

Полная классификация

Темы урока

Функциональное/нефункциональное, ручное/автоматизированное, чёрный/белый/серый ящик, Smoke/Sanity/Regression/E2E/Ad-hoc/Exploratory, пирамида тестирования

Видео урока

Пройти тест по уроку

Конспект урока

Главное за урок

«Я всё проверил» — пустая фраза. «Всё» нельзя проверить ни в магазине, ни в банке, ни в калькуляторе. QA выбирает вид проверки под риск: что может сломаться и насколько это больно.

Вид тестирования — это ответ на вопрос «какую опасность ловим». Smoke спрашивает: магазин вообще жив? Regression спрашивает: после правки ничего старого не сломали? E2E спрашивает: реальный пользователь пройдёт путь от товара до заказа?

Одна проверка может относиться сразу к нескольким видам. Классификация — это не коробки, а разные линзы, через которые QA смотрит на одну проверку.


Функциональное vs нефункциональное тестирование

Что проверяем Пример
Функциональное Что продукт делает Промокод QA60 применяет скидку 10%
Нефункциональное Как хорошо он это делает Страница каталога загружается менее чем за 2 сек

Функция «работает» ещё не значит, что продуктом приятно и безопасно пользоваться. Нефункциональное включает: производительность, надёжность, безопасность, удобство (UX), совместимость.


Ручное vs автоматизированное тестирование

Это способ проверки, а не уровень крутости QA.

  • Manual нужен, когда важны здравый смысл, UX, исследование и быстрые вопросы к продукту.
  • Automation полезна для повторяемых проверок: регресс перед релизом, API, корзина, промокод.

Хороший QA не спорит «ручное или авто», а выбирает инструмент под задачу и стоимость ошибки.


Чёрный, белый и серый ящик

Вид Что видит QA Где применяется
Black-box Только интерфейс в браузере Ручное тестирование функций
White-box Код, внутренние условия Unit-тесты, code review разработчиков
Grey-box Браузер + API, DevTools, логи Самый рабочий режим для QA

Smoke, Sanity и Regression: в чём разница

Smoke — «магазин вообще жив?»

Проверяем главный путь: открыть, добавить товар, оформить заказ, увидеть popup с номером. Цель: понять, пригодна ли сборка для дальнейшего тестирования. Это не поиск всех багов — это быстрый старт.

Аналогия: перед поездкой проверяем, заводится ли машина, а не разбираем двигатель.

Sanity — «конкретная правка выглядит здраво?»

Починили промокод — проверяем только промокод, скидку и итоговую сумму. Уже, чем smoke: не обходим весь продукт, а смотрим зону изменения.

Аналогия: после ремонта одной розетки не проверяем всю электрику в доме.

Regression — «старое не сломалось?»

Поменяли корзину — проверяем не только её, но и каталог, количество, доставку, checkout и popup заказа. Ловит неприятное: «мы починили одно, но случайно сломали другое».

Аналогия: после ремонта кухни смотрим, не перестала ли течь вода в ванной.

Re-test vs Regression

  • Re-test — подтверждаем, что конкретный баг исправлен: QA60 снова даёт скидку.
  • Regression — проверяем соседние зоны: сумма, доставка, checkout, popup, очистка корзины.

E2E — история пользователя от начала до конца

Полный путь: открыть каталог → найти пиццу → добавить в корзину → применить промокод → оформить заказ → увидеть popup с номером.

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


Пирамида тестирования

         / E2E \          ← мало, медленные, дорогие
        /--------\
       /Integration\      ← стыки: UI+API, сервис+сервис
      /------------\
     /  Unit Tests  \     ← много, быстрые, дешёвые
    /-----------------\
  • Unit — проверяют маленькие куски логики: расчёт скидки, валидацию промокода.
  • Integration — проверяют стыки: каталог + корзина, UI + API, промокод + итоговая сумма.
  • E2E — полный путь пользователя. Меньше всего: полезные, но медленные и чаще ломаются из-за окружения.

Ad-hoc и Exploratory тестирование

Ad-hoc — свободная проверка, но не хаос

  • Плохой ad-hoc: «покликал что-то 40 минут и не помню что».
  • Хороший ad-hoc: «10 минут смотрю корзину, количество, недоступный товар и странные действия пользователя».

Exploratory — расследование с целью и таймером

  • Цель: исследовать промокоды, товар не в наличии, быстрые клики +/-.
  • Time-box: 20 минут, чтобы не утонуть в бесконечном «ещё чуть-чуть проверю».
  • Результат: найденные баги, вопросы к требованиям, риски и список того, что сознательно не проверяли.

Примеры классификации на «Пиццаеде»

Проверка Виды тестирования
Открыть магазин, добавить «Маргариту», оформить заказ Smoke, Functional, Manual, Black-box
QA60 применяет скидку 10%, итоговая сумма пересчиталась Sanity, Functional, Re-test
После правки корзины: каталог, количество, доставка, checkout Regression
Каталог → товар → корзина → промокод → заказ → popup E2E
«Чизкейк» недоступен, его нельзя добавить Functional, Negative, Black-box

Ключевые тезисы для теста

  • Функциональное — что делает продукт; нефункциональное — как хорошо он это делает.
  • Manual vs automation — это способ проверки, не уровень квалификации.
  • Grey-box — самый рабочий режим QA: браузер + API + DevTools.
  • Smoke — «жив ли продукт»; sanity — «здравая ли правка»; regression — «ничего старого не сломалось».
  • Re-testregression: re-test проверяет конкретный фикс, regression — соседние зоны.
  • E2E — полный путь пользователя, дорогой и медленный, но ближайший к реальному опыту.
  • Пирамида: unit — много, integration — средне, E2E — мало.
  • Exploratory — целенаправленное исследование с time-box и фиксацией результата.
  • Одна проверка может относиться сразу к нескольким видам тестирования.

Полезные ссылки