5 видов тестирования, которые покрывают 90% реальной работы

Когда начинаешь погружаться в QA, кажется, что видов тестирования десятки, если не сотни. Учебники и курсы вываливают их списком: исследовательское, дымовое, регрессионное, приёмочное, нагрузочное, юзабилити, локализационное, инсталляционное, восстановительное, A/B… — продолжать можно долго. И появляется ощущение, что в работу не пускают, пока не научился применять каждое из них.

За 12+ лет в тестировании я понял одну вещь: теория сильно расходится с практикой. В реальном дне тестировщика 90% времени уходит на 5 видов. Остальные — либо узкоспециальные (perf, security), либо академические термины для одного и того же.

Ниже разберём эти пять: где используется, что ловит, где не работает, какие ошибки люди делают чаще всего.

🔍 Исследовательское тестирование

Тестирование без заранее подготовленных сценариев. Нет тест-кейсов, нет чек-листа, есть только продукт, ваш опыт и интуиция. Задача — понять, как система работает и где может сломаться.

На практике выглядит просто: открываете приложение и взаимодействуете с ним. Жмёте кнопки, вводите странные данные, комбинируете действия, пробуете нестандартные сценарии. Это игра «а что будет, если…».

Когда применяется

Две ситуации.

Когда нет документации и тест-кейсов. Пришла новая фича, ТЗ — пара строк в Slack, релиз через два дня. Нужно быстро понять, как оно вообще работает.

Когда нужно выйти за рамки описанных сценариев. Даже хорошие тест-кейсы покрывают только ожидаемое поведение. А пользователи делают ошибки, вводят мусор, нажимают кнопки не в том порядке. Именно тут исследовательское тестирование даёт максимальную ценность.

Что ловит хорошо

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

Иногда это смешно. В UI находится кнопка, про которую все забыли — она есть, никто её давно не трогал, в тест-кейсы она тоже не попала. И при исследовательском прогоне внезапно выясняется, что она не работает уже полгода. Просто никто не замечал.

Отдельно хорошо работает на новых людях в команде. У джуна или человека, только что пришедшего на проект, нет устоявшихся ожиданий. Глаз не замылен. Он смотрит на продукт свежо — и находит баги там, где остальные их перестали видеть.

Где не работает

Несмотря на пользу, исследовательское — не серебряная пуля.

Плохо воспроизводится. Один удачный прогон, в котором нашли кучу проблем, не гарантирует, что следующая итерация поймает то же самое. Сегодня вы прокликали один путь, завтра другой.
Сильно зависит от опыта. Один тестировщик найдёт десятки багов, другой — почти ничего. Просто потому что у них разный паттерн взаимодействия с продуктом и разная насмотренность.
Легко пропустить базу. Увлекаешься исследованием — и забываешь проверить очевидное.

Главная проблема: без структурированного покрытия нет уверенности в качестве. Только исследовательским тестированием релиз не закроешь.

💨 Smoke-тестирование

Самая базовая проверка по принципу «оно вообще работает или совсем сломано?» Не тратить часы на детальное тестирование, если система в принципе не запускается. Первый фильтр.

На практике — несколько простых действий без углубления. Открылось приложение → залогинился → положил товар в корзину → оплатил. Если эти 4 шага прошли — есть смысл тестировать дальше. Если нет — возвращаем билд, чиним базу.

Когда применяется

Перед основным прогоном. Прежде чем открывать список из 200 тест-кейсов, имеет смысл пройти ключевой сценарий и убедиться, что фундамент не развалился.

Уровень любой: одна функция в коде, одна фича, один модуль, всё приложение. Принцип один — быстро проверить, что критический путь жив.

Зачем это нужно

Чтобы не оказаться в ситуации, когда два дня тестировал второстепенный функционал, а потом выяснилось, что основной сценарий вообще не работает. После фикса придётся пересдавать всё заново — потому что код в основном пути менялся, и побочные эффекты могли затронуть всё, что вы уже проверяли.

Несколько минут на smoke экономят часы.

Почему его всё равно пропускают

Доверие к разработчику или к процессу. «Ну базово точно работает, не мог же дев влить сломанный билд». В условиях спешки особенно — хочется быстрее закрыть задачу.

На практике даже очевидные вещи ломаются. Разработчик мог проверить один кусок, а не весь сценарий. Или локально у него работало, а на dev-стенде нет — конфиг другой, окружение другое, integrations недоступны. Чем раньше это поймать, тем меньше команда страдает потом.

Бонус для собеседований

Любимый вопрос: чем smoke отличается от sanity?

Половина кандидатов говорит, что sanity шире. Другая половина — что уже. Третьи — что sanity на проде. Все по-своему правы.

Правильный ответ — со ссылкой на ISTQB Glossary: smoke и sanity — это синонимы. Никакой разницы официально нет. Дальше можно пояснить, что в индустрии термины часто используют по-разному, но canonical-определение одно.

📱 Тестирование совместимости

Проверка того, как продукт ведёт себя в разных окружениях. Звучит очевидно — на практике вокруг этого собирается больше всего боли.

Самая частая ошибка: протестил у себя — значит, работает. Это не так. Пользователи приходят с другими девайсами, другими версиями ОС, другими браузерами, другими языками, другими часовыми поясами. Каждая ось — потенциальный класс багов.

Что именно проверяется

Разные устройства (iPhone 14 vs iPhone SE, флагман vs бюджетный Android).
Разные версии ОС (iOS 16/17/18, Android 10/12/14).
Разные браузеры (Safari, Chrome, Firefox, Edge — и их мобильные версии).
Разные разрешения и плотности экрана.
Разные локали, языки, часовые пояса.
Разные сетевые условия (Wi-Fi, 4G, плохое соединение, оффлайн).

Даже визуально одинаковые девайсы могут вести себя по-разному.

Кейс из практики

У меня на столе два монитора. Один FullHD, другой 4K. Диагональ одинаковая, выглядят почти идентично. На 4К открываю продукт — верстка идеальна. На FullHD — в маленьком текстовом поле появляются два огромных неактивных скролла, которые ломают всю страницу.

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

Почему это критично

Пользователь работает в своём непредсказуемом окружении, а не в вашем. Если тестирование ограничивается одной конфигурацией — есть гарантия, что что-то всплывёт в проде.

Часто это самые неудобные баги: воспроизвести нельзя (нужного девайса нет), починить нельзя (не понятно, в чём именно проблема), а пользователи продолжают жаловаться.

Как правильно

Не тестить «всё на всём» — это нереалистично. А тестировать по статистике.

Откройте аналитику: с каких устройств, ОС, браузеров приходят ваши пользователи. Покрывайте топ. Если 99% юзеров заходят через Safari — Safari в приоритете, а не Chrome, который вам нравится. Если 70% Android и 30% iOS — соответствующий перекос в покрытии.

Для девайсов, которых нет физически — облачные фермы (BrowserStack, Sauce Labs, AWS Device Farm, локальные провайдеры). Не панацея, но закрывают большой кусок.

🔄 Регрессионное тестирование

Проверка того, что после изменений ничего не сломалось в соседних местах.

Любая правка может задеть существующий функционал. Добавили фичу — старая логика начала работать по-другому. Починили баг — открыли два новых. Изменили запрос к БД — поломали отчёты, которые никто давно не открывал. Регресс ловит именно такое.

Важный нюанс: регресс проверяет то, что НЕ должно было измениться. То, что меняли намеренно — это уже не регресс, а проверка новой функциональности.

Когда проводится

Практически постоянно.

После фикса бага — что починили, и что соседние фичи не отвалились.
После новой фичи — что старые сценарии работают.
Перед релизом — чтобы убедиться, что весь продукт жив, а не только новая часть.

Регресс — не разовая активность, а регулярная часть процесса.

Главная проблема

Объём. Со временем продукт растёт, регресс-чек-листы пухнут, прогонять всё руками становится невозможно. Через два года у вас 800 тест-кейсов, а времени на регресс — день.

Что с этим делать:

Приоритизация по риску. Не все сценарии равны. Платёж и логин — критично всегда, экспорт CSV — можно проверить реже.
Risk-based regression. Прогоняем подробно те модули, которые были задеты изменениями, остальные — на smoke-уровне.
Автоматизация. То, что не меняется месяцами и стабильно работает — отличный кандидат на автотест. Хрупкие, часто меняющиеся вещи — наоборот, лучше оставить ручными до стабилизации.

Этим обычно занимается QA-лид, но общее понимание принципов нужно каждому тестировщику — иначе через год работы команда тонет в регрессе.

Почему пропускать опасно

Соблазн «изменения маленькие, регресс можно сократить» — главная причина багов в проде. Именно мелкие правки чаще всего вызывают неочевидные побочные эффекты. Поменяли один параметр в общем хелпере — и сломались три экрана, которые этот хелпер использовали.

Регресс защищает продукт от тихой деградации. Без него каждый релиз — лотерея.

🚀 Приёмочное тестирование на проде

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

На разных проектах называется по-разному: пост-релизное, smoke на проде, приёмочное, релизное, post-deploy verification. Суть одна — продукт оказался в реальном окружении, с реальными пользователями и нагрузкой, и здесь могут проявиться вещи, которых не было видно на стейдже.

Что обычно происходит

Сценарий №1 — что-то рассинхронизировалось на релизе. Новая версия фронта доехала, бэка — нет. Или наоборот. И теперь на проде лежат две несовместимые части приложения, которые рисуют ошибки в логах.

Сценарий №2 — прод-окружение отличается от тестового. На стейдже мы дёргали test.bank.ru, в проде — bank.ru. Контракты слегка разные, тайминги другие, error codes отличаются. На стейдже это не проявлялось.

Сценарий №3 — нагрузка. На стейдже 5 запросов в минуту, на проде 5000. И всё, что было «нормально» под маленькой нагрузкой, начинает падать.

Часто это сопровождается хотфиксами, откатами, повторными прогонами и общей нервозностью в команде.

Почему это особенно важно

Прод — единственная среда, где продукт используется по-настоящему. Как бы хорошо ни был настроен стейдж — он никогда не воспроизводит реальные условия полностью.

Цена ошибки на проде высокая. Баг на дев-стенде — локальная проблема, баг в проде — это уже потеря пользователей, репутация, деньги. Поэтому любые пропуски на предыдущих этапах здесь ощущаются особенно болезненно.

Как снижать риск

Канареечный релиз — раскатить новую версию сначала на 1%, потом на 10%, потом на 100%. Если что-то ломается — затронуто меньше людей.
Feature flags — выкатить код, но включить фичу только для внутренней команды. Проверили — открыли остальным.
Staff first — релиз сначала видят только сотрудники компании. Прогнали критический путь, удостоверились — катим всем.
Готовый rollback — план отката должен быть проверен до релиза. Не «вроде должно сработать», а реально протестировано.

Идеального тестирования до релиза не бывает. Но хорошие практики выкатки превращают приёмочное тестирование из паники в спокойную процедуру.

Вывод

Терминов в QA много, классификаций ещё больше. На практике 90% работы — это пять видов:

Исследовательское — ловить неожиданные баги, когда нет сценариев.
Smoke — быстро понять, что система в принципе жива.
Совместимость — проверять поведение на разных девайсах и окружениях.
Регресс — убеждаться, что новые изменения не сломали старое.
Приёмочное на проде — последний рубеж после выката.

Эти виды не существуют отдельно. На реальном проекте они переплетены: smoke → регресс → совместимость по топу устройств → исследовательский прогон новой фичи → приёмочное на проде после релиза. Один пайплайн.

Ошибки чаще всего возникают не из-за того, что тестировщик не знает редкую технику. А из-за того, что пропустили базовую проверку или сделали ложное предположение о том, как работает система. Освоить эти пять видов — закрыть большую часть реальных рисков.