Как онбордить опытных  и не очень инженеров в QA-команду? Расскажем об основных этапах на примере команды GS Labs, поделимся планом, что сделать в первую очередь. Эти принципы легко можно адаптировать под инженеров любого уровня, которых вы нанимаете. 

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

Старт работы для любого нового сотрудника начинается с испытательного срока. Целью и положительным результатом испытательного срока является успешное «подключение» к команде.

Основные задачи на испытательный срок: 

• Знакомство с командой

• Знакомство с задачами отдела

• Выполнение индивидуальных задач

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

Пример плана из жизни, компания GS Labs:

Задачи онбординга можно условно разделить на несколько категорий:

• Работа с документацией

• Работа с тест кейсами

• Тестирование и работа с дефектами

Используемые инструменты

Для каждой задачи используются свои инструменты. Рассмотрим каждый из них подробнее.

Системы тест-менеджмента

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

Например, существует тест кейс, проверяющий отправку широковещательного сообщения.

Рис.1 Кейс по отправке сообщения.

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

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

Рис.2 Устаревший кейс.

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

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

Рис. 3. Обновленный кейс.

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

Wiki системы

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

Рис. 4. Использование wiki систем в качестве базы знаний.

Система имеет свой API, что позволяет автоматизировать работу с ним. В Confluence удобно планировать задачи, существует интеграция с баг-трекинговой системой того же производителя — JIRA.

Рис. 5. Использование ссылок на JIRA в Confluence

В подобных инструментах удобно писать документацию, например, необходимые каждому тестировщику спецификации.

Основной недостаток этой системы на момент написания статьи — планируемый уход Atlassian из РФ.

Известно, что до конца 2022 года выходит российский инструмент по управлению совместной работой TeamStorm, который, по заявлению разработчиков, будет иметь аналогичную функциональность продуктам Atlassian: Confluence, Trello и др. Его можно будет без проблем интегрировать с Test IT TMS, так как это продукты линейки шеф-бренда Yoonion. 

Баг-трекинговая система

Долгое время в компании GS Labs, на чьем примере мы разбираем тему онбординга, использовалась система Redmine, но развитие компании и рост команды потребовали большего. Выбор был сделан в пользу баг-трекера JIRA.

Изначально JIRA предназначалась только для отслеживания ошибок. Однако сейчас она используется и для планирования Agile-проектов.

JIRA представляет собой интерактивную доску (дашборд), с помощью которой можно следить за выполнением поставленных задач. Все задачи классифицируются различными видами work item: функции, подзадачи, дефекты и т. д. Их легко можно редактировать, назначать на различных исполнителей или просто изменять статус с «открыт» на «закрыт». Все изменения по задаче логируются и отражаются в журнале. Система немного сложнее Redmine, однако и к ней новые сотрудники привыкают легко.

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

Но, как говорилось ранее, Atlassian планирует уход с российского рынка. Скорее всего, появятся релевантные аналоги.

Вместо заключения

В борьбе за таланты компании все больше стремятся к совершенствованию адаптационных процессов. Сегодня есть много эффективных инструментов, которые позволяют провести адаптацию сотрудника «безболезненно».

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

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