Не искали волшебников, а вырастили их сами: история создания команды автоматизаторов без магии

Привет, Хабр! Меня зовут Наталия, и я руковожу отделом тестирования в группе компаний Экзон. Начала карьеру в IT 7 лет назад с позиции стажера автоматизатора, работала фулл-стек тестировщиком, тех-лидом и имею опыт построения команд тестирования с нуля.

Когда я пришла на проект, у нас было 9 тестировщиков, из которых только двое умели писать автотесты. Остальные работали вручную, а покрытие автотестами составляло 30% на двух модулях из шести. Регресс длился вечность, баги вылезали в продакшене, а команда мечтала о волшебной кнопке “Протестировать всё”. Но вместо поиска магии мы выбрали стратегию, которая сократила время регресса и жизнь багов. И да, мы не нанимали дорогих аутсорс-гуру и не продавали душу рекрутерам.

3 «Стандартных» Варианта, Которые Не Сработали (и Почему)

1. Аутсорс-автоматизаторы

«Они же эксперты!» VS «Они даже не читают документацию!»

Проблемы:

• Собеседования не спасают — часто приходят «теоретики», а не практики.

• Погружение = боль — вместо изучения проекта сыплются бесконечные вопросы.

• Контроль отнимает больше времени, чем сама автоматизация.

Специфика работы с аутсорсом — необходим более жесткий контроль за скоростью и качеством выполнения задач. У команды начинается гонка за количеством, чтобы продемонстрировать свою “полезность”, не учитывая влияние на работу команды продукта. Они часто бездумно пролистывают документацию и заваливают «старичков» вопросами уровня «Как создать пользователя?». А если проект сложный, без глубокого погружения не обойтись. В итоге вместо экономии получаем дополнительные затраты времени и нервов.

2. Нанять своих автоматизаторов

«Давайте возьмём крутых спецов!» VS «Где вы, о великие QA-гуру?»

Проблемы:

• Борьба за кадры — хорошие автоматизаторы уже работают (и хорошо зарабатывают).

• Долгий онбординг — даже если наймёте, придётся объяснять нюансы проекта.

• Переплата — рынок диктует высокие зарплаты.

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

3. Оставить как есть и надеяться

«Мануальное тестирование — это надёжно!» VS «Надёжно = медленно»

 Проблемы:

•     Регресс занимает недели и постоянно увеличивается.

•     Люди устают от монотонной работы = демотивация.

•     Нет перспективы развития, часто тестировщики не идут в компанию, где нет возможностей роста.

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

Наш выбор: Вырастить своих автоматизаторов

Мы выбрали четвертый путь — не нанимать, а обучать. Почему?

•        4 из 9 тестировщиков уже хотели учить автоматизацию.

•        Новые кандидаты в ближайшей перспективе тоже хотели развиваться.

•        Свои люди уже знают продукт — не нужно тратить месяцы на онбординг.

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

Как мы превратили мануальщиков в автотестеров

Шаг 1. Индивидуальный подход к обучению

Не все любят курсы, не все любят книги. Поэтому мы давали выбор:

•     Платные курсы (частично оплачивала компания)

•     Бесплатные материалы (статьи, видео, документация)

•     Поддержка наших автоматизаторов (никакого «гугли сам»)

Результат:

•     Кто-то освоил базу за 3 месяца и рвался в бой.

•     Кому-то понадобилось больше времени (не все курсы одинаково полезны).

•     Некоторые поняли, что автоматизация — не их, и это нормально.

Тут сразу подмечу, что обучение у каждого проходило индивидуально, с комфортным темпом и при наличии свободного времени на это. Никого не подгоняли и не заставляли, старались помогать, если приходили с вопросами. По мере роста команды появлялись еще желающие попробовать себя в этом деле, автоматизация оказалась заразительна!

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

Конкретные курсы перечислять не буду, перебрали несколько, но, в результате, поняли, что один и тот же курс всеми воспринимается по-разному, кто то прошел от и до и достиг результатов, кто то не смог воспринимать подачу лектора и перешел на другие материалы.

Шаг 2. Рефакторинг фреймворка

Важным моментом стало подготовить фреймворк, сделать его более масштабируемым и с четкой архитектурой, учесть все варианты его использования в будущем. Так, одной из главных задач, было перейти на подготовку тестовых данных “на лету”, без привязки к снапшотам или конкретным стендам. В дальнейшем это позволило запускать автотесты на любых окружениях (включая проды), в любом порядке и без опасений сломать пользовательские данные. 

Итого, пока новички учились, мы избавлялись от legacy-костылей:

•        Выпилили Cucumber — он только мешал писать сложные тесты.

•        Сделали тесты стендонезависимыми — больше никаких падений из-за сломанных снапшотов БД.

•        Добавили API-слой для подготовки тестовых данных.

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

Шаг 3. Код-ревью без боли

Первые попытки писать автотесты — это страшно. Вчерашние эксперты вынуждены оказаться вновь в роли джуна, это доставляет дискомфорт и неудобства, а иногда и раздражение. Поэтому постарались смягчить начальный этап практики:

•     Индивидуальные разборы ошибок (не всем комфортно на общих ревью).

•     Постепенное усложнение задач (сначала простые тесты, потом хардкор).

Эти действия уменьшили стресс для новичков, сделали процесс адаптации мягче и сократили время последующих код-ревью.

Подводные камни и как их обойти

Наш подход дал отличные результаты, но были и сложности:

1.   Не все дошли до финиша

•     30% обучающихся «отсеялись»

•     Решение: Заранее закладывайте «норму отсева»

2.   Технический долг во фреймворке

•     Пришлось параллельно рефакторить

•     Решение: Выделили 20% времени автоматизаторов на поддержку

3.   Ресурсные конфликты

•     «Срочные задачи» мешали обучению

•     Решение: Зафиксировали «часы на автоматизацию» в графике

Что получили в итоге?

К концу 2024 года:

•        10 автоматизаторов (из них 7 — бывшие ручные тестировщики) из 25 тестировщиков на 8 модулей.

•        Покрытие выросло до 20% по всем модулям (было 30% на двух).

•        Ускорился регресс (меньше рутины — больше времени на сложные кейсы).

•        Баг-радар срабатывает раньше — ловим ошибки ещё на этапе функционального тестирования.

Вывод: стоит ли игра свеч?

Определённо да. Мы:

•        Сэкономили бюджет (не переплачивали за аутсорс и дорогих спецов).

•        Прокачали команду (мотивированные тестировщики с новым навыком автоматизации).

•        Ускорили процессы (меньше ручного регресса — быстрее релизы).

Планы на будущее:

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

•     Переводим ещё больше тестировщиков в автоматизацию.

•     Увеличиваем покрытие и масштабируем подход на другие проекты.

•     Доводим покрытие автотестами основного функционала до 80% к концу 2026 года.

  А как у вас обстоят дела с автоматизацией? Делитесь в комментариях!