Путь тестировщика: как не стать врагом создателей продукта, выполняя свою работу

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

Мария Волкова

Лид-инженер центра экспертизы ПО в Газпромбанке

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

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

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

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

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

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

Вот несколько полезных советов:

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

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

А что еще сделали мы

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

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

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

При возникновении конфликтной ситуации, тестировщик всегда может обратиться к scrum-мастеру или же к команде стрима.