Добрый день! Я – Елена Поплоухина, руководитель группы тестирования в компании Usetech. В этой статье хочу поделиться информацией о том, как мы на протяжении 7 лет выстраивали практику обучения тестировщиков. Конечно же, я расскажу про успехи, проблемы (как же без них) и их решение.

Мы использовали 2 основных подхода к обучению:

• Квартальные цели.

• Профиль тестировщика.

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

Нужна ли единая практика обучения?

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

Более 7 лет назад наша группа тестирования начиналась с 2 человек. Никакой практики обучения не было. Постепенно мы набирали новых сотрудников уровня junior и middle. У QA команды существовала нехватка знаний и опыта в нагрузочном тестировании, тестировании мобильных приложений, работе с базами данных. Передо мной как руководителем группы встала большая задача — повысить квалификацию QA инженеров. Я решила подойти системно к вопросу и внедрить единую практику обучения. 

Группа тестирования на тот момент состояла из 5 человек, включая меня. Я взяла на себя роль организатора и технического ментора. 

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

Квартальные цели

Первой мы внедрили практику квартальных целей. Она просуществовала примерно 3,5 года. Рассмотрим подробно ее суть.

В начале каждого квартала мы вместе с сотрудником выбирали цель по обучению на ближайшие 3 месяца. Отсюда и название практики - "квартальные цели". При выборе цели мы ориентировались на "пробелы" в знаниях и опыте тестировщика. Например:

• Изучить нагрузочное тестирование веб-приложений.

По правилам практики цель в течение 3 месяцев мы не меняли.

После формулирования цели мы расписывали критерии достижения — при каких условиях цель будет считаться выполненной? По правилам может быть максимум 3 критерия. Обычно мы устанавливали 2 критерия — один по теории, другой по практике.

Например:

• Получен сертификат о прохождении курса по нагрузочному тестированию.

• На проекте Х проведено нагрузочное тестирование.

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

Например:

• Пройти курс по нагрузочному тестированию веб-приложений с использованием JMeter.

• Изучить официальную документацию JMeter.

• Провести нагрузочное тестирование проекта.

• Изучить и при необходимости обновить корпоративный шаблон методики о НТ.

• Создать корпоративный шаблон отчета о НТ.

Отдельным блоком шел список источников обучения. Частично он оформлялся при первом описании документа — теми источниками, про которые знали я и сотрудник. Этот список дополнялся тестировщиком по мере выполнения цели. Туда входили ссылки на курс, статьи, корпоративные документы и т.д.

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

Все результаты фиксировались. Квартальная цель велась в отдельном для каждого сотрудника Excel документе. Он имел такой вид:

Мнемоника SMART для целей

В теории все выглядит легко и логично. А на практике мы столкнулись со сложностями. Спойлер — все удалось успешно преодолеть.

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

S – (Specific) – точные

M  –  (Measurable) – измеримые

A  – (Attainable) – достижимые

R  –  (Relevant) – релевантные

T  – (Time bound) – ограниченные по времени

При внедрении этой практики мы не обратили должного внимания на мнемонику и потеряли 2 буквы – A и R. К чему же это привело?

Цель не соотносится с проектом

Мы не учитывали букву R  из мнемоники SMART, что значит  релевантная цель. И иногда выбирали цель, которая не относится к текущему проекту сотрудника. Например, мы ставили цель «Изучить нагрузочное тестирование». Но на проекте в течение квартала было предусмотрено только функциональное тестирование.

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

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

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

Во всех этих случаях получалось, что цель не относится к проекту сотрудника.

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

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

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

Как решить проблему

После нескольких случаев постановки нерелевантных целей мы решили следующее:

• либо мы пытаемся адаптировать цель под проект;

• если не получается, то такую цель брать не нужно. 

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

Недостижимая цель

Еще одна буква из мнемоники  SMART, которую мы не учли – А – достижимая цель. Мы ставили цели, которые невозможно выполнить за 3 месяца.

Например:

• Поднять уровень специалиста с junior до middle.

• Изучить автоматизацию тестов пользовательского интерфейса с использованием Java и Selenium.WebDriver. 

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

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

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

В этом случае на контрольной точке я как ментор открыто проговаривала, что цель была поставлена неправильно.  Затем мы с сотрудником обсуждали, что удалось сделать и ставили статус "частично выполнено".

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

Как решить проблему

Могу дать следующие советы:

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

• При сомнении в достижимости цели можно попросить провести ревью  одного из старших специалистов, которые имеют экспертизу по цели.

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

Как мотивировать сотрудников на обучение? 

В практике обучения участвовали все тестировщики – и когда группа состояла из 5 человек, и когда из 20.

Обучение преимущественно было желанием самого сотрудника. Я предлагала участвовать в практике – и QA инженеры соглашались без специальных уговоров. Я как наставник помогала составить план обучения, оценивала результат, давала фидбек. Дополнительным фактором являлось то, что уже при найме тестировщиков мы оценивали желание учиться. В нашей компании сотрудники могут менять проекты, поэтому требуется работать с новыми видами тестирования, технологиями, инструментами. Это привычное требование нашей меняющейся IT отрасли.

Дополнительными мотивирующими факторами были следующие:

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

• Перспективы перехода на новые проекты, более интересные для сотрудника, при выполнении плана по обучению и применению навыков.

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

• Участие в общей активности мотивирует само по себе.

Как выделить время на обучение

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

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

• В случае очень загруженных проектов — можно выделять по часу в день с утра, несколько раз в неделю. Учитывая, что обучение всегда коррелируется с проектом — это все равно “работа на проект”. И обычно это время не так заметно с точки зрения выполнения текущих задач, чем время в середине дня или вечером. Плюс вечером накапливается усталость.

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

• Личное время. Только при желании самого сотрудника. Это относится, в том числе к курсам. Обычно прохождение курсов требует значительного количества времени, которое не получается выделить в рамках работы. Поэтому перед прохождением мы с сотрудником договариваемся, сможет он потратить личное время или нет. Многие соглашаются, понимают, что это вклад в себя. Но если сотрудник говорит “сейчас не могу” – то ок, с такой позицией тоже согласны.

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

Итог по практике квартальных целей

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

Сотрудник и наставник получали наглядный процесс роста за год.

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

Тем не менее через 3.5 года я решила отказаться от квартальных целей и перейти на более подходящий для нас способ обучения. Что же послужило причиной и какой новый способ мы выбрали? Читайте в следующей статье.