Перед релизом редко бывает время проверить абсолютно всё заново. Нужно уметь быстро решить: что проверить прямо сейчас, а что можно пропустить без риска. Для этого у тестировщика есть четыре разных по охвату вида проверок — смоук, санити, регресс и ретест — и общее понимание того, как устроено автоматизированное покрытие тестами, которое называют пирамидой тестирования.
Чему научишься за этот урок:
— различать смоук, санити, регресс и ретест по охвату и моменту применения;
— выбирать минимально достаточный набор проверок перед релизом при нехватке времени;
— понимать идею пирамиды тестирования (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 предложениях: чем регрессионное тестирование отличается от ретеста, если оба выполняются ПОСЛЕ исправления бага в коде?
Критерий приёмки: объяснено, что ретест — узкая, точечная проверка именно того конкретного бага, который был исправлен, а регрессионное тестирование — более широкая проверка остального, ранее работавшего функционала, чтобы убедиться, что исправление не сломало что-то другое. Разница — в ОХВАТЕ проверки, а не в том, что она выполняется после изменений (это общее для обоих).
Подсказка: Подумай не о том, что общего у этих двух проверок (обе после изменений), а о том, чем отличается их охват — узкий он или широкий.
✅ Готово, если: ответ раскрывает то, что просит критерий приёмки в задании выше.
Онлайн-проверка ответа появится позже
Задание. Опиши минимально достаточный набор действий тестировщика перед этим релизом: что именно он проверит и в каком порядке. В ответе явно назови нужные термины из четырёх (смоук/санити/регресс/ретест) и объясни, почему НЕ подойдёт полный регресс всего продукта.
Критерий приёмки: назван порядок — сначала смоук (быстро убедиться, что сборка в целом не развалилась: сайт открывается, ключевые страницы работают), затем ретест конкретно исправленного бага с промокодом BLACKFRIDAY (проверить, что именно он теперь работает), затем санити области формы поиска курсов (проверить, что мелкая правка текста подсказки не сломала саму форму, без выхода за пределы этой области). Объяснено, что полного регресса всего продукта (3 часа) сделать не успеть за отведённый час, а раз изменения точечные (один баг + одна мелкая правка текста), узкие точечные проверки покрывают риск с приемлемой уверенностью в рамках имеющегося времени.
До релиза остался 1 час. Разработчик только что закоммитил фикс одного конкретного бага (промокод BLACKFRIDAY не применялся из-за опечатки в коде) плюс сделал мелкую правку в другом месте — поменял текст подсказки в форме поиска курсов. Полный регресс всего продукта занимает 3 часа — столько времени нет.
Подсказка: Раздели работу на три шага по возрастанию точности: сначала самая быстрая проверка сборки в целом, потом точечная проверка исправленного бага, потом узкая проверка области, где была мелкая правка — и сопоставь каждый шаг с одним из четырёх терминов урока.
Онлайн-проверка ответа появится позже
Что дальше
Глава «Тестирование в жизненном цикле разработки» на этом закрыта. Прошли путь: модели SDLC (водопад, V-модель, итеративная) и цикл STLC; Agile, Scrum и Kanban — место тестировщика в спринте; четыре уровня тестирования — от компонентного до приёмочного; типы тестирования — функциональное/нефункциональное, black-box/white-box; и, наконец, смоук, санити, регресс, ретест и пирамида тестирования — как выбирать минимально достаточный набор проверок под ограниченное время. Дальше курс переходит к главе «Как устроено ПО, которое мы тестируем» — технической базе: клиент-серверная архитектура, сеть, HTTP, DevTools. Она пригодится, чтобы понимать, ГДЕ искать доказательства найденных дефектов.
