Тестировщик — это ходячая Википедия. QA-инженер о том, как быть на хорошем счету у коллег
Как зарекомендовать себя на онбординге
Для онбординга важно, чтобы на проекте уже был QA, помогающий с адаптацией. Но так бывает далеко не всегда — иногда ты становишься человеком, которого готовят на замену другому специалисту, или тестировщик находится на долгом больничном, или увольняется, или по другим причинам не в состоянии провести онбординг. В таком случае адаптация нового сотрудника полностью ложится на плечи проджект-менеджера либо разработчика, а эти люди зачастую знают о тестировании только со стороны своей профессии, без подробностей, которые нужны узкому специалисту.
Чтобы не попасть в такую ситуацию во время онбординга, важно вести себя заинтересованно и брать ответственность за погружение в проект. Самостоятельно задавать коллегам вопросы по требованиям, кредам, задачам, спринтам, тестовой документации на проекте. Четко сформулировать для себя, что это за проект, какие в нем основные механизмы, какой вид у приложения или сайта, какой бэкенд, кто из людей по какому направлению работает. Сразу идти в разработку, потому что только там сотрудники точно знают, как сделаны фичи. Это поможет не задавать неуместные для грамотного специалиста вопросы вроде «Я нашел баг, к кому мне обратиться?» или «А это баг или нет?». Подразумевается, что тестировщик может отличить баг от фичи после ознакомления с техническим заданием и требованиями.
Эти рекомендации подойдут и тем, у кого онбординг изначально был проведен качественно, — такая проактивность в любом случае сформирует положительное впечатление у коллег.
Как найти подход к разработчикам
Общение с разработчиками не всегда бывает простым — не каждый привык к развернутой коммуникации. Иногда ответ на волнующий вопрос от девелопера звучит как сухое «нет» или «да» без пояснений. Тестировщику нужно с этим смириться, отбросить человеческий фактор и научиться идти до конца, чтобы вытащить необходимую информацию.
Некоторые воспринимают эти «нет» категорически, внутри поднимается возмущение, не хочется больше ничего говорить и писать. Хороший специалист закрывает глаза на эмоциональную составляющую и относится к диалогу как к рабочей задаче. Можно представить, что это Chat GPT, для которого необходимо составить правильный промт — пока ты это не сделаешь, то не получишь нужный ответ.
Как оправдать ожидания команды от тестировщика
Проджект-менеджер ждет от тестировщика релевантных проекту знаний и навыков. Тестировщики на проекте и разработчики хотят, чтобы коллега-аутстафер хорошо понимал инструменты и методологию и ловил информацию на лету — не придется тратить время на обучение, только подсказывать. И все вместе они ожидают, что у сотрудника будут хорошо развиты софт скилы. Если тестировщик умеет говорить, разбирается в инструментах и не теряется в новых условиях, то вопросов к нему никогда не будет.
Можно сказать, что софт скилы в момент знакомства с проектом и командой имеют первостепенное значение. Сильный специалист без проблем изучит новые инструменты, а навыки коммуникации за пару недель подтянуть невозможно. Тестировщик не должен знать все технологии на свете, зато должен постоянно общаться с командой, поэтому зачастую он является единственным человеком, который знает проект от и до. Разработчик не разбирается в аналитике, аналитик не знает в деталях, как устроена реализация фичей, ПМ не понимает, как подойти к тестированию, а тестировщик интересуется каждой деталью и пытается во всем разобраться. Такому профессионалу жизненно необходимо умение общаться.
Четыре правила тестировщика
1. Не давать повод думать, что хорошо знаешь инструмент, которым не пользовался или пользовался мало.
Как-то я работал с коллегой, который заявлял, что хорошо разбирается в конкретном инструменте. Подозрения возникли, когда он начал употреблять его название с ошибками и неправильно описывать возможности. Команда задумалась — как такое возможно? Было очевидно, что сотрудник соврал, и на самом деле изучает инструмент в процессе работы. Никто не стал указывать тестировщику на этот промах, и специалист довел проект до конца, но с негативным фидбэком и испорченным мнением о себе у коллег.
2. Не игнорировать сообщения.
3. Быть инициативным.
Не нужно ждать, когда тебе дадут задачу или что-то объяснят. Ценный тестировщик проявляет инициативу, предлагает новое, улучшает процессы, напоминает о себе, показывает свою заинтересованность и следит за тем, чтобы над багами шла работа. Такие активные сотрудники часто потом переходят в менеджмент, потому что их знают и запоминают.
4. Быть честным.
Не надо врать и приукрашивать. Например, бывают ситуации, когда тестировщик в аврале забывает что-то протестировать и скрывает это, чтобы избежать факапа перед командой — стыдно, неудобно. Так делать запрещено. Лучше сказать честно и попросить дополнительное время на задачу, потому что любая ошибка тестировщика может вылиться в потери для бизнеса, если пропущенный баг зальют в прод. Виноват в этом будет именно тестировщик, который постеснялся признаться в своем промахе.
