# Процессы и автоматизация проекта с нуля Есть множество статей про технологии и те или иные подходы к автоматизации. Но почему-то нет статей про «обратную сторону» автоматизации. Как вообще всё зарождается на проекте? И как это «всё» организовать? Ниже будет рассмотрен пример компании Россельхозбанк. ## Общая информация по проекту * Большой проект с командами, разрабатывающими общий продукт; * В командах есть 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) --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://vladislaveremeev.gitbook.io/qa_bible/avtomatizaciya-testirovaniya/ci-cd-i-infrastruktura/processy-i-avtomatizaciya-proekta-s-nulya.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.