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

415

Как онбордить опытных и не очень инженеров в 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 планирует уход с российского рынка. Скорее всего, появятся релевантные аналоги.

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

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

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

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

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