При построении автоматизации функционального тестирования (АФТ) в разных командах, проектах, компаниях могут возникать одни и те же проблемы, универсального решения которых не существует. Я, Василий Соколов, руководитель направления разработки ИТ-решений ДОМ.РФ, расскажу, как мы два года назад начали строить АФТ и каких результатов удалось достичь.

Проблематика

Проблема №1: тестировщики не используют автотесты

Основная задача и цель работы автоматизатора – сократить время тестирования нового релиза и облегчить работу ручного тестировщика. Однако ситуация, когда ручные тестировщики и автоматизаторы работают так, словно не знают о существовании друг друга, очень распространена. Это может быть следствием обоюдного недопонимания в команде. С одной стороны, тестировщик не может прочитать автотест и понять, что там написано, что он делает, как его запускать, как анализировать результаты. С другой стороны, автоматизатор может не понимать ручной тест-кейс, не знать тонкостей системы или выбирать кейсы, исходя не из важности проверок для всей команды тестирования, а просто наугад. В результате ручное и автоматизированное тестирование выполняется так, будто они изолированы друг от друга.

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

Проблема №2: «Зоопарк» фреймворков и двойная работа для автоматизаторов

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

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

Проблема №3: изолированность автоматизаторов разных команд

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

Представим, что в соседних командах сидят такие же одинокие автотестеры. Самое простое и правильное решение – объединить их в комьюнити, где они смогут спросить совета, похвастаться элегантным решением трудной задачи, получить адекватную критику и обратную связь. Да просто пообщаться с коллегами «по цеху»!

Проблема №4: запуск автотестов в CI и интеграция с TMS

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

Из нашего опыта хорошей практикой решения проблемы являются следующие шаги:

• настроить регулярный запуск автотестов;

• настроить выгрузку в TMS результатов каждого запуска для сбора объективной статистики;

• встроить автотесты в пайплайн CI и не завершать его успешно при упавших тестах;

• собрать на публичном дашборде команды метрики успешности автотестов и результаты их выполнения в CI.

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

Проблема №5: долгое ожидание пользы от автоматизации тестирования

Причин может быть множество. Время требуется и на изучение специфики тестируемой системы, и на выбор инструментов тестирования, и на создание первого автотеста, и на коммуникации с другими тестировщиками и объяснение им проделанной работы, и на взаимодействие с девопсами. Проблема особенно заметна, когда в компании есть несколько систем. Так наступает бесконечный день сурка.

Для нас в ДОМ.РФ лучшим решением было создание отдельной сервисной команды автоматизации тестирования, которая создала единый фреймворк. Таким образом, рутинные задачи по старту автоматизации удалось оптимизировать и ускорить появление первых результатов.

Решения

Мы применили эти решения в своей работе, и сейчас на нашем фреймворке находятся 15 команд. От первой задумки до первого полноценного теста в CI требуется от одного до трех дней.

Далее я расскажу, как мы внедрили эти решения в ДОМ.РФ.

Шаг первый: сбор информации

Мы собрали список из 10 проектов, где срочно требовалась автоматизация тестирования. По каждому проекту провели встречу: коллеги показали нам систему, рассказали об основных кейсах для автоматизации, предоставили доступ к тестовым стендам. Из этих 10 проектов в качестве пилота мы выбрали три, которые показались самыми разнообразными с точки зрения автоматизации тестирования, а к остальными мы решили вернуться чуть позже.

Шаг второй: выбор инструментов для автоматизации тестирования

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

Выбранный стек:

• Java;

• Maven;

• Junit;

• Cucumber, Gherkin;

• Selenium, Selenide;

• Allure.

Шаг третий: разработка своего фреймворка силами сервисной команды

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

В основе фреймворка должно быть:

• поднятие и закрытие браузера;

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

• генерация популярных рандомных значений (паспорт, дата, СНИЛС, ИНН и т.п.);

• взаимодействие с MQ и БД;

• проверки сообщений, обработка ошибок системы и т.п.;

• скачивание и загрузка файлов разных форматов;

• формирование Allure-отчета.

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

Наши задачи:

• регулярно собирать потребности по автоматизации от проектных команд;

• реализовывать эти потребности во фреймворке или предоставлять такую возможность автоматизатору проектной команды;

• исследовать новые инструменты и возможности;

• решать глобальные задачи по автоматизации, такие как интеграция с TMS/настройка CI/заказ виртуальных машин и т.п.;

• обучать автоматизаторов и ручных тестировщиков проектных команд;

• развивать фреймворк компании, чтобы максимально закрывать потребности проектных команд.

Шаг четвертый: создание пилота по автоматизации в проектной команде

Имея на руках фреймворк, возвращаемся к одной из пилотных команд. Задача – написать для них первые 5—10 автотестов. В процессе дописываются необходимые Cucumber-шаги, добавляются задачи в бэклог сервисной команды на доработку, уточняются детали у проектной команды. В процессе написания настраиваем удаленный запуск в CI и интеграцию с TMS. Когда всё готово, проводим демо-встречу с командой для передачи пилота. После повторяем тот же алгоритм с двумя другими проектными командами из первой очереди.

Что входит в передачу пилота:

• разработанные автотесты выгружаются в gitlab проектной команды, при необходимости создается новый репозиторий;

• настраивается регулярный запуск автотестов с рассылкой результатов в CI;

• демонстрируется работа автотестов и объясняется, как их использовать в ручном тестировании или при разработке;

• проводится обучение работе с автотестами автоматизатора проектной команды или ручного тестировщика.

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

Шаг пятый: масштабирование автоматизации и развитие возможностей фреймворка

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

Итоги

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

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

Сейчас сообщество автотестеров состоит как из нескольких опытных java-разработчиков, так и из автоматизаторов, которые только начинают знакомиться с программированием. Общими усилиями за последние два года мы смогли развить автоматизацию тестирования больше чем на 15 проектах ДОМ.РФ разного уровня сложности.

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