Привет, Хабр! Меня зовут Константин Боковиков, я Chapter QA Lead в онлайн-кинотеатре KION. Я занимаюсь организацией процессов тестирования в командах и оценкой их зрелости, а потому часто использую в работе автотесты. К слову, автотесты нужны не всем: для некоторых задач и команд они просто не подходят. В этой статье я постараюсь показать наш опыт использования этого инструмента и расскажу, кому, на мой взгляд, можно обойтись без него, а кому точно стоит его освоить.

Зачем KION автотесты?

Стоит сразу отметить, что в KION есть чёткое разделение QA на фронтенд и бэкенд, причём у каждого направления своя «кухня». Я отвечаю за бэк и расскажу, как автотесты применяются у нас. По мере роста и развития онлайн-кинотеатра становилось всё яснее, что нужно уходить от вендорных решений и отдавать предпочтение самостоятельным. На начальном этапе мы использовали только ручное тестирование, но найти тестировщиков — отдельный квест, так что тесты часто проводились силами самих разработчиков. 

Количество задач с тестами росло, релизы стали заходить со скрипом из-за багов. Появилась явная необходимость решить вопрос с тестированием глобально и перейти от ручных тестов к автоматизированным. К тому моменту команда разрослась примерно до 30 человек и стала дробиться на мини-команды. Я перешёл в субкоманду KION, которая занималась формированием витрины. Мы сразу приняли решение писать код и запускать автотесты, чтобы не копить технический долг. Сейчас тестировщиков в KION много, и тестировщики — по сути последняя инстанция перед релизом.

Плюсы автотестов

Из очевидных преимуществ автотестов: скорость, точность, универсальность, а ещё возможность проводить тесты круглосуточно. Кроме того, автоматизация исключает человеческий фактор — усталость, невнимательность, стресс.

В случае KION автотесты помогают проверять основной функционал бизнес-фичей. Тесты у нас пишутся не в формате «вышел сервис и тут же покрылся автотестами», нет. Мы смотрим на картинку глобально: у нас микросервисная архитектура, разные сервисы взаимодействуют друг с другом синхронно и асинхронно. Мы смотрим на KION с точки зрения бизнеса и с точки зрения пользователя, а затем тестируем нужные процессы.

Минусы автотестов

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

У нас довольно высокие требования к компетенциям тестировщиков. Нам нужны не тестировщики в общем смысле, а, скорее, профессионалы в написании кодов по автотестам. По сути нам нужны программисты, которые пишут код в разрезе автотестирования, а сотрудников с такими компетенциями сложно найти. В последнее время мы брали серьёзных middle-специалистов из мира автотестирования и растили их до уровня senior.

Почему же мы всё равно проводим автотесты? Дело всё в той же микросервисной архитектуре. При ручном тестировании в любом случае придётся обеспечивать взаимодействие со сложной инфраструктурой, а этот процесс практически идентичен написанию автотеста. В нашем случае трудозатраты на ручной и автотест сопоставимы, так что проще сразу запустить автотест. Да и даже если бы мы решили перейти на ручные тесты и искать ручных тестировщиков, наши требования по-прежнему были бы высокими, так что проблему поиска подходящих кандидатов это бы не решило.

Автотесты незаменимы? 

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

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

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

Условия для проведения автотестов

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

Кому нужны автотесты?

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

У нас бывали случаи, когда UI-автотесты прогонялись около 4 часов. Сейчас время сократилось до 1,5 часов, но это всё равно довольно много. При этом тесты на бэкенд (их около 400 штук, и количество растёт с увеличением фич) прогоняются 3 минуты, а сервисы CI/CD умеют распараллеливать тесты и ускорять прогон. Так что тестирование бэкенда проще и дешевле автоматизировать. Если вы тестируете фронтенд, можно составить чек-листы и прожимать руками.

А мне нужны автотесты?

Для того чтобы понять это, ответьте на несколько вопросов:

1. Внутри вашего проекта много межсервисных взаимодействий?

2. У вас частые релизы (раз в две недели)?

3. У вас мало тестировщиков и достаточно разработчиков?

4. Ваши разработчики могут поделиться компетенциями с тестировщиками или поучаствовать в настройке тестов?

5. У вас большая долгая регрессионная модель?

Большинство ответов «да»? Значит, вашей команде стоит задуматься об использовании автотестов.

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