5 дней для погружения и знакомства с командой — про наш новый формат онбординга в формате квеста. Краткое пособие для джунов и лидов: какие задания ждут на старте и как пересмотреть процесс адаптации для команды из 10+ QA.
Привет! Меня зовут Настя, я руководитель QA-отдела Red Collar. Расскажу про онбординг на сервисных проектах для нашей команды QA. Его цель: настроить коммуникацию между командой и познакомить со всеми необходимыми инструментами. Идея нашего онбординга-квеста масштабируемая, так что формат может применяться и в других отделах.
«Меня кидали в воду, а я должна была поплыть, или нет», — уходим от такого подхода на старте работы
Мой опыт на проектах в других компаниях был такой: меня кидали в воду, а я должна была поплыть, или нет. Приходилось самой много изучать, а ответы на вопросы часто затягивались. Бывало, что люди сами не знали, кто может помочь с моим запросом.
Придя в Red Collar, в первую очередь я решила проработать процесс онбординга на проектах — сделать его максимально информативным и безболезненным. Чтобы человек погружался не только в процессы, но и знакомился с командой, понимал зоны ответственности каждого на проекте.
Начала с ресерча и изучения разных форматов онбординга в компаниях. После структурирования всей информации меня зацепила идея онбординга в виде квеста, и я решила попробовать сделать что-то подобное. Добавила этапы знакомства, проверки навыков для джуниор-специалистов или тех, у кого ранее был другой опыт.
Онбординг длится рабочую неделю. Каждый день — это список задач и ожидаемого результата. Документ с ними получает каждый тестировщик.
День 1: знакомство с проектом, документацией и командой
В первый день человек знакомится с внутренними документами компании, получает все доступы и регистрируется на внутренней платформе проекта — в Space. Дальше план такой:
- Получить доступ к TestIT проекта.
- Ознакомиться с инструкцией заведения дефектов.
- Создать задачу в Space, назначить ее на себя и прикрепить к борде.
- Присутствовать и представиться на дейлике команды. Перед этим в личке связаться с тимлидом и менеджером проекта, чтобы вас добавили на встречи.
Для знакомства с другими участниками и инструментами у нас есть Тест-план (мастер) — документ с информацией о проекте и полным составом команды, а также контактами и описанием их компетенций. Добавляем сюда и окружение: ссылки на Swagger, Storybook, тестовый стенд.
Также у нас есть ожидания от сотрудника в первый день. Основная задача — знакомство со Space, поэтому помимо выполнения заданий я жду в личке сообщение человека о том, какой фичи ему не хватает в системе, например. Так я понимаю, что сотрудник изучил платформу и вопросов по ней не возникнет.
Схематично ожидания первого дня выглядят так, формат для остальных дней по формуле «ожидание и реальность» схожий:
Так у нас проходит первый день: заданий немного, больше направлено на коммуникацию и знакомство. Ребята, которые уже работали на подобных проектах, автоматически пропускают первые пункты и переходят к следующему этапу.
День 2: знакомство с аналитиком и творчество написания тест-кейсов
Второй день — сначала изучение информации о проекте в Notion и записей встреч. Это довольно длительный процесс, так что его можно проходить постепенно и фоном.
Тестировщики постоянно контактируют с аналитиками, ведь у них сосредоточена вся информация о проекте. Основная задача второго дня — знакомство с аналитиком и изучение документации. Вопросы и уточнения по документации возникают всегда, особенно если тестировщик знакомится с ней впервые. Отсюда следующее задание квеста: написать любой вопрос о use case, например, от формата ведения документации до формата полей. Вопрос может быть любой, главное — начать контакт с аналитиком.
Дальше оттачиваем творчество написания тест-кейсов и глубже погружаемся в работу с ними. И новая задача: используя use case, придумать 3 тест-кейса и записать их пока в комментарии в Space.
На этом этапе мы настраиваем работу в общем направлении и корректируем некоторые моменты, чтобы сонастроиться. Это помогает человеку быстрее влиться, вникнуть в процессы и проще проходить ревью. Конечно, написание тест-кейсов — мастерство индивидуальное, но в большой команде обычно у всех вырабатывается единый стиль.
Финалим второй день — знакомимся с правилами заведения багов. Частенько некоторые игнорируют их, хотя документ является одним из основополагающих, особенно для джуниор-специалистов.
На этом этапе я жду, что каждый пришлет мне дефект, который обнаружит во время прочтения правил в самих правилах. Как правило, во второй рабочий день каждый очень внимательно читает документ и ищет в нем любые ошибки. А вот есть ли в задании дефект на самом деле — думайте сами. 🙂
Сверяемся с ожиданиями и переходим к другому блоку.
День 3: привет, дизайн-команда и TestIT
Сначала изучаем TestIT: нашу структуру, теги и оформление тест-планов.
Дальше знакомимся с дизайном проекта и дизайнером, которому нужно написать и спросить, какой блок он закончил последним, а какой сейчас в работе. Написать 5 тест-кейсов по последнему отрисованному блоку. Это снова направлено на тренировку написания тест-кейсов и коммуникацию с дизайн-командой.
Потом переносим тест-кейс из комментариев в TestIT вместе с кейсами дня 2 — учимся работать с TMS, если это в первый раз.
На финише дня 3 знакомимся с первой итерацией тест-плана и задаем вопросы по нему тимлиду. Едем дальше.
День 4: разработка и разработчики
На четвертый день мы знакомимся с разработкой и backend-разработчиками. Изучаем Swagger, если кто-то не работал с ним — на этот случай у нас есть инструкция.
Потом пишем backend-разработчику, знакомимся и спрашиваем про авторизацию в Swagger. Затем выбираем микросервис и пишем к нему 2-3 тестовых запроса. Как проверяем себя потом? Снова идем к backend-разработчику — задаем вопросы.
Превращаем все запросы в тест-кейсы. Это тренировка понимания того, с какими инструментами тестировщик раньше работал, а где есть пробелы. Вечером я жду отчеты и провожу ревью тест-кейсов.
День 5: выпускной и переход к реальным задачам
В пятый день знакомимся со Storybook, если он есть на проекте, и frontend-разработчиком — вспоминаем, что его контакты есть в Test Plan Master. Общаемся, спрашиваем про работу разных элементов и пишем 5 тест-кейсов по последнему блоку, над которым разработчик завершил работу.
Теперь мы готовы познакомиться с техническим директором! Пишем ему, представляемся и делимся первыми впечатлениями о проекте и онбординге. Это и психологический момент — в будущем у вас не будет стеснения в коммуникации.
Самое время попросить у лида реальную задачу. За пять дней я рассчитываю, что человек уже достаточно погрузиться и сможет выполнять реальные задания. Вот такая я оптимистка. 🙂
Оценка онбординга командой и сдача его «экстерном»
Бывает, что ребята быстрее воспринимают информацию или ранее уже встречались с некоторыми инструментами — тогда они заканчивают онбординг и за три дня.
«Онбординг помог в кратчайшие сроки выстроить коммуникацию со всеми членами команды. Понять порядок действий и вникнуть во внутренние процессы.
Больше всего понравились мини-задания, для выполнения которых необходимо начинать общение с командой».
Антон, Mobile QA Engineer Red Collar — 2 месяца в команде
В процессе выяснилось, что такой формат онбординга оказался удобным для всех участников команды и начал приживаться у разработчиков — многие заглядывают в наш Test Plan Master и находят нужную информацию. Ну, а мы рады помочь.
