«У команды не должно возникать вопроса, чем занят тестировщик»

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

Спикеры — QA Lead Андрей Бракоренко и QA Никита Кузнецов.

Чек-лист действий тестировщика на новом проекте

Андрей Бракоренко

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

1. Узнайте, что вам нужно делать, если коллеги об этом не рассказали сразу. Не ждите молча, когда кто-то сам придет к вам с задачей.

2. Получите доступы к необходимым средам — трекерам задач, TMS, тестовым контурам.

3. Познакомьтесь с членами команды и поймите, у кого какая проектная роль, и с кем вам предстоит взаимодействовать.

4. Спросите, какие в команде есть традиции и правила. Менее формальные: как проходят дейли, обязательные и необязательные встречи, достаточно ли вам быть просто слушателем или необходимо брать на себя роль спикера. И более формальные: как ведется документация, в каком виде предоставляются отчеты о тестировании, какие инструменты используются.

Эти четыре простых действия помогут не растеряться на новом месте и обеспечить себя необходимой информацией о проекте.

Важные софт скилы тестировщика

Никита Кузнецов

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

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

Андрей Бракоренко

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

Важно формулировать вопросы так, чтобы собеседник не тратил время на выяснение подробностей. Не «у меня ничего не работает», а «вот это не работает при таких-то условиях, я уже пробовал сделать это и это, в чем может быть проблема?».

О необходимости проявлять инициативу

Андрей Бракоренко

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

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

Об адекватной оценке своих навыков

Никита Кузнецов

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

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

Как не раздражать разработчиков

Никита Кузнецов

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

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

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