Задача тестировщика — находить изъяны в продукте, созданном другими. Но если разработчики ревностно относятся к поиску багов и считают тестировщика лишним звеном, конфликта не избежать. Расскажем, как не стать врагом команды разработки.
Мария Волкова Лид-инженер центра экспертизы ПО в Газпромбанке
Руководителю проекта необходимо выпустить новую фичу или апдейт вовремя. Но на каком-то этапе процессы встали, и мы получили один из двух кейсов:
В обоих случаях тестировщик выступает в роли злодея, который не делает продукт, а только критикует его. К тому же делает это слишком долго и не объясняет подробно, что не так. В итоге нередко возникают споры.
Чтобы отношения разработчиков и тестировщиков не переросли в перманентный конфликт, надо общаться. Во-первых, с коллегами, чтобы понимать причины задержек на их стороне. Во-вторых, с менеджером, чтобы еще на этапе, когда понятно, что сроки будут сдвинуты, спланировать новый реалистичный дедлайн и предупредить заказчика.
Вот несколько полезных советов:
Идеально, когда у тестировщиков есть хотя бы минимальные навыки программирования, а у разработчиков — понимание процесса тестирования. Это позволит им лучше понимать друг друга. Например, в Газпромбанке разработчики и тестировщики обладают соответствующими скиллами. К тому же у нас принято, чтобы специалисты обоих направлений участвовали в устранении багов наравне.
Я верю, что хороший продукт получается, когда в команде выстроены хорошие рабочие отношения. А для этого тестировщикам необходимо налаживать коммуникацию со всей командой разработки. От этого выиграют все: компания получит продукт высокого качества, а пользователи будут реже сталкиваться с багами.
В Газпромбанке над экологичными взаимоотношениями в коллективе работают scrum-мастера: они выстраивают процессы, помогают создавать эффективные коммуникации и достигать целей.
Кроме того, мы внедрили так называемые Value Streams — кросс-функциональные команды, объединяющие разных экспертов от бизнеса и IT, которые вместе работают над продуктом. Например, улучшают клиентский путь по открытию и пополнению вкладов.
При возникновении конфликтной ситуации, тестировщик всегда может обратиться к scrum-мастеру или же к команде стрима.
Творцы-разработчики и злодеи-тестировщики
Руководителю проекта необходимо выпустить новую фичу или апдейт вовремя. Но на каком-то этапе процессы встали, и мы получили один из двух кейсов:
- Тестировщик получил продукт на проверку со сроком «вчера» вместо положенных 5 дней, потому что разработчики не успели с доработками. И приходит продлевать дедлайн.
- Тестировщика торопили с репортами, и он не успел подробно описать баги. Разработчик не понимает, что править.
В обоих случаях тестировщик выступает в роли злодея, который не делает продукт, а только критикует его. К тому же делает это слишком долго и не объясняет подробно, что не так. В итоге нередко возникают споры.
Как снизить вероятность конфликта
Чтобы отношения разработчиков и тестировщиков не переросли в перманентный конфликт, надо общаться. Во-первых, с коллегами, чтобы понимать причины задержек на их стороне. Во-вторых, с менеджером, чтобы еще на этапе, когда понятно, что сроки будут сдвинуты, спланировать новый реалистичный дедлайн и предупредить заказчика.
Вот несколько полезных советов:
- Оговаривайте сроки заранее. Регулярные встречи и предварительные договоренности о дедлайнах на каждом этапе исключат взаимное недовольство.
- Подробно описывайте баги. Даже если мало времени. Не говорите «вот это не работает» — давайте детальное описание, подкрепленное логами, ссылками на тестовую документацию или мнением аналитика, который подтвердит, что перед нами «баг, а не фича».
- Сразу переходите к сути. В гайдах по обратной связи учат, что сотрудника нужно похвалить, прежде чем переходить к критике. В тестировании на это нет времени. Когда мы работаем над устранением недочетов, важно именно устранить недочеты. А разработчика хвалят после релиза —например, на ретро-созвоне, когда команда будет обсуждать события и процессы, случившиеся в течение спринта.
- Обходитесь без колких формулировок. Если вы напишете разработчику «Допустить такую ошибку мог только полный…» — конфликт обеспечен. Важно подбирать нейтральные формулировки, особенно если команда для вас новая и неясно, какой подход работает с тем или другим специалистом. По этой же причине лучше избегать шуток.
- Если конфликт возник, переходите в приватный разговор. Не нужно раздувать ситуацию публично. Устройте отдельный технический митинг и обсудите с разработчиком все детали тет-а-тет или вместе со scrum-мастером.
- Совет для новичков: обращайтесь за помощью к старшим товарищам. Если возникла конфликтная ситуация, не стесняйтесь обращаться к руководителю направления или scrum-мастеру, который окажет психологическую поддержку и завизирует баги.
Идеально, когда у тестировщиков есть хотя бы минимальные навыки программирования, а у разработчиков — понимание процесса тестирования. Это позволит им лучше понимать друг друга. Например, в Газпромбанке разработчики и тестировщики обладают соответствующими скиллами. К тому же у нас принято, чтобы специалисты обоих направлений участвовали в устранении багов наравне.
А что еще сделали мы
Я верю, что хороший продукт получается, когда в команде выстроены хорошие рабочие отношения. А для этого тестировщикам необходимо налаживать коммуникацию со всей командой разработки. От этого выиграют все: компания получит продукт высокого качества, а пользователи будут реже сталкиваться с багами.
В Газпромбанке над экологичными взаимоотношениями в коллективе работают scrum-мастера: они выстраивают процессы, помогают создавать эффективные коммуникации и достигать целей.
Кроме того, мы внедрили так называемые Value Streams — кросс-функциональные команды, объединяющие разных экспертов от бизнеса и IT, которые вместе работают над продуктом. Например, улучшают клиентский путь по открытию и пополнению вкладов.
При возникновении конфликтной ситуации, тестировщик всегда может обратиться к scrum-мастеру или же к команде стрима.
