Я пришёл в проект в период его бурного роста: сервис постоянно обновлялся, архитектура менялась, появлялось много нового функционала. До моего прихода разработчики сами пытались всё автоматизировать, но всё заканчивалось большим скопом дополнительных задач, которые приходилось решать всей команде.

Задача мне была ясна: самостоятельно поднять автоматизированное тестирование с нуля.

Мы хотели повысить качество приложения с учётом того, что оно быстро меняется, требует подробных и понятных отчётов. Нужен был инструмент, чтобы своевременно выявлять проблемы и оперативно решать их. Мы разработали Web-сервис для визуализации и хранения истории отчетов, полученных при прогоне автотестов.

Сначала был сделан дашборд, который интегрируется с тестами и где можно посмотреть историю прогона с подробным отчётом. Самый большой плюс нашей системы: он понятен и менеджерам, и тестировщикам. В отчёты мы попытались вложить максимум информации с пошаговым описанием:

• Сколько тестов прошло, сколько упало.
• Время выполнения.
• Причина падения.
• Шаг на котором тест упал.
• Скриншоты и логи.

Менеджерам тесты нужны, чтобы понимать:

1. Сколько тестов есть.
2. С какой скоростью пишутся.
3. Количество упавших тестов и в случае, если самолет падает быстро — принять решение.
4. Что ключевые компоненты системы работают.

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

Появилась форма, в которой можно показать, на каком стенде и в каком режиме (параллельном или нет) запускать тест, указывать имя прогона.

Также мы сделали метод, который создаёт для каждого теста предустановленную сконфигурированную учётку: с нужными параметрами и с сохранением в базе, чтобы при очистке базы тест не ломался.

• Тест сначала идёт в свою БД и спрашивает: есть ли у меня для этого теста и окружения учётка?
• Если есть, тогда тест забирает её в работу.
• Если это новый тест — он идёт на API Gelato, которое выдаёт ему новую учётку. Он сохраняет её в базу и в дальнейшем использует.

• PageObjects. Его суть заключается в отделении тестов от предметов тестирования и создания уровней абстракции, которые легко переиспользовать.
• Steps-паттерн — у нас это называется «активность». Активности можно объединять в целые Flow и подключать в тесты. Получается так, что у нас есть пул активностей, которые постоянно переиспользуются в разных тестах.

Эти паттерны позволяют нам быстро собирать нужные тесты из разных фрагментов кода.

В начале работы у меня была амбиция сделать всё на Node.js + Angular.js. Сразу скажу, что после полученного опыта я бы не стал писать на Node.js. У нас возникла проблема с параллельным выполнением тестов, которую пришлось решать костыльно.

1. В начале я сделал основу дашборда, чтобы показать команде, как всё будет выглядеть. Потом накидал первичную структуру фреймворка.
2. Установил node.js.
3. Установил webdriver-manager.
4. Создал пустой проект в Web-storm.
5. Почитал документацию — https://seleniumhq.github.io/selenium/docs/api/javasc
6. Начал писать тесты.

1. Не упарываться.
2. Максимально переиспользовать код.
3. Вложить максимум информации в отчеты о прогонах:
4. Использовать паттерны при написании тестов.
5. И самое главное и тяжелое — показать и объяснить важность автоматизации менеджерам:

• Самый главный аргумент — машинное время в разы дешевле человеческого. Даже несмотря на дорогую поддержку автотестов в долгосрочной перспективе они дают хороший профит.
• Тесты могут работать круглосуточно — человек не может.
• Можем запустить тесты по расписанию (например, ночью) и понять, что не так.
• Тестами могут пользоваться не только тестировщики, но и разработчики, что увеличивает скорость выпуска релиза