Что стоит автоматизировать, а что нет: стратегия выбора тестов для QA
Не всё подряд нужно покрывать автотестами. Разбираем, какие сценарии автоматизировать в первую очередь, что покрывать обязательно, а где ручная проверка дешевле и честнее. Простое правило из трёх вопросов для собеседования и работы.
«Окей, я научился писать автотесты — но что именно покрывать? Неужели вообще всё подряд?» — это один из самых частых вопросов и у новичков, и на собеседованиях. Ответ короткий: нет. Всё подряд — это прямой путь к хрупким тестам, вечной поддержке и потраченному времени. Разберём, что реально стоит автоматизировать, а на что лучше не тратить силы.
Главный принцип: автотест — это вложение
Автотест стоит денег дважды: один раз — когда ты его пишешь, и потом постоянно — когда поддерживаешь. Поэтому покрывать стоит то, что часто проверяется и больно ломается. Если сценарий важный и повторяется из релиза в релиз — тест окупится. Если редкий и копеечный — он съест больше, чем принесёт.
Хороший автоматизатор — это не тот, кто покрыл сто процентов, а тот, кто покрыл то, что приносит максимум пользы при разумной поддержке. Автотесты должны экономить время команде, а не превращаться в ещё одну работу, которую все боятся трогать.
Что покрывать в первую очередь
Критичные бизнес-сценарии, без которых продукт просто не живёт. Авторизация, регистрация, оформление заказа, оплата. Если это сломается — у компании сразу проблемы и потерянные деньги. Такие кейсы автоматизируем первыми и бережём как зеницу ока.
Что покрывать обязательно
Регрессионные сценарии — то, что вручную проверяется каждый релиз. Именно здесь автоматизация раскрывается лучше всего: пишешь тест один раз и больше не гоняешь руками одно и то же по сто раз. Сюда же — критичные API, на которых держится логика продукта.
Что стоит покрывать
- ▸Места, где баги вылезают чаще всего — если модуль регулярно ломается, это прямой кандидат на тесты
- ▸Граничные случаи в важной логике — пустые значения, лимиты, некорректные данные, где ошибки особенно вероятны
А теперь — что покрывать не стоит
Тут новички чаще всего и зарываются. Не нужно автоматизировать всё ради красивой цифры покрытия. Есть вещи, где автотест дороже и бесполезнее ручной проверки — и про них важно знать заранее.
Не автоматизируй то, что постоянно меняется
Если фича ещё сырая и интерфейс переделывают каждую неделю — тесты будут падать не из-за багов, а из-за вечных изменений. Подожди, пока всё устаканится, и только потом покрывай. Иначе ты будешь чинить тесты быстрее, чем команда меняет дизайн.
Не автоматизируй разовые и редкие сценарии
Если что-то проверяется раз в полгода руками за пять минут — нет смысла писать и потом годами поддерживать тест. Здесь ручная проверка честно дешевле и проще, и это нормально.
Не лезь автотестами в чистую визуалку и UX
Красиво ли смотрится кнопка, удобно ли расположены элементы, приятная ли анимация — это про человеческий глаз. Автотест проверяет логику и факты, а ощущения и внешний вид лучше отдавать живому тестировщику или специальным инструментам визуального сравнения.
Осторожнее с UI там, где хватает API
Если логику можно проверить быстрым и стабильным API-тестом — не дублируй это тяжёлым UI-сценарием. UI оставляй для того, что реально живёт только в интерфейсе, а основную проверку логики уводи на уровень API.
Простое правило, чтобы решить
Перед каждым тестом задай себе три вопроса:
- ▸Насколько это критично?
- ▸Как часто это проверяется?
- ▸Стабильна ли уже сама фича?
Если важно, часто и стабильно — автоматизируй смело. Если нет — спокойно оставь это ручной проверке. Цель автоматизации не в проценте покрытия, а в том, чтобы команда тратила меньше времени на рутину и быстрее выкатывала релизы без страха что-то сломать.