В вашей команде есть Middle QA, который хочет развиваться дальше. Что должен делать лид команды, чтобы вырастить из него синьора? Ниже вы найдете советы, основанные на моем опыте. Если вы инженер, тоже читайте дальше - рекомендации помогут понять, как расти и что просить от своего лида.
Будущему сеньору нужен ментор
Если рост от Junior до Middle в основном обеспечивается развитием hard-скиллов, то рост от Middle и выше больше связан с софт-скиллами, хотя техническое развитие тоже не должно отставать.
Вырасти из миддла в синьора довольно сложно и одного желания может быть недостаточно. Наставник поможет пройти этот путь: стать им может как опытный senior или principle, так и лид тестирования.
Прививайте желание разбираться
Кроме опытного наставника у того, кто хочет вырасти, должно быть стремление к развитию, в том числе и саморазвитию, - такие люди дорастают до сеньоров в самые короткие сроки.
Вот как можно включить это в рабочую рутину:
Способствуйте тому, чтобы QA изучали, как устроен продукт с точки зрения архитектуры и взаимодействия. Пусть участвуют в обсуждениях с разработчиками и не боятся задавать даже самые глупые, по их мнению, вопросы. Это можно разъяснять и на встречах 1-на-1, и показывать собственным примером.
Смотрите, чтобы кандидаты на синьоров изучали внутренности инструментов, с которыми они работают при тестировании. Чтобы они лучше понимали, как все устроено внутри, можно не всегда давать полный ответ на их вопросы: давайте взамен ссылку на более исчерпывающую документацию. А иногда полезно вместо ответа сразу отправлять в доку.
Ставьте более высокоуровневые задачи и просите самого QA их декомпозировать. Поначалу потребуется помощь и пример, но затем это добавит человеку самостоятельности и умения разбираться в незнакомом материале.
Развивайте мышление направленное на решение проблемы, а не ее перекладывание. Предлагайте сходить к другим с проблемой и попытаться решить вместе. Например, вместо простого reopen задачи, можно прийти к разработчику и объяснить проблему - возможно ее можно решить быстрее.
Давайте проблему вместо решения
Обычно в задачах для Middle QA расписано детальное решение: “Для тестирования нового сервиса воспользуйся этим инструментом и проверь это и то”. При росте в сторону Senior лучше давать проблему на подумать - и ожидать вариантов решений уже от самого специалиста.
Если мы даем задачу на вырост, тот же пример можно сформулировать по-другому: “Есть новый сервис, как думаешь, что стоит проверить?” При этом можно дать какие-то отсылки к тому, как такое проверялось ранее, - у нас ведь еще не готовый Senior. А потом вместе разобрать сам процесс принятия решения и результаты.
Поощряйте шаринг знаний
Хорошо развивать QA через помощь другим тестировщикам. Например, поначалу отправлять тех, кому требуется помощь, к кандидату на синьора. Потом просить его помогать, не дожидаясь вашего вмешательства, - и ожидать от него инициативы с помощью другим.
Вот еще пара вариантов:
Сделайте почти синьора ментором и прикрепите к нему новичка. Попросите составить план адаптации нового сотрудника: в нем должны быть понятные цели и шаги. Уделите внимание детальности плана - хватит ли его для обучения новичка? И не забудьте про обратную связь от самого нового сотрудника - хватило ли информации ему, была ли она последовательна?
Другая возможность - попросить читать доклады для внутреннего QA-сообщества. Например, будущий сеньор может рассказать о методиках тестирования, технологиях и тонкостях самого продукта, с которыми работает.
Научите расставлять приоритеты и управлять временем
Переход в сеньоры - тот момент, когда нужно давать больше свободы в определении сроков и выставлении приоритетов по задачам. Снижайте контроль постепенно, поначалу просите аргументировать. Например, есть две задачи с одинаковым приоритетом, которые надо взять в тестирование. Попросите специалиста выбрать ту, которую он будет тестировать первой - и попросите объяснить почему.
Отлично, если аргументация будет на уровне пользы для бизнеса и снижения рисков. Если же ответ будет в стиле “меня попросил менеджер”, стоит сесть и вместе разобрать обе задачи, чтобы понять, почему у одной задачи выставлен такой высокий приоритет, а у другой он ниже.
Что еще может сделать тимлид:
Просите анализировать затраченное на задачи время, чтобы специалист учился понимать, как можно было сделать быстрее и лучше.
Помогите выстроить цели на краткосрочный и долгосрочный периоды. Разбейте план развития на этапы, опишите сроки и результаты для каждого. Делайте чекпоинты по окончанию этапов для понимания статуса.
Увеличивайте зону ответственности
С ростом грейда растет и ответственность. Первое, что можно сделать: расширять зону ответственности в работе с задачами. Просите, чтобы QA подключался к работе над задачей в момент ее обсуждения с продактами, знал на какие метрики она влияет, отслеживал статус задачи после релиза. В итоге ответственность тестировщика должна быть за результат, а не только за качество тестирования.
Попросите QA участвовать в обсуждении продукта и новых фич не только как слушателя. Поначалу можно вместе ходить на встречи-обсуждения и смотреть, какие вопросы он задает. Обсуждайте, какие вопросы он не озвучил, почему, повторяйте, что задавать любые вопросы не стыдно.
Еще несколько вариантов:
Можно расширять зону ответственности и внутри слоя QA. Например, попросить специалиста разобраться с инфраструктурой тестирования: узнать, что не нравится, выслушать предложения и выделить время на внедрение инициатив.
Автоматизация тестирования тоже очень хорошо подходит для расширения зоны ответственности. Если она уже настроена на проекте, можно попросить заняться автоматизацией тех задач, которые тестирует конкретный QA. Если ее нет, но у мидла есть интерес, можно попросить его описать, как бы он ее сделал, - и потом вместе постараться внедрить решение.
Учите видеть продукт целиком
Хорошо бы двигать мышление специалиста к пониманию, как задача может повлиять на продукт, какие риски принесет оставленный баг. Обязательно стоит рассказывать про продуктовые метрики - какие есть в принципе, по каким оценивается бизнес, что на что влияет. Чтобы QA понимал, что кроме технических метрик и логики, есть еще и то, как продукт зарабатывает деньги.
Если, например, тестировщик занимается только тестированием backend части, то обязательно стоит погрузить его в то, что происходит на клиентах, и как изменения в бэке влияют на пользователей.
Также вовлекайте сотрудника в работу с отзывами от реальных пользователей. Это дает понимание, как люди пользуются продуктом и какие зоны более важны для пользовательского опыта.
Цените мнение и учите его доносить
Объясните, как доводить найденные баги до завершения: “Нашел проблему - сделай так чтобы ее пофиксили. Для этого бывает нужно доказать, что она важная”. Учите QA использовать аналитику, документацию, привлекать экспертное мнение других людей и т.п.
Очень неплохо для развития специалиста дать ему задачу про выбор метода или инструмента тестирования. Например, лид знает, что нужно провести нагрузочное тестирование какого-то сервиса: он может сам определить процесс и инструмент, а может отдать выбор и аргументацию растущему QA. Это даст тому возможность проявить себя, выразить и аргументировать свое мнение.
Учите анализировать ошибки и принимать критику
QA специалист, который хорошо анализирует собственную работу, не только будет прокачиваться сам, но послужит отличным примером для других. В частности, нужно выделять время на анализ допущенных ошибок и проблемных ситуаций.
Вот что тимлид может сделать для этого:
Разговаривайте с QA и меняйте мышление с “поиска виноватых” на “как не допустить в будущем”. Просите описать, почему произошел инцидент, и составить план, как впредь избегать подобного.
Объясните, что конструктивная критика помогает развитию и принимать ее нужно спокойно, без расстройств и от любого коллеги. Предложите анализировать коммуникации с коллегами: расскажите, как собирать обратную связь и почему нужно делать это регулярно.
Снижайте контроль
Пока перед вами Middle QA, контроль за тем, успевает ли он в сроки, что и как тестирует, как ставит приоритеты - важная часть работы лида. Но с ростом в сторону Senior его надо ослаблять: здесь контроль нужен в основном за результатом.
Нужно, чтобы специалист чувствовал себя более самостоятельным - это поможет передать ему больше ответственности. Снижать контроль можно исходя из роста самостоятельности сотрудника. Но при возникновении систематических проблем контроль надо возвращать и докапываться до сути проблемы.
P.S. Бонус для лида - собеседования
Всегда проще вырастить Senior QA из того, кто уже стремится им стать. Проводя собеседования, вы уже можете понять, готов ли кандидат расти в дальнейшем, выяснив:
Как человек воспринимает ответственность. Например, можно спросить, был ли у него опыт ведения какого-то проекта. Делает ли он что-то по задачам, которые протестировал, после их релиза. Бывали ли задачи с жесткими сроками и как прошел их выпуск.
Проявляет ли он инициативу. Чтобы узнать это, можно спросить, удалось ли ему внести что-то в процесс/инструменты тестирования на последнем месте работы.
Как работает в режиме самостоятельности. Спросите, что бы он делал, если в процессе тестирования задачи найдена проблема, но разработчик, который ее делал, в отпуске. Или как бы он начал тестировать продукт, если документации нет, а люди, которые его тестировали раньше, уже уволились.
Как относится к ошибкам и критике. Спросите, как проходили 1-на-1 с прошлым руководителем, за что его критиковали коллеги. Попросите рассказать о каком-то fail’e и как он с ним работал.
Для QA-инженеров
Все описанное выше поможет тебе вырасти, даже независимо от твоего лида. Бери на себя ответственность, проявляй инициативу, разбирайся с проблемами до конца, будь проактивным и делай свою работу на отлично!
