> For the complete documentation index, see [llms.txt](https://vladislaveremeev.gitbook.io/qa_bible/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://vladislaveremeev.gitbook.io/qa_bible/avtomatizaciya-testirovaniya/ci-cd-i-infrastruktura/processy-i-avtomatizaciya-proekta-s-nulya.md).

# Процессы и автоматизация проекта с нуля

Есть множество статей про технологии и те или иные подходы к автоматизации. Но почему-то нет статей про «обратную сторону» автоматизации. Как вообще всё зарождается на проекте? И как это «всё» организовать? Ниже будет рассмотрен пример компании Россельхозбанк.

## Общая информация по проекту

* Большой проект с командами, разрабатывающими общий продукт;
* В командах есть 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.

{% hint style="info" %}
**Современная альтернатива 2025:** Для новых проектов рассмотрите GitHub Actions вместо Jenkins, Playwright вместо Selenium, TypeScript вместо Java для frontend-тестов. Jenkins остаётся в enterprise-инфраструктурах как legacy backbone.
{% endhint %}

## Оцениваем силы автоматизаторов

Поскольку их нет, берем 1 автоматизатора на 5 команд (больше 5-и не потянет).

## Автотесты нужно где-то запускать

Что нам понадобится?

* Машина для **GitHub Actions** (self-hosted runner) или Jenkins для legacy-проектов. 1 штука. Через него реализуем удаленный запуск;
* Машина под runner/agent. Как agent для CI;
* Машина под Selenoid или Playwright Grid. Для параллельного запуска тестов.

{% hint style="info" %}
**Современный подход:** GitHub Actions предоставляет бесплатные minutes для публичных репозиториев и 20 параллельных воркеров для платных планов. Для локальных запусков рассмотрим Playwright Grid или Docker-контейнеры.
{% endhint %}

## Делаем демо нашего инструмента

Наше демо будут смотреть все: владельцы продуктов, QA инженеры, разработчики, аналитики и тд. Значит ориентируемся на понимание для всех.

Берем команду в качестве первой «жертвы» автоматизации. Ребята разрабатывают Frontend. Нам нужна наглядность.

* Делаем 5-10 автотестов. Записываем на видео;
* Обязательно после прогона показываем Allure. Красивые графики любят все;
* Рисуем «инфраструктуру автотестов». Главное, чтобы было просто и понятно;
* Обозначаем главную цель автоматизации;
* Демонстрируем эффект от автоматизации;
* Делаем сравнительные тесты. Ручное прохождение и автоматизированное;
* Показываем, как создаются сценарии;
* Показываем планы автоматизации (когда появятся тот или иной функционал);
* Показываем, как будет происходить внедрение автоматизации в команды.

## Подготавливаем UI к автоматизации

Для обеспечения надежности, стабильности и качества автотестов, необходимо раскидать якоря на UI. Централизованно через лидера Frontend и дополнительно через владельцев продукта проставляем атрибут для UI-элементов "data-test-id" или с любым другим названием. Смысл в том, чтобы со стороны UI проставить этот атрибут во всех элементах типа «Таблица, поле для ввода, кнопка» и тд. Если коротко, на всех элементах, с которыми взаимодействуем, это даст +300% к надежности автотестов. Переезд элемента в другое место или изменение его содержимого никак не повлияют на проверку автотестом. Делаем этот момент обязательным для всех новых фич.

## Разрабатываем автотесты

* Делим команды между автотестерами;
* Разрабатываем каркас проекта для автоматизации. Все по шаблону;
* Подготавливаем набор Cucumber шагов для работы с Frontend, основным направлением в тестировании. Выносим шаги в отдельный проект и делаем из него подключаемый артефакт;
* Настраиваем Selenoid и CI/CD pipeline;
* Начинаем подключать команды к автоматизации. При подключении команды все сводится к тому, чтобы создать репозиторий, загрузить каркас, создать workflow/job в CI, обучить QA работе с Cucumber, работе с Git и средой разработки;
* После обучения QA manual самостоятельно пишут автотесты. Один раз за спринт автоматизатор приходит в команду и принимает написанные автотесты, делает правки и вливает в основную ветку. На этом этапе ребята качают уровень написания правильных сценариев, а мы получаем качественные проверенные сценарии;
* После встречи со всеми командами у автоматизатора в спринте остается еще 5-6 свободных дней. Это время тратим на разработку Cucumber шагов;
* В конце спринта на продуктовом демо показываем результаты по командам и делаем анонсы новых фич в инструменте.

## Результаты

6 спринтов (60 дней), 8 команд, 2 автотестера и 11 ручных тестировщиков - имеем 50% покрытия регресса проекта автотестами. Это с учетом подключения команд (подключались постепенно) и разработки шагов.

## Вещи о которых нужно помнить при разработке с таким подходом

### Ручной тестировщик это клиент

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

### Ориентация на выгоду для проекта

Нужно всегда помнить, что содержание разработчиков, тестировщиков, аналитиков и других специалистов стоит денег. В конечном итоге наша цель их сэкономить. Как мы их экономим?

* Автотестами: находим дефекты запуская их каждый день.
* На каждом этапе тестирования сокращаем время регресса.

Все это приводит к более быстрому выпуску продукта в промышленную эксплуатацию.

### Не работает меняй

Не нужно бояться ошибок. Их будет очень много в разработке, в общении с командами, во взаимодействии с QA инженерами, в демо. Главное увидеть, что «что-то» не работает и менять подход до тех пор, пока все не будут в восторге. Всё делаем для людей. Не для себя.

## Источники

* [Автоматизация тестирования «с нуля» (нетехническая сторона вопроса)](https://habr.com/ru/company/rshb/blog/591449/)

### Дополнительные материалы

* [Гайд внедрения автоматизации тестирования, если ты рядовой QA инженер](https://www.youtube.com/watch?v=LSlF_0LqYAM)
* [Путь к автоматизации тестирования в SuperJob: инструменты, проблемы и решения](https://habr.com/ru/company/superjob/blog/577042/)
* [Как мы автоматизировали тестирование бэкенда](https://habr.com/ru/company/ru_mts/blog/578600/)
* [Готовим приложение для автоматизации тестирования](https://habr.com/ru/post/654959/)
* [О чем спрашивать, унаследовав тест-автоматизацию](https://telegra.ph/O-chem-sprashivat-unasledovav-test-avtomatizaciyu-01-11)
* [Андрей Солнцев - Воркшоп: Как начать свой проект автоматизации с нуля. Продолжение (часть 1)](https://www.youtube.com/watch?v=h254Tccxgq4\&list=PLsVTVVvrKX9td9Zm_4nF6Ywlz6gC5_e7K\&index=15)
* [Андрей Солнцев - Воркшоп: Как начать свой проект автоматизации с нуля. Продолжение (часть 2)](https://www.youtube.com/watch?v=WETyt87o_R4\&list=PLsVTVVvrKX9td9Zm_4nF6Ywlz6gC5_e7K\&index=16)
* [AQA Checklist / Score для интеграции Автоматизации тестирования в существующие Agile процессы](https://www.youtube.com/watch?v=Z6svY5iTdac)
* [5 заклинаний для команды автоматизации](https://www.youtube.com/watch?v=kbDOZLcQsBo)
* [Организация мониторинга бизнес-процессов (с нуля до автоматизации)](https://www.youtube.com/watch?v=CdH_OB_G5RA)
* [Вместо 100 запусков приложения - один автотест, или как сэкономить QA-инженеру 20 лет жизни](https://habr.com/ru/company/pixonic/blog/503704/)
* [Автоматизация тестирования в микросервисной архитектуре](https://habr.com/ru/company/avito/blog/509280/)
* [Как (авто)тестировать Монстра](https://habr.com/ru/company/rshb/blog/518374/)
* [Как автоматизировать тестирование на проекте, где по 100 релизов в месяц](https://dou.ua/lenta/columns/test-automation-in-parimatch/)
* [Процесс автоматизированного тестирования за 10 шагов](https://habr.com/ru/company/otus/blog/546148/)
* [How Does Test Planning Differ For Manual And Automation Projects?](https://www.softwaretestinghelp.com/automation-test-palnning/)
* [Step By Step Guide To Implement Proof Of Concept (POC) In Automation Testing](https://www.softwaretestinghelp.com/implement-proof-of-concept-poc-in-automation-testing/)
* [How To Perform Automation Testing Of JAVA/J2EE Applications (Part 2)](https://www.softwaretestinghelp.com/automated-testing-of-j2ee-applications-part-2/)
* [Как мы научились запускать 10-часовые UI-тесты за 5 минут в условиях 30 релизов в день](https://habr.com/ru/company/sberbank/blog/660891/)
* [Как мы организовали «Автошколу» и научили тестировщиков писать автотесты](https://telegra.ph/Kak-my-organizovali-Avtoshkolu-i-nauchili-testirovshchikov-pisat-avtotesty-04-12)
* [QA без рутины: как мы автоматизировали регрессионное тестирование](https://habr.com/ru/company/mygames/blog/665576/)
* [Функциональные тесты на проекте: жизнь до и после (на примерах)](https://habr.com/ru/company/skyeng/blog/659559/)
* [GitHub Actions documentation](https://docs.github.com/en/actions)
* [Playwright CI/CD guide](https://playwright.dev/docs/ci)