Урок 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-test ≠ regression: re-test проверяет конкретный фикс, regression — соседние зоны.
- E2E — полный путь пользователя, дорогой и медленный, но ближайший к реальному опыту.
- Пирамида: unit — много, integration — средне, E2E — мало.
- Exploratory — целенаправленное исследование с time-box и фиксацией результата.
- Одна проверка может относиться сразу к нескольким видам тестирования.
Полезные ссылки
- Эфиры Сергея на YouTube: https://www.youtube.com/@qabigtech/streams
- Чат марафона: https://t.me/+-utD4gcZaG82MTky
- Telegram-канал Сергея: https://t.me/qabigtech
- Учебный магазин «Пиццаед»: /base/shop
- Требования к «Пиццаеду»: /base/shop/requirements