28.10.2025 07:02
SiYa_renko 0 252 Источник

Привет, Хабр! Меня зовут Анастасия Нечепоренко, я QA Lead и преподаватель курса «JavaScript QA Engineer» в Отус. 

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

Обычно, уже после первого релиза, проект начинает расти слишком быстро, багов появляется все больше, а регресс руками занимает все больше времени. К тому же сейчас весьма распространена ситуация, когда в команде есть только один тестировщик, он же «тире» лид QA, и если темпы разработки достаточно быстрые, то на налаживание процессов и уж тем более автоматизацию, по крайней мере с первого взгляда, просто не остается времени. Скачешь с одной фичи на другую, от спринта к спринту и медленно сходишь с ума, поскольку в какой‑то момент область тестирования начинает казаться необъятной, а на еще одного QA ресурсов попросту нет.

Знакомая ситуация, да? Наверное, не ошибусь, если предположу, что с такой ситуацией сталкивались от проекта к проекту многие из нас :-)

Итак, когда же нужны автотесты?

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

Более того, в порыве покрыть 100% кода тестами вы не придете ни к чему хорошему, потому что 100% покрытие не дает гарантии качества на проекте. Пусть тестов будет не так много, но зато пусть каждый из них несет реальную пользу и будет осмысленно написан.

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

  1. Регрессионные баги возвращаются снова и снова. Как обычно бывает? Оно раньше работало, мы его не трогали, но теперь сломалось. Причем по не очень очевидным при тестировании причинам — добавили новое поле в модель какой‑то сущности, а в другом сервисе сломался импорт (реальный кейс с реального проекта).

    Нет, разумеется после обнаружения бага мы дружно ударим ладонью по лицу и скажем «это же было очевидно», но в момент когда дедлайны горят и ты тестируешь только новый функционал, о том, что он взаимодействует еще и с другим сервисом можно сразу и не вспомнить. Не спорю, можно было бы и получше подумать над тест‑кейсами, но если так просто решается проблема, то откуда тогда берутся баги, верно?

  2. Регресс перед релизом занимает часы, а то и дни. В таком случае вместо того, чтобы заниматься выпуском новых фич, вы тыкаетесь в интерфейс, в попытке вспомнить все, что нужно протестировать, либо глядя в TMS и отмечая кейс за кейсом.

    Не будем также скрывать тот факт, что при ручном регрессе из раза в раз глаз человека «замыливается» и мы часто перестаем замечать очевидные ошибки, особенно когда бэк отвечает корректно. Кто‑то из вас умеет обращать внимание на каждую лексему на проекте? Честно признаюсь, с этим у меня есть проблемы, когда тестируешь реально сложные бизнес‑сценарии, внимательно читать каждую строчку в интерфейсе не получается.

    К слову сказать, небольшой оффтоп, с этим отлично справляется GPT, рекомендую дополнительно проверять через него.

  3. От каждого изменения в код становится страшно и даже мелкий рефакторинг вызывает тревогу и мысль «А вдруг что‑то сломается и мы не заметим?». Тут можно сказать, что эта мысль может появиться на любом проекте, но как правило, если действительно появляется это опасение, вы не первый день на проекте и хорошо его знаете, а еще вы не вчерашний новичок, то это признак того, что проблема превратилась в системную и баги появляются циклично и регулярно.

  4. Сложно передать контекст новому члену команды. Это не только проблема автотестов, но еще и признак плохо задокументированного поведения, но в быстро растущих проектах документация — та еще головная боль и часто выкраивать время на ее ведение приходится буквально с боем (У вас не так? Напишите об этом в комментариях, мне правда интересно).

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

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

  6. Баги приходят от клиентов или заказчиков. Если основной источник репортов внешний, у вас проблема — внутренних проверок недостаточно. Либо вы плохо проверяете. В любом случае лояльность клиента и заказчика это довольно важная штука, поскольку проект существует для них и из‑за них, так что не стоит рисковать ей и получать плохие отзывы.

  7. Частые откаты релизов. Надеюсь, вы никогда не столкнетесь с этой проблемой, поскольку она буквально кричит о том, что что‑то в процессах у вас явно не так, но если вы регулярно откатываете изменения после деплоя на прод из‑за критических багов, 100% нужно задуматься над автоматизацией. И над улучшением качества тестирования, поскольку это одна из дорогих проблем, которая также рискует лояльностью пользователей.

  8. Проект стабилен. Как ни странно, если у вас есть время и другие ресурсы, дедлайны не горят (кажется почти невозможным, да?), то самое время подумать об автоматизации.

Если у вас наблюдается хотя бы 2 или 3 пункта из этого чек‑листа, стоит завести разговор о написании автотестов со своим лидом или проджектом. Но как понять, что для автотестов еще слишком рано и они вам не нужны?

Когда автотесты не нужны (пока)

Как я, кажется, уже говорила, это не универсальный инструмент, который нужен в 100% случаев. Иногда, особенно на ранних стадиях проекта, тесты приносят вреда больше чем пользы, поскольку отжирают слишком большое количество времени и умудряются устаревать быстрее, чем команда релизит новые фичи.

Вот несколько кейсов, когда автоматизацию стоит отложить:

  1. Архитектура проекта не стабильна и регулярно меняется. Пока фундамент шатается, над автоматизацией лучше не думать, поскольку в таком случае тесты будут показывать не баги, а факт изменений API и др. элементов системы. Поддержка таких тестов будет сложной, долгой и будет занимать времени больше, чем ручные проверки. В большинстве случаев оно того не стоит.

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

    Сюда также можно было бы добавить причину, что команда не имеет достаточного опыта в автоматизации, но с этим я не согласна, поскольку опыт нарабатывается и приобретается, даже плохо написанные с точки зрения бест практик тесты будут приносить пользу, если они способны проконтролировать нужные проверки.

  3. Ресурсы команды критически ограничены или цель проекта только в быстрой проверке гипотезы. Достаточно очевидный пункт, но если в команде условно говоря один разработчик, один тестировщик или это вообще человек два‑в‑одном, дедлайн вчера и каждая минута на счету, то выживание становится важнее потенциальных идеалов и лучше потратить время на то, чтобы продует вообще заработал.

    Микроотступление, здесь, разумеется, речь идет о временной паузе, а не об отказе от тестов навсегда. Как только проект стабилизируется, ресурсы появятся, вам нужно будет вернуться к списку «когда нужны автотесты» и проверить еще раз.

  4. Проект одноразовый или имеет четкий срок жизни. Если система умрет через неделю (условно говоря) вам нет смысла обеспечивать ее выживаемость в долговременной перспективе, это будет только трата времени. Всякие лендинги, скрипты для единоразовой миграции и так далее и тому подобное нуждаются в автотестах только в том случае, если вам нечем заняться и вы хотите попрактиковаться «для себя».

С чего начать?

Не совсем по теме статьи, но все таки, с чего я рекомендую начать внедрение автоматизации?

Помню, еще в начале своей карьеры, когда мы поняли, что на проекте нужны тесты (ну как всегда срочно и вчера), у нас с моим проджектом был крайне «оптимистичный» план за пару месяцев покрыть весь регресс e2e‑тестами. Для контекста: проект был сложный (биллинговая система), по правде говоря момент внедрения тестов был давно упущен, количество проверок для регресса превышало несколько сотен и занимало огромнейшей количество времени, причем сам сервис биллинга вел себя не слишком стабильно и от каждой попытки порефакторить его обязательно пытался сломать критически важную часть системы. Ну и как вишенка на торте — была огромная просадка по юнит‑тестам (их должны были писать разработчики, как для фронта, так и для бэка, но времени на них не хватало).

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

Запомните. Вам не нужна идеальная пирамида тестирования, особенно на первых этапах.

Наиболее быстрый эффект при минимальных затратах можно получить, если (внезапно) сначала обдумать существующие сценарии и выделить критически важный функционал, который не должен ломаться ни при каких условиях.

Как понять, какой функционал критический? Это функционал, который ведет к потере в деньгах или в клиентах, что, в целом, одно и то же. Чем выше риск потери клиента после обнаружения бага в функционале, тем выше критичность сценария.

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

Опять же, для начала передо мной стоял бы выбор unit (если в вашей команде решено, что ими занимаются не разработчики) или e2e‑тесты?

Базовой рекомендацией будет сначала покрыть Unit‑тестами ядро бизнес‑логики, самые критичные сценарии (как определить критичность уже писала выше). Это могут быть расчеты, валидация, преобразование данных, корректность правил доступа и так далее Это будет быстро, дешево, надежно и ломаться будет гораздо реже, чем e2e.

И уже следующим этапом логично будет начать автоматизацию smoke‑тестирования с помощью e2e‑тестов, которые будут проверять длинные юзерфлоу, «пронизывающие» всю систему. Это может быть буквально 3-5-10 сценариев, но, поверьте, они уже принесут огромную пользу и отловят самые глупые ошибки.

А еще вы можете заставлять разработчиков (которые не очень любят тестировать свой код) прогонять тесты перед сдачей фичи в тестирование до тех пор, пока они не станут зелеными, и это тоже сэкономит вам кучу времени! И не будет этого дурацкого пинг‑понга не работающим функционалом, если у вас на проекте он есть.

Подведем итоги

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

Напомню, автоматизация тестирования должна стать решением вашей боли, а не еще одной вилкой в... Ну, вы поняли :-)

Автоматизация тестирования постепенно становится неотъемлемой частью разработки. Если вы хотите глубже разобраться в инструментах, процессах и роли QA‑инженера в современном проекте, приглашаю вас на курс JavaScript QA Engineer. Чтобы узнать, подойдет ли вам программа курса, пройдите вступительный тест.

Приходите на открытые уроки, которые бесплатно проведут преподаватели курса (и я в том числе):

Комментарии (0)