Как комфортно ввести нового тестировщика на проект

Вводить нового человека в работу непросто: даже если это опытный специалист, ему нужно время, чтобы освоиться. Но проекты не привыкли ждать, пока пройдет адаптация нового сотрудника. Поэтому действовать надо быстро и точно. Мы нашли подход, который помогает оперативно вводить новых тестировщиков в боевые проекты без потери в качестве. Как это сделать и чего не стоит бояться новеньким? Об этом рассказала руководитель отдела QA в YuSMP Group, Мария Субботина.

Чтобы новый человек как можно быстрее влился в работу, мы вводим его в проект поэтапно: начиная от первой беседы с ментором и заканчивая самостоятельным решением сложных задач. На этот цикл уходит в среднем 3 месяца — получается стандартный испытательный срок. Опыт показал, что такой подход позволяет избежать лишних ошибок и доработок, при этом мы получаем ощутимую помощь от нового тестировщика уже в ближайшие недели.

В самом начале мы выдаем логины-пароли, добавляем сотрудника во все нужные чаты. Его первая задачка на погружение — проверить свои доступы (Jira, Confluence, 1Password и другие инструменты, которые пригодятся на проектах). После проводится встреча (митинг) с ментором или тимлидом. Ментором может выступать как и тимлид, так и любой другой опытный сотрудник отдела.

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

Запомнить все тонкости с первого раза довольно сложно. Поэтому сотрудник получает от нас памятки в письменном виде – это своеобразный конспект митинга, к которому можно обратиться в любой момент.

После всех обсуждений новичок пробует себя в деле. У него есть подсказки, как работать с фичами и багами. Сперва он пробует самостоятельно решить задачку пока только в тестовом пространстве. Несмотря на то что новый QA-инженер будет работать с «ненастоящим» проектом, ему нужно будет сделать все необходимые шаги: протестировать фичи, описать чек-листы, проработать статусы задач, зафиксировать время.

Получается, на довольно легком задании (часто это функция регистрации или авторизации) QA отрабатывает полный цикл тестирования фичи. После ментор проверяет работу.

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

Знакомство – первая задача новичка в полевых условиях. Необходимо изучить SRS в Confluence, дизайн и тестовый билд, где можно наглядно на практике уже посмотреть и понять проект по требованиям в SRS.

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

Каждая такая задачка тщательно контролируется ментором – наставник дает обратную связь и следит за прогрессом новичка. Постепенно мы доверяем сотруднику все более сложные задания, пока он не станет самостоятельным тестировщиком.

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

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

Что бы я посоветовала тестировщикам в новом коллективе, так это задавать как можно больше вопросов. В команду может прийти опытный сотрудник, и тогда может казаться, что все понятно. Но если есть малейшие сомнения, всегда лучше уточнить. Главное — не бояться показаться не таким подкованным, как хотелось бы выглядеть.

Глупый вопрос? Очевидный вопрос? Смело спрашивайте! Никто о вас не подумает плохо, а для команды ценно ваше понимание всех процессов.

А еще не стоит бояться ошибаться – это тоже нормально. Кому, как не тестировщикам, это знать. Проекты бывают разные, в каких-то будет легко разобраться, другие – даются чуть сложнее.

Если с вами будет ментор – берите от него максимум. Задача наставника максимально ввести вас в процессы.

Через какое-то время наберете опыта и станете более самостоятельным. Наша система менторства предполагает, что это случится через 3 месяца. Но даже когда вы будете вести проекты, никогда не стыдно попросить помощи у старших коллег.

Зачем терять время на тестовые задачи, тратить ресурс на наставничество, отвлекать опытных сотрудников, когда можно сразу дать новенькому рабочие задания?

Звучит неплохо, но на практике мы увидели, что даже классным тестировщикам нужно время для адаптации. Здесь возможны и ошибки, и вопросы – все это тормозит проект. Даже неправильное оформление бага в Jira может неприятно сказаться на работе всей команды. Например, важно максимально коротко и понятно описать, как воспроизвести баг, а также прикрепить видео или скриншот. Если этого не сделать, разработчики будут значительно дольше разбираться, чтобы исправить все замечания.

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