Привет, Хабр! Меня зовут Николай Николаев, я руководитель отдела тестирования Учи.ру. Недавно мы внедрили автоматизацию: ускорили процессы и повысили качество тестирования. Далее я расскажу о пройденном пути, улучшениях и ошибках.

Выбор стека для автоматизации

На старте инструментов у нас было немного. Мы писали чек-листы в Google Docs, ставили задачи в Jira, сохраняли важную информацию в Confluence, а для ручного кросс-браузерного тестирования использовали BrowserStack. Еще у нас был CI, построенный в CircleCI, но в нем многого не хватало, тесты падали и приходилось заводить их снова.

Мы подобрали удобный стек технологий, учитывающий специфику нашей компании и продукта:

• основной стек — Python 3.х.х + Selenium WebDriver Framework PyTest;

• ферма браузеров — Selenoid;

• система управления тестированием — Qase;

• CI — GitHub Actions.

Python

Я сам пишу автотесты на Python, поэтому и выбрал его для обучения. Большой плюс —  низкий порог вхождения. За несколько уроков можно научиться писать простые автотесты, даже без знания языка.

Selenoid

Это удобный сервис для запуска изолированных браузеров в Docker-контейнерах. Тесты запускаются, прогоняются, а затем контейнер уничтожается. К тому же, у Selenoid есть поддержка, а это весомый плюс. 

Qase

В качестве системы управления тестированием выбрали Qase. Она позволяет запускать тест-раны, составлять тест-кейсы, приоритезировать и отмечать автоматизированные. Еще здесь можно распределять тест-кейсы, если на одном проекте несколько тестировщиков.

Qase интегрируется с Jira по API: в таск-трекере можно создать шаблон ошибки, снять метрики по времени, отследить начало, конец и результаты теста. Есть возможность настройки уведомлений в Slack. 

В репозитории Qase доступно создание чек-листов или тест-планов, можно поставить метки для автоматизированных тест-кейсов и фильтровать их по этому признаку. Удобно, что можно сделать Milestone (объединение нескольких итераций тестирования при разработке большой фичи). Для нас Qase оказался очень удобным инструментом.

Три стадии автоматизации

Автоматизацию внедряли в несколько итераций. Сначала мы развернули Selenoid и Selenoid UI, но все еще хранили и запускали тесты локально.

Во второй итерации провели интеграцию с Qase и создали отдельные репозитории с автотестами для каждого проекта в GitHub. Репозитории, в которых тестировщики ведут разработку своих тестов, создавали по две ветки: master и dev.  Внедрили обязательный code review. Договорились, что тесты в master всегда должны быть в рабочем состоянии. 

Наши первые результаты были такими: тесты хранились и прогонялись удаленно, хотя мы все еще запускали их локально. Отчеты просматривали в Qase.

В третьей итерации создали workflow в GitHub Actions по двум триггерам:

1. Push. Тесты запускаются автоматически, когда в master заливается их новая версия.

2. Schedule. На проектах, в которых уже выполнена интеграция CI, минимум раз в сутки, в 00:00, прогоняются тесты. Утром, если прошло неудачно, ищем причины. 

Теперь тесты хранятся и запускаются удаленно: как вручную, так и автоматически. Прогоняются в Selenoid, а результаты формируются в Qase.

Препятствия и ошибки

В процессе автоматизации мы совершили три ошибки. Они, как мне кажется, могут возникнуть у многих.

1. Скептическое отношение к автоматизации тестирования

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

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

• Желание автоматизировать все

Одна из ошибок — желание автоматизировать еще и регрессионное тестирование. Эта функциональность была стабильна и казалось, что покрыть ее автотестами — хорошая идея.

Однако, при более глубоком погружении выяснилось, что на это у нас не хватит времени. И чем больше будет написано тестов, тем сложнее их поддерживать. Поэтому, мы решили не писать регрессионные автотесты, а делать smoke-тесты для каждого сервиса. Это значит, что вся автоматизация должна проходить по критическим местам: позитивным сценариям и возможностям бизнес-требований. Так мы смогли контролировать основную функциональность, чтобы она не отваливалась без дополнительных временных затрат на автоматизацию.

• Пытались писать на разных языках

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

Итоги и планы

На сегодняшний день мы получили неплохую автоматизацию. И вот ее плюсы.

• Увеличились скорость и качество тестирования: у автотеста нет человеческого фактора, из-за которого что-то можно упустить. Что в нем написано, то он и делает. Все имеющиеся тесты обязательно прогоняются (лишь бы они были стабильны).

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

• Появилась дополнительная метрика стабильности сервиса, на которую мы можем положиться.

Далее мы собираемся внедрить отправку события аналитики. В качестве нагрузочного тестирования попробуем Яндекс.Танк. Еще одна часть автоматизации, о которой мы думаем — тестирование скриншотами. Это будет полезно, так как наш основной продукт содержит большое количество контента — заданий.

Если ваша команда внедряла автоматизацию, расскажите, какие инструменты использовали и что порекомендуете?