Как легко онбордить нового сотрудника в тестировании

138

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

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

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

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

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

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

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

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

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


Неделя

Цель

Задачи

Контроль

1

Подготовка рабочего места.


Знакомство со структурой компании.


Знакомство с основными регламентами компании.

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

Беседа по взаимодействию отделов при разработке ПО


Беседа по процедуре интеграции


2

Изучение инструментов тестирования

Научиться работать с Jira, Testit, Confluence

Демонстрация работы с инструментами тестирования

Настройка тестовой зоны

Научиться настраивать тестовую зону

Демонстрация настройки скремблированного потока, открытия каналов в разных системах команд.


Демонстрация работы с сервисами на приемнике.


4

Анализ логов

Научиться снимать и анализировать логи

Локализация найденного бага

5

Проведение тестирования и описание найденных дефектов

Провести полноценное тестирование на выданном релизе.

Оформить найденные дефекты.

Разбор найденных/пропущенных дефектов и качества их оформления.

6

Работа по текущим проектам команды



12

Работа по текущим проектам команды



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Wiki системы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Была ли статья полезной?