Критиковать коллег и сохранять хорошие отношения: опыт тестировщика

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

Творцы-разработчики и суперзлодеи-тестировщики

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

Расскажу, что может ухудшить отношения между специалистами, а если процесс не настроить, то еще и сказаться на самом продукте:

1. Разработчики не успевают с доработкой и тестировщик получает продукт на проверку со сроком «вчера» вместо положенных 5 дней
2. Чтобы понимать, что править, разработчику нужно подробное описание бага, но тестировщика торопили, и он не успел

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

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

Как снизить вероятность конфликта: 4 совета

• Подробно описывайте баги. Не стоит просто говорить «что-то не работает» — давайте детальное описание, подкрепленное логами, ссылками на тестовую документацию или мнением аналитика, который подтвердит, что перед нами «баг, а не фича». Постарайтесь по максимуму проанализировать дефект и предоставить все факты.
• Оговаривайте сроки заранее. Тесное взаимодействие внутри команды на регулярных встречах, предварительные договоренности о сроках, которые необходимо заложить на каждый этап, исключат взаимное недовольство.
• Обходитесь без колких формулировок. Если вы напишите разработчику «Допустить такую ошибку мог только полный…» — конфликт обеспечен. Важно подбирать нейтральные формулировки, особенно если команда для вас новая и неясно, какой подход работает с тем или другим разработчиком. По этой же причине лучше избегать шуток.
• Если конфликт возник, переходите в приватный разговор. Не нужно раздувать ситуацию публично, лучше устроить отдельный технический митинг и обговорить с разработчиком все детали тет-а-тет. Или подключив scrum-мастера.
• И совет для новичков: обращайтесь за помощью к старшим товарищам. Если возникла конфликтная ситуация, не стесняйтесь обращаться к руководителю направления или scrum-мастеру, который окажет психологическую поддержку и завизирует баги.

Секреты профессии: хвалить не надо, разбираться в программировании — желательно

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

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

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

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

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

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

А над экологичными взаимоотношениями в коллективе работают scrum-мастера: выстраивают процессы, помогают создавать эффективные коммуникации и достигать целей.

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