Home

Автор: Александр Шленский

Вступление

Я работаю на позиции QA Automation Engineer более 7 лет. За это время команда автоматизаторов выросла с 7 до 70 человек, и мы продолжаем расширяться. В нашей компании группы ручного и автоматического тестирования находятся в отдельных командах. 

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

У нас хорошо развито автотестирование: на момент написания статьи у нас  более 100 тысяч уникальных тестов. На нашем основном продукте около 45 тысяч приемочных end-to-end-тестов. Это экономит более 400 часов ручного тестирования. При условии, что один прогон длится 1,5 часа. Чтобы все это работало, мы используем и разрабатываем свои внутренние инструменты.

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

• Автоматизаторы тратили меньше времени на поддержку, больше на разработку.

• Ручное тестирование начало лучше понимать тесты, а значит, больше доверять им.

• Сотрудники начали развиваться в новом для себя направлении, повышая навыки, нужные в компании. Например, знание Python и внутренней инфраструктуры.

В общем, мы задумали курс по обучению ручного тестирования принципам и основным подходам к автоматизации. 

В первую очередь мы хотели, чтобы тестирование научилось понимать код автотестов и могло самостоятельно вносить минимальные правки (менять локаторы, переменные, данные и т.д.) в случае необходимости актуализации тестов. Это помогло бы дать дополнительное время на разработку автоматизатору и развить тестировщиков. 

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

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

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

Что мы сделали?

Разбили курс на 2 блока: «Основы Python» и «Обзор возможностей нашего фреймворка». Курс состоял из 9 вебинаров по 1,5 часа. После каждого вебинара мы давали задания для выполнения. Между вебинарами был недельный перерыв, чтобы люди спокойно могли со всем разобраться. Мы понимали, что это игра вдолгую, поэтому не надеялись на быстрый результат.

Блок 1. Основы Python. Начали с самых азов, чтобы любой сотрудник в будущем мог начать осваивать Python даже с нулевым опытом в программировании. 

План выглядел так:

Мы не совершили педагогических или методических открытий — все темы давно есть в свободном доступе. Старались подробно рассказать об основах и сделать упор на те аспекты, которые постоянно используем в работе, опустив некоторые темы. Например, как работает интерпретатор Python, форматирование вывода чисел с плавающей точкой, работа с регулярными выражениями и т.п. Это позволило быстрее достигнуть поставленной цели, чем общие курсы. 

Домашние задания сотрудники решали после каждой части. Задания были по типу «Проверь себя» и основывались на только что пройденном материале. Обычно это 6–8 небольших примеров: 

• Сложите цифры целого числа;

• Выведите все чeтные кратные трeм числа в диапазоне от 1 до N;

• Напишите функцию, которая проверяет, является ли число палиндромом;

• Используя модуль datetime, напишите функцию change_month, которая к переданной дате прибавляет/вычитает переданное количество месяцев.

Блок 2. Обзор работы нашего фреймворка, написанного над Selenium. В нем мы старались показать, как строятся наши интерфейсы, основные механики, как быстро и эффективно использовать, описывать и переиспользовать наши решения.

Принцип построения тот же: 5 вебинаров на разные темы. В качестве домашних заданий было написание тестов. 

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

Результаты фокус-группы

После первых четырех вебинаров, которые были посвящены Python, результаты не оправдали наших ожиданий. Только 5 человек из 13 поспевало за предложенным темпом — 1 вебинар в неделю и выполнение заданий по нему. Проблемы были самые разные и зачастую стандартные: неправильно рассчитали время, многое не поняли, трудно без подсказок. 

Мы решили не опускать руки и доделать начатое. Старались максимально разжевывать темы, чтобы увеличить понимание и уменьшить порог входа. В итоге все так или иначе стали глубже понимать, как работают автотесты. А 6 тестировщиков начали поддерживать и разрабатывать свои тесты. 

Нам удалось научить и заинтересовать чуть меньше половины участников. Мы посчитали, что это неплохой результат. Все было сделано не из-под палки и если хотя бы двузначный процент из 500+ тестировщиков компании станет лучше разбираться в автотестах, то уже мы сможем сэкономить время на поддержку. Это важно и для самих сотрудников тестирования — они осваивают навыки и повышают квалификацию.

После подведения итогов мы решили выложить курс «Для всех».

Что не предусмотрели?

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

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

Тут нам на помощь пришел плагин PyCharm Edu для PyCharm, в который можно внести свои задачи и проверки к ним. Легкий в установке и обращении. Все задачи портировали туда. Желающие могут ознакомиться с ними.

Наплыв вопросов и отзывов. Чем больше становилось людей, тем больше они задавали вопросов. От «А почему тут не работает?» до «Помогите установить гит и покажите решения». В какой-то момент и на это стало уходить много времени. В компании работает более 500 тестировщиков, многие из которых то и дело решаются штурмовать «олимп автотестов». 

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

Но как бы ни была хороша ваша документация, всегда найдутся те, кто ее плохо читает. Со временем количество ссылок в личных сообщениях стало надоедать и отнимать время, тогда мы создали общий чат «Техподдержка автотестирования». Так мы решили 2 проблемы: 

• Вопросы стали задаваться обдуманно, ведь теперь их видят 160+ участников чата;

• На вопросы могут отвечать не только автоматизаторы, но и сами тестировщики, которые уже набили шишки.

  

Обновление материала. Со временем автотестирование в нашей компании семимильными шагами двигалось вперед, а наш курс начал устаревать. Например, мы перешли с unittest на pytest, разбили наши репозитории, переименовали важные зависимости. Конечно, общие подходы остались, но каждое отклонение от рассказанного в видео вызывало десяток вопросов. И если текстовую базу знаний можно без проблем поправить, то с видео это не так. Мы стараемся выпускать новые вебинары и публиковать новости (с одновременным занесением в базу знаний), которые помогают разобраться в нововведениях и изменениях. 

У нас в компании выделяется часть рабочего времени на прохождение внутренних курсов. И даже имеется мотивация их проходить: для тестировщиков, которые поддерживают тесты, добавляют 10% к текущему грейду. Чтобы был контроль, мы сделали итоговый тест из 40 вопросов: 20 вопросов на знания Python, 20 вопросов на знание подходов работы автотестирования в нашей компании. При проходном балле 70, у 55 участников — отличная успеваемость. Почти все уверенно справляются с нашими заданиями. 

Курс доступен всем 1,5 года. За это время его начали проходить более 200 человек. 

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

Что у нас получилось?

• Более 30 мануальных тестировщиков стали помогать автоматизации.

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

• У тестирования выросло общее понимание устройства автотестирования. Как следствие, повысилось доверие к тестам. 

• Улучшилась общая техническая грамотность. 

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

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

• Теперь мануальное тестирование может самостоятельно делать мелкие правки, а автоматизаторы — больше заниматься разработкой новый тестов, инструментов и курсов для тестирования.

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

Сегодня у нас есть инфраструктура, где, как нам кажется, сотрудник может освоить основы автоматизации. У него есть понимание, что делать, что решать, куда задать вопрос, где почитать и посмотреть интересующую информацию.

Обсудить в форуме