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