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