Пять видов тестирования закрывают большую часть повседневной работы QA, хотя в теории классификаций куда больше. Для русскоязычной IT-аудитории это полезный холодный душ: если команда тонет в терминах, а не в реальных проверках, она почти наверняка тратит время не туда.
Именно на этом делает акцент свежий материал Selectel на Хабре: автор Антон Дуенин, который пишет, что работает в тестировании более шести лет, разбирает не академический каталог техник, а набор практик, которые действительно встречаются в релизном цикле, сообщает Habr / Карьера. В центре внимания пять подходов: исследовательское, smoke-, тестирование совместимости, регрессионное и приемочное тестирование. Логика простая: новичков часто пугают десятки названий, но в реальной разработке основной объем пользы дают несколько проверок, которые команда повторяет из спринта в спринт.
Первый из этих подходов — исследовательское тестирование. Это сценарий, где у QA нет заранее расписанных шагов, а есть продукт, опыт и привычка задавать неудобный вопрос «а что будет, если…». Такой формат особенно полезен, когда в проект прилетела новая фича, документация еще не успела догнать разработку, а понять, где система может посыпаться, нужно уже сейчас. Сильная сторона метода в том, что он находит неочевидные баги: забытые кнопки, странные последовательности действий, поломки на нетипичных данных. Но у свободы есть цена. Результат плохо воспроизводится, сильно зависит от уровня конкретного тестировщика и не гарантирует, что никто не пропустил базовый сценарий просто потому, что увлекся поиском экзотики.
Второй обязательный минимум — smoke-тестирование, то есть быстрая проверка на уровне «оно вообще живо или уже нет». В статье это описано без романтики: несколько простых действий по ключевому пути пользователя часто экономят часы, а иногда и дни. Открывается ли приложение, можно ли войти, проходит ли базовая операция вроде добавления товара в корзину и оплаты — если на этом этапе все ломается, углубляться в тонкие кейсы бессмысленно. Любопытная деталь из текста: автор отдельно напоминает о вечном споре на собеседованиях между smoke и sanity и ссылается на глоссарий ISTQB, где эти термины рассматриваются как синонимы. Для рынка это полезное уточнение: иногда команды спорят о словах дольше, чем проверяют сборку.
Третий блок — тестирование совместимости. На бумаге идея банальна: продукт должен одинаково вести себя в разных условиях. На практике именно здесь команды регулярно получают сюрпризы уже после релиза. Автор приводит типичный пример: фича может корректно работать на одном телефоне или мониторе, но ломаться у другого пользователя из-за отличий в разрешении, масштабе, браузере, версии ОС или настройках отображения. Для бизнеса это не абстрактная проблема качества, а прямой риск потери денег и доверия. Если платежный экран у части аудитории уехал за границы видимой области, спорить о том, чей это баг — фронта, бэка или тестов, уже поздно. Для разработчиков вывод неприятный, но полезный: проверка «у меня все ок» не считается тестовой стратегией, особенно если продукт живет сразу на нескольких устройствах и конфигурациях.
Дальше идет регрессионное тестирование — та часть работы, которую многие недолюбливают ровно до первого дорогого отката. Смысл очевиден: после изменений нужно убедиться, что новый код не сломал старый функционал. В статье этот подход подается как рутинный, но критически важный слой контроля. Именно здесь команда расплачивается за быстрые фиксы без достаточной проверки, за хрупкие зависимости между модулями и за релизную дисциплину в духе «да там всего одна маленькая правка». Для продактов и IT-руководителей это особенно показательно: чем выше скорость выпуска изменений, тем дороже ошибка в регрессии. Без понятного набора повторяемых проверок релизный процесс превращается в лотерею, где выигрышный билет почему-то всегда достается только на демо.
Пятый тип — приемочное тестирование. В практической оптике статьи это не про красивую терминологию, а про финальную сверку ожиданий с тем, что реально получилось на выходе. Такая проверка нужна не только QA, но и всей продуктовой цепочке: разработке, аналитике, владельцу фичи, иногда поддержке. Именно на этом этапе особенно хорошо видно расхождение между «задача формально закрыта» и «пользователь действительно может этим пользоваться без боли». Если предыдущие виды тестирования отвечают на вопрос, работает ли система технически, то приемочное чаще упирается в бизнес-смысл и соответствие ожиданиям. Для рынка, где команды стараются выпускать быстрее и меньшими итерациями, это важный сигнал: скорость релизов не отменяет последнюю проверку на здравый смысл.
Главный вывод из этой истории довольно приземленный и потому ценный. Рынку не очень нужны QA-специалисты, которые могут наизусть перечислить полсотни терминов, но пропускают базовый smoke или не закладывают совместимость в релизный процесс. Куда важнее умение понимать, какой из видов тестирования нужен прямо сейчас, где он экономит время команды и где спасает продукт от репутационного конфуза. Для тех, кто только входит в профессию, это хороший ориентир: практический стек QA начинается не с энциклопедии методов, а с нескольких дисциплин, которые закрывают основную часть реальных рисков.