Перед релизом редко бывает время проверить абсолютно всё заново. Нужно уметь быстро решить: что проверить прямо сейчас, а что можно пропустить без риска. Для этого у тестировщика есть четыре разных по охвату вида проверок — смоук, санити, регресс и ретест — и общее понимание того, как устроено автоматизированное покрытие тестами, которое называют пирамидой тестирования.
Чему научишься за этот урок:
— различать смоук, санити, регресс и ретест по охвату и моменту применения;
— выбирать минимально достаточный набор проверок перед релизом при нехватке времени;
— понимать идею пирамиды тестирования (unit → интеграционные → e2e).
Смоук-тестирование (smoke testing)
Смоук-тестирование — быстрая ПОВЕРХНОСТНАЯ проверка того, что система вообще «не развалилась» и её ОСНОВНЫЕ функции работают, без углубления в детали. Обычно это первое, что делает тестировщик сразу после получения новой сборки — чтобы решить, стоит ли вообще тратить время на подробное тестирование этой сборки.
Санити-тестирование (sanity testing)
Санити-тестирование — более УЗКАЯ и СФОКУСИРОВАННАЯ проверка КОНКРЕТНОЙ области или функции сразу после НЕБОЛЬШОГО изменения в ней. Цель — убедиться, что именно эта область работает разумно, без полного регресса всей системы.
Регрессионное тестирование (regression testing)
Регрессионное тестирование — повторная проверка РАНЕЕ РАБОТАВШЕГО функционала ПОСЛЕ изменений в коде, чтобы убедиться, что эти изменения не сломали что-то другое, что раньше работало корректно. В отличие от санити, охват здесь широкий — не одна область, а весь ранее работавший функционал.
Ретест (retest / confirmation testing)
Ретест (подтверждающее тестирование) — повторная проверка КОНКРЕТНОГО ранее найденного и предположительно исправленного дефекта, чтобы убедиться, что именно ЭТОТ баг действительно исправлен. Охват здесь узкий и точечный — в отличие от регресса, который смотрит шире, на остальной функционал.
Различай четыре вида по двум вопросам: (а) это про НОВУЮ сборку в целом или про ОДНУ область/баг? (б) охват узкий (одна область или один баг) или широкий (весь ранее работавший функционал)? Смоук — новая сборка в целом. Санити — одна область после мелкого изменения. Регресс — весь функционал после изменений. Ретест — один конкретный исправленный баг.
Пирамида тестирования
Пирамида тестирования — концепция про баланс УРОВНЕЙ АВТОТЕСТОВ (это не то же самое, что четыре уровня тестирования из урока про уровни, хотя термины похожи — там речь про этапы проверки продукта, здесь — именно про автоматизацию). В основании пирамиды — много тестов, они быстро выполняются и дёшевы в поддержке. На вершине — мало тестов, они медленно выполняются и дороги в поддержке.
E2E / UI [======] <- мало тестов, медленно и дорого в поддержке Интеграционные [==================] <- средне тестов, средняя скорость и цена Unit [==============================] <- много тестов, быстро и дёшево в поддержке
Идея пирамиды: не нужно проверять всё вручную через интерфейс целиком (e2e/UI), если что-то дешевле и надёжнее проверить на более низком автоматизированном уровне. Решение о том, автоматизировать проверку или нет, обычно принимает не ручной тестировщик — но важно понимать эту логику, когда команда обсуждает, что и как покрывать тестами.
Итог:
— смоук — быстрая поверхностная проверка новой сборки в целом («не развалилось ли всё»);
— санити — узкая проверка одной конкретной области сразу после небольшого изменения;
— регресс — широкая повторная проверка всего ранее работавшего функционала после изменений;
— ретест — точечная повторная проверка одного конкретного исправленного бага;
— пирамида тестирования — баланс уровней автотестов: unit (много, быстро, дёшево) → интеграционные (средне) → e2e/UI (мало, медленно, дорого).
Контрольный вопрос. Что такое смоук-тестирование?
Подсказка: Это первая проверка сразу после получения новой сборки — она решает, стоит ли вообще тратить время на сборку дальше.
Онлайн-проверка ответа появится позже
Контрольный вопрос. Что такое санити-тестирование?
Подсказка: Ключевой признак здесь — «конкретная область», а не вся система целиком.
Онлайн-проверка ответа появится позже
Контрольный вопрос. Что такое регрессионное тестирование?
Подсказка: Здесь охват широкий — не одна область и не один баг, а функционал, который раньше уже работал.
Онлайн-проверка ответа появится позже
Контрольный вопрос. Что такое ретест (confirmation testing)?
Подсказка: Здесь охват точечный — один конкретный баг, а не всё вокруг него.
Онлайн-проверка ответа появится позже
Контрольный вопрос. Какие из утверждений про пирамиду тестирования верны (выбери все подходящие)?
Выберите все верные варианты.
Подсказка: Сверь каждое утверждение с описанием пирамиды и с тем, что урок говорит про её отличие от уровней тестирования и про то, кто обычно решает вопрос автоматизации.
Онлайн-проверка ответа появится позже
Контрольный вопрос. Как называется самый широкий и нижний уровень пирамиды тестирования — тот, где тестов больше всего и они дешевле всего в поддержке? Ответь одним словом (заимствованный термин).
Подсказка: Это слово уже встречалось в ASCII-схеме урока на самой нижней и самой широкой строке.
Онлайн-проверка ответа появится позже
Контрольный вопрос. Чем ретест отличается от регрессионного тестирования по охвату?
Подсказка: Сравни, как урок описывает охват каждой из этих двух проверок — узкий он или широкий.
Онлайн-проверка ответа появится позже
Задание. Новая сборка только что развернулась на тестовом стенде. Тестировщик за 10 минут проверяет: приложение запускается, открывается главная страница, можно залогиниться. Как называется такая проверка? Ответь одним словом.
Подсказка: Это первая, самая быстрая проверка сразу после получения сборки.
✅ Готово, если: ты ввёл(а) верный ответ, и онлайн-проверка его приняла.
Онлайн-проверка ответа появится позже
Задание. После исправления бага с промокодом разработчик заодно случайно задел код скидок в корзине. Тестировщик хочет узнать, не сломалось ли что-то ЕЩЁ в корзине, помимо заявленного бага. Как называется такая проверка? Ответь одним словом.
Подсказка: Здесь интересует не только сам исправленный баг, а более широкий круг возможных последствий изменения.
✅ Готово, если: ты ввёл(а) верный ответ, и онлайн-проверка его приняла.
Онлайн-проверка ответа появится позже
Задание. Объясни в 2-3 предложениях: чем регрессионное тестирование отличается от ретеста, если оба выполняются ПОСЛЕ исправления бага в коде?
Подсказка: Подумай не о том, что общего у этих двух проверок (обе после изменений), а о том, чем отличается их охват — узкий он или широкий.
✅ Готово, если: программа запускается без ошибок и выводит то, что просят в задании.
Онлайн-проверка ответа появится позже
Задание. Опиши минимально достаточный набор действий тестировщика перед этим релизом: что именно он проверит и в каком порядке. В ответе явно назови нужные термины из четырёх (смоук/санити/регресс/ретест) и объясни, почему НЕ подойдёт полный регресс всего продукта.
До релиза остался 1 час. Разработчик только что закоммитил фикс одного конкретного бага (промокод BLACKFRIDAY не применялся из-за опечатки в коде) плюс сделал мелкую правку в другом месте — поменял текст подсказки в форме поиска курсов. Полный регресс всего продукта занимает 3 часа — столько времени нет.
Подсказка: Раздели работу на три шага по возрастанию точности: сначала самая быстрая проверка сборки в целом, потом точечная проверка исправленного бага, потом узкая проверка области, где была мелкая правка — и сопоставь каждый шаг с одним из четырёх терминов урока.
Онлайн-проверка ответа появится позже
Что дальше
Глава «Тестирование в жизненном цикле разработки» на этом закрыта. Прошли путь: модели SDLC (водопад, V-модель, итеративная) и цикл STLC; Agile, Scrum и Kanban — место тестировщика в спринте; четыре уровня тестирования — от компонентного до приёмочного; типы тестирования — функциональное/нефункциональное, black-box/white-box; и, наконец, смоук, санити, регресс, ретест и пирамида тестирования — как выбирать минимально достаточный набор проверок под ограниченное время. Дальше курс переходит к главе «Как устроено ПО, которое мы тестируем» — технической базе: клиент-серверная архитектура, сеть, HTTP, DevTools. Она пригодится, чтобы понимать, ГДЕ искать доказательства найденных дефектов.
