Процессы и автоматизация проекта с нуля
Есть множество статей про технологии и те или иные подходы к автоматизации. Но почему-то нет статей про «обратную сторону» автоматизации. Как вообще всё зарождается на проекте? И как это «всё» организовать? Ниже будет рассмотрен пример компании Россельхозбанк.
Общая информация по проекту
Большой проект с командами, разрабатывающими общий продукт;
В командах есть 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 manual самостоятельно пишут автотесты. Один раз за спринт автоматизатор приходит в команду и принимает написанные автотесты, делает правки и вливает в основную ветку. На этом этапе ребята качают уровень написания правильных сценариев, а мы получаем качественные проверенные сценарии;
После встречи со всеми командами у автоматизатора в спринте остается еще 5-6 свободных дней. Это время тратим на разработку Cucumber шагов;
В конце спринта на продуктовом демо показываем результаты по командам и делаем анонсы новых фич в инструменте.
Результаты
6 спринтов (60 дней), 8 команд, 2 автотестера и 11 ручных тестировщиков - имеем 50% покрытия регресса проекта автотестами. Это с учетом подключения команд (подключались постепенно) и разработки шагов.
Вещи, о которых нужно помнить при разработке с таким подходом
Ручной тестировщик - это клиент. QA инженер - прямой потребитель инструмента автоматизации. Их уровень комфорта, счастья и количество автотестов - это показатель качества нашей работы. Если один из показателей падает, значит нужно что-то менять. Иначе все посыпется.
Ориентация на выгоду для проекта. Нужно всегда помнить, что содержание разработчиков, тестировщиков, аналитиков и других специалистов стоит денег. В конечном итоге наша цель их сэкономить. Как мы их экономим?
Автотестами: находим дефекты запуская их каждый день.
На каждом этапе тестирования сокращаем время регресса.
Все это приводит к более быстрому выпуску продукта в промышленную эксплуатацию.
Не работает? Меняй! Не нужно бояться ошибок. Их будет очень много в разработке, в общении с командами, во взаимодействии с QA инженерами, в демо. Главное увидеть, что «что-то» не работает и менять подход до тех пор, пока все не будут в восторге. Всё делаем для людей. Не для себя.
Источники:
Доп. материал:
Last updated
Was this helpful?