Тестировщик — это ходячая Википедия. QA-инженер о том, как быть на хорошем счету у коллег

Продолжаем серию материалов о том, как тестировщикам успешно вливаться в новые проекты при работе на аутстафе. QA-инженер IT Test (компания-разработчик TMS DoQA) Максим Манжос поделился тактикой успешного прохождения онбординга, рассказал, как добывать информацию у разработчиков, и как вести себя, чтобы оправдать ожидания команды.

Как зарекомендовать себя на онбординге

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

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

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

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

Чтобы не попасть в такую ситуацию во время онбординга, важно вести себя заинтересованно и брать ответственность за погружение в проект. Самостоятельно задавать коллегам вопросы по требованиям, кредам, задачам, спринтам, тестовой документации на проекте. Четко сформулировать для себя, что это за проект, какие в нем основные механизмы, какой вид у приложения или сайта, какой бэкенд, кто из людей по какому направлению работает. Сразу идти в разработку, потому что только там сотрудники точно знают, как сделаны фичи. Это поможет не задавать неуместные для грамотного специалиста вопросы вроде «Я нашел баг, к кому мне обратиться?» или «А это баг или нет?». Подразумевается, что тестировщик может отличить баг от фичи после ознакомления с техническим заданием и требованиями.

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

Как найти подход к разработчикам

Общение с разработчиками не всегда бывает простым — не каждый привык к развернутой коммуникации. Иногда ответ на волнующий вопрос от девелопера звучит как сухое «нет» или «да» без пояснений. Тестировщику нужно с этим смириться, отбросить человеческий фактор и научиться идти до конца, чтобы вытащить необходимую информацию.

Некоторые воспринимают эти «нет» категорически, внутри поднимается возмущение, не хочется больше ничего говорить и писать. Хороший специалист закрывает глаза на эмоциональную составляющую и относится к диалогу как к рабочей задаче. Можно представить, что это Chat GPT, для которого необходимо составить правильный промт — пока ты это не сделаешь, то не получишь нужный ответ.

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

Как оправдать ожидания команды от тестировщика

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

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

Спустя несколько лет на одном проекте тестировщик становится для команды ходячей «Википедией», которая связывает друг с другом отделы и помогает новым сотрудникам разобраться в проекте.

Четыре правила тестировщика

1. Не давать повод думать, что хорошо знаешь инструмент, которым не пользовался или пользовался мало.
Нормально чего-то не знать на новом проекте. Это можно объяснить коллегам и сразу взять ответственность за свое незнание — задать нужные вопросы, самостоятельно поискать информацию в интернете, потратить время на практику. Главное не врать.

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

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

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

4. Быть честным.
Не надо врать и приукрашивать. Например, бывают ситуации, когда тестировщик в аврале забывает что-то протестировать и скрывает это, чтобы избежать факапа перед командой — стыдно, неудобно. Так делать запрещено. Лучше сказать честно и попросить дополнительное время на задачу, потому что любая ошибка тестировщика может вылиться в потери для бизнеса, если пропущенный баг зальют в прод. Виноват в этом будет именно тестировщик, который постеснялся признаться в своем промахе.