Автоматизация тестирования «с нуля» (нетехническая сторона вопроса)
Есть множество статей про технологии и те или иные подходы к автоматизации. Но почему-то нет статей про «обратную сторону» автоматизации. Как вообще всё зарождается на проекте? И как это «всё» организовать?
Итак, здравствуйте! Меня зовут Ярослав, я являюсь лидером автоматизации тестирования в Центре развития финансовых технологий Россельхозбанка. В этой статье поделюсь своим опытом организации автоматизации на примере большого проекта РСХБ из 8 команд.
Общая информация по проекту
Большой проект с командами, разрабатывающими общий продукт.
В командах есть QA Manual (Ручной тестировщик).
Направления тестирования — Frontend, Backend.
Изучаем проект
Понимаем цель разработки продукта и кто потребитель
Ответы на эти вопросы помогают понять, на что делать упор в автоматизации. Например, если работаем с юридическими лицами, то делаем упор на тестирование «исполнения законодательства» и переводы по платежам и тд. Если это физические лица, то на основные выполняемые операции: переводы с карты на карту, оплату услуг и тп. Так же важно, чтобы направление автоматизации «смотрело» в целом на продукт, а не на отдельные в нем команды.
Знакомимся с участниками разработки продукта
В нашем случае нужно быть знакомым со всеми, так как необходимо будет взаимодействовать тем или иным образом.
Выделю ключевых людей:
Владельцы продуктов (Product Owners), они заказчики автоматизации в команде.
QA каждой команды. Они — это клиенты инструмента автоматизации, их уровень счастья — это показатель успеха.
Лидер ручного тестирования. Помогает в организации процесса и во взаимодействии с ручным тестированием.
Лидер разработки Frontend. Он влияет на стабильность и качество автотестов.
Специалист по закупке. Решит вопросы выделения техники, в основном с серверным железом.
Изучаем каждую команду
Собираем информацию о том, какую часть проекта разрабатывает команда.
Разбираемся в направлении — Frontend, Backend или всё сразу.
Разбираемся с тем, как QA тестируют свою часть продукта.
Выясняем, на каком уровне QA manual знаком с автоматизацией.
Находим боли в тестировании и что приоритетно закрыть автоматизацией.
Формируем требования к автоматизации и заказываем ресурсы
Что мы собрали?
У нас есть 8 команд.
Есть 11 QA инженеров.
Есть направления тестирования Frontend, Backend + будем «ходить» в Базу данных.
90% QA manual никогда не занимались автоматизацией.
Исходя из данных, формируем требования к автоматизации
У нас нет задачи делать какие-то инновационные решения, поэтому придерживаемся классики:
В качестве языка программирования выбираем Java — так будет проще найти специалистов.
Нужно тестировать Frontend. Берем Selenium.
Нужно тестировать Backend. Взаимодействуем с ним через REST. Берем REST-assured.
Нужно «ходить» в базу данных. Возьмем стандартные библиотеки из Java.
Нужно либо обучить QA manual разработке автотестов, либо нанять армию из N автоматизаторов. Мы думаем о расходах проекта на тестирование, поэтому убиваем 2-х зайцев сразу. Берем Cucumber.
Нам нужна отчетность с красивыми графиками. Берем Allure.
Получился следующий стек технологий: Java, Selenium, REST-assured, Cucumber.
Оцениваем силы автоматизаторов
Поскольку их нет, берем 1 автоматизатора на 5 команд (больше 5-и не потянет).
Автотесты нужно где-то запускать
Что нам понадобится?
Машина для Jenkins. 1 штука. Через него реализуем удаленный запуск.
Машина под Slave Jenkins. Как agent для Jenkins.
Машина под Selenoid. Для параллельного запуска тестов.
Делаем демо нашего инструмента
Наше демо будут смотреть все: владельцы продуктов, QA инженеры, разработчики, аналитики и тд. Значит ориентируемся на понимание для всех.
Берем команду в качестве первой «жертвы» автоматизации. Ребята разрабатывают Frontend. Нам нужна наглядность.
Делаем 5–10 автотестов. Записываем на видео.
Обязательно после прогона показываем Allure. Красивые графики любят все.
Рисуем «инфраструктуру автотестов». Главное, чтобы было просто и понятно.
Обозначаем главную цель автоматизации.
Демонстрируем эффект от автоматизации.
Делаем сравнительные тесты. Ручное прохождение и автоматизированное.
Показываем, как создаются сценарии.
Показываем планы автоматизации (когда появятся тот или иной функционал).
Показываем, как будет происходить внедрение автоматизации в команды.
Подготавливаем UI к автоматизации
Для обеспечения надежности, стабильности и качества автотестов, необходимо раскидать якоря на UI. Централизованно через лидера Frontend и дополнительно через владельцев продукта проставляем атрибут для UI-элементов «data-test-id» или с любым другим названием. Смысл в том, чтобы со стороны UI проставить этот атрибут во всех элементах типа «Таблица, поле для ввода, кнопка» и тд. Если коротко, то на всех элементах, с которыми взаимодействуем, это даст +300% к надежности автотестов. Переезд элемента в другое место или изменение его содержимого никак не повлияют на проверку автотестом. Делаем этот момент обязательным для всех новых фич.
Разрабатываем автотесты
Делим команды между автотестерами.
Разрабатываем каркас проекта для автоматизации. Все по шаблону.
Подготавливаем набор Cucumber шагов для работы с Frontend, основным направлением в тестировании. Выносим шаги в отдельный проект и делаем из него подключаемый артефакт.
Настраиваем Selenoid и Jenkins.
Начинаем подключать команды к автоматизации. При подключении команды все сводится к тому, чтобы создать репозиторий, загрузить каркас, создать Job в Jenkins по шаблону, обучить QA работе с Cucumber, работе с Git и средой разработки.
После обучения QA самостоятельно пишут автотесты. Один раз за спринт автоматизатор приходит в команду и принимает написанные автотесты, делает правки и вливает в основную ветку. На этом этапе ребята качают уровень написания правильных сценариев, а мы получаем качественные проверенные сценарии.
После встречи со всеми командами у автоматизатора в спринте остается еще 5–6 свободных дней. Это время тратим на разработку Cucumber шагов.
В конце спринта на продуктовом демо показываем результаты по командам и делаем анонсы новых фич в инструменте.
Результаты
6 спринтов (60 дней), 8 команд, 2 автотестера и 11 ручных тестировщиков — имеем 50% покрытия регресса проекта автотестами. Это с учетом подключения команд (подключались постепенно) и разработки шагов.
4 вещи, о которых нужно помнить при разработке с таким подходом
Ручной тестировщик — это клиент
QA инженер — прямой потребитель инструмента автоматизации. Их уровень комфорта, счастья и количество автотестов — это показатель качества нашей работы. Если один из показателей падает, значит нужно что-то менять. Иначе все посыпется.
Ориентация на выгоду для проекта
Нужно всегда помнить, что содержание разработчиков, тестировщиков, аналитиков и других специалистов стоит денег. В конечном итоге наша цель их сэкономить.
Как мы их экономим?
Автотестами: находим дефекты запуская их каждый день.
На каждом этапе тестирования сокращаем время регресса.
Все это приводит к более быстрому выпуску продукта в промышленную эксплуатацию.
Не работает? Меняй!
Не нужно бояться ошибок. Их будет очень много в разработке, в общении с командами, во взаимодействии с QA инженерами, в демо. Главное увидеть, что «что-то» не работает и менять подход до тех пор, пока все не будут в восторге. Всё делаем для людей. Не для себя.
Кайфуй
Наверное, самое главное в любой работе — это получать удовольствие. До сих пор с умилением смотрю на автотесты. Я тоже был QA manual инженером и прекрасно понимаю, насколько нудно тестировать регресс раз за разом. Автотесты — это бальзам:)
