Привет! Меня зовут Ксения, я QA Automation Engineer в inDriver, занимаюсь обучением наших ручных тестировщиков автоматизации. Хочу сразу сказать, что эта статья — не история успеха. Было бы классно написать: «За один год мы научили всех ручных тестировщиков писать автотесты, и теперь у нас 100% покрытие функционала автотестами». Но нет, это история о том, как мы до сих пор ищем способы завести автотесты во всех командах разработки.

Первоначальная ситуация

В начале 2021 года у нас было 8 команд, около 20 ручных тестировщиков и всего 5 автоматизаторов тестирования. Мы начали запускать новый функционал в отдельных сервисах вместо того, чтобы запихивать его в 2 старых монолита (PHP и Go).

Флоу автоматизации тестирования выглядел так:

1. Ручной тестировщик ставил на команду автоматизации тестирования таску, прикладывал свои кейсы.

2. Таска попадала в бэклог к остальным таким же.

3. Команда автоматизации бралась за нее, когда появлялось время.

В ответственность команды автоматизации также входили:

1. Поддержка тестовых билдов в TeamCity и собственного велосипеда, написанного, чтобы облегчить работу и управление этими билдами. 

2. Автоматизация подготовки тестовых данных. 

3. Обновления и фиксы уже готовых тестов, борьба с флакающими. 

4. Мониторинг ситуации с окружениями, отведенными под запуск автотестов. 

Всего в проекте API было 400 автотестов, а в Mobile UI — 0. В то же время, в TestRail лежало 1291 кейсов API и 1741 мобильных.

На 2021 год у нас были большие планы по расширению тестирования. Мы наняли более 30 человек (сейчас у нас 56 человек, занимающихся ручным тестированием), написали еще больше кейсов (в TMS у нас сегодня 4740 кейсов для мобильного приложения и 3447 на API).

Проблема и идея

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

Команда автоматизации стала узким горлышком процесса. И мы решили исправить ситуацию.

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

Так у нас появилась идея «Автошколы»: мы выбираем программу на Kotlin и даем ее обучающимся. Они самостоятельно проходят ее, мы отвечаем на вопросы и помогаем там, где нужно. После того, как они прошли обучение, разбираем с ними, как мы пишем тесты в нашем проекте, и даем первые задачи.

Несколько важных моментов, которые мы хотели учесть:

1. Курс Kotlin должен быть сторонним, мы не хотели тратить время на то, чтобы написать собственный курс.

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

3. Максимально быстро доводить ребят до написания тестов. Мы опустили из курса многие части, связанные с детальным изучением Kotlin, откладывая их на дальнейшее развитие.

Почему мы не выбрали сторонее обучение целиком? Сейчас много разных курсов, где человек за несколько недель получает необходимые знания: по программированию, работе с тестовыми фреймворками и библиотеками, запуску и анализу результатов тестирования.

Мы рассматривали этот вариант, но нас остановило то, что на тот момент не было курсов по автоматизации тестирования, в котором учили писать тесты на Kotlin.

Двумя самыми популярными языками для автоматизации являются Java и Python. В какой-то момент мы решили переписать наши тесты с Java на Kotlin. Тогда еще не думали о том, чтобы учить людей автоматизации тестирования с нуля.

Человек, хорошо знакомый с одним из двух языков, может быстро адаптироваться к Kotlin. Но если у вас нет опыта в программировании, это может оказаться проблемой. Отправлять новичков учить Java или Python, а потом сразу переводить их на Kotlin — для кого-то это могло бы сработать, а для кого-то нет. Поэтому мы решили, что лучше сразу учить всех писать на том языке, который уже используется.

Кроме этого, сторонний курс дал бы абстрактные знания. Допустим, научатся ребята писать запросы на REST Assured. Они будут большими молодцами, только у нас уже есть тесты, и в них он обернут в совершенно другие классы. Поэтому писать запросы и проверять их придется совершенно по-другому.

Кстати, позже мы все переписали, поменяли целиком архитектуру тестов, и выбрали в качестве HTTP-клиента OkHttp. Если знаете, где найти курсы автоматизации тестирования, которые учили бы работе с ним — напишите в комментариях.

«Автошкола 1.0»

Среди трех курсов Kotlin, мы выбрали курс на Stepik. Он устроил нас по программе, большим плюсом были встроенные в него задачи с автоматической проверкой.

Мы взяли 3 добровольцев из разных команд и предложили пройти курс. Не ставили им никаких сроков, просто рекомендовали заниматься 4-5 часов в неделю. Выдали им необходимые доступы и назначили еженедельный созвон, чтобы знать прогресс каждого. Обучение должно было считаться законченным, когда автошкольник мержил свой первый PR. 

Что получилось:

1. Из-за нечетких сроков обучение растянулось на пару месяцев.

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

3. Фраза «На этой неделе не получилось заняться автоматизацией» стала рефреном (не только в «Автошколе 1.0», но и в течение всего года).

4. Мы не хотели одобрять работу ребят над автоматизацией в выходные дни или после работы, но по факту все работали дополнительно. 

5. Несколько раз мы повторяли «правило 20 минут»: если кто-то застрял на проблеме больше, чем на 20 минут, и не продвинулся в решении, лучше задать вопрос. По факту многие сидели и разбирались сами. Иногда это было полезно, а иногда сыпались ошибки, которые было невозможно решить.

6. У ребят появлялись ошибки, с которыми никто в команде автоматизации не сталкивался во время ежедневной работы. В битбакет не пускает ни по SSH ключу, ни по логину-паролю. Проект загрузился в IDEA, но не хочет собираться. Прописали в settings.xml корпоративный мавен-репозиторий, но оно не подтягивается.

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

«Автошкола 2.0»

Мы учли свои ошибки (как нам казалось), и набрали новых ребят. Что изменили:

1. Сделали четкие сроки для прохождения материала. Длительность курса ограничили двумя месяцами, по истечении которых школьники должны были сделать первый PR. 

2. Написали еще больше детальных инструкций.

Но главное — почему-то не сменили курс на Stepik на что-то другое. Судя по оставшимся докам в Confluence, мы обсуждали этот вопрос, но решили отложить на третий квартал 2021 года. Нам казалось, что мы только потеряем время, если начнем искать что-то другое (или, боже упаси, писать свое).

Когда ребята принялись за тесты, мы столкнулись с самой большой проблемой: в «Автошколе 2.0» были ребята из команд, занимающиеся новыми сервисами. Все предыдущие тесты были заточены под работу со старыми монолитами: мы деплоили только их, создавали тестовых пользователей, города и другие данные только для них, делали API-вызовы только в монолиты.

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

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

Так наш бэклог начал забиваться задачами на реализацию подготовки данных.

Еще одна проблема. Задействуем разработчиков

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

Идеальным вариантом было бы, если в команду приходил кто-то, настраивал автоматическую подготовку данных, репозиторий с автотестами. Конечно, было бы круто, если бы мы сами могли это сделать. Но нас мало, а команд много.

Тем временем, наступила середина третьего квартала 2021 года, а мы добились малого. Нужно было ускоряться.

Необходимо было решить следующую проблему: как сделать так, чтобы подготовка и настройка автоматизации прошла как можно быстрее, если у команды автоматизации есть знания, но нет ресурса (а у тестировщика — ни знаний, ни ресурса)?

Решение: задействовать разработчиков в команде.

Подготовка к автоматизации состоит из трех частей:

1. Реализовать механизм подготовки данных.

2. Создать и подготовить проект для автотестов.

3. Настроить билды для запуска деплоя, тестирования и так далее. 

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

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

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

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

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

Когда решение было принято и согласовано с техлидами, начался этап, когда они пытались соскочить. Происходило это так:

1. Мы договариваемся о том, как нужно делать.

2. Техлид уходит.

3. Техлид приходит к нам обратно и говорит, что ему не очень нравится решение.

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

5. Мы договариваемся.

6. Техлид уходит.

7. Техлид вновь приходит и говорит, что ему не очень нравится решение...

Так мы потратили весь 4 квартал 2021 года только на то, чтобы уговорить техлидов. Тем не менее, с одной из двух команд мы все-таки пришли к финалу, и к марту 2022 года ребята начали писать тесты. 

Что дальше? «Автошкола 3.0»

В 2022 году мы вновь дорабатываем проект. Главное: 

1. Мы не берем команды, которые не готовы выделять время тестировщика на тесты, и время команды на помощь тестировщику с подготовкой данных. 

2. Мы сокращаем программу обучения до 10 часов, если речь идет о курсе по Kotlin — с целью того, чтобы ребята могли пройти ее примерно за 2 недели.

А еще мы наконец-то сменили курс обучения со Stepik на курс от JetBrains и петербургского «Политеха» на Coursera (правда, сейчас платформа заблочила все российские курсы).

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

Промежуточные результаты:

1. Почти все команды готовы выделить время на обучение (но несколько все-таки нет). 

2. Программа обучения не сократилась до 10 часов, но хотя бы не занимает 2 месяца. 

3. Про курс от JetBrains многие говорят, что там слишком много математики. С этим я абсолютно согласна (одна из задач там про укладку рюкзака, блин!). 

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

По результатам первого квартала 2022 года у нас, конечно, уже появились новые трудности и новые идеи, как их решить. Так что в 2023 году можно ждать от меня новую статью про это. А пока пишите комментарии и вопросы, которые появились при прочтении статьи. Буду рада ответить на них.

P.S.

В послесловии статьи публикую 2 разнящихся анонимных отзыва об обучении в «Автошколе»:

Привет! То, что я проходил в рамках обучения, вряд ли помогло мне сесть и написать автотест. У меня был опыт написания автотестов до этого, поэтому я считаю, что справился. В свое время меня учил писать тесты, можно сказать, личный ментор. Я вообще не шарил насчет ООП, за всякие там студии, переменные среды, фреймворки — это был темный лес. Считаю, что в рамках курса освоить автотесты просто бы не сумел.

Впечатления — огонь. Детальность статей хорошая, но ряд моментов можно описывать подробнее (не все ясно для новичков). Классным оказалось то, что ментор провел демо, как писать тест — это ускорило написание и понимание в разы. Классными оказались созвоны, когда каждый высказывал свои проблемы. Это помогало понять, что ты не один в количестве вопросов, которые возникают.