Home

Автор: Катрина Клоки (Katrina Clokie)

Оригинал статьи: http://katrinatester.blogspot.ru/2017/08/encouraging-testers-to-share-testing.html

Перевод: Ольга Алифанова

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

Если тестировщики – единственные, кто тестирует, то это душит команду. Это происходит потому, что разработчики и люди бизнеса, участвующие в процессе разработки, не хотят заниматься тестированием. Это может также происходить потому, что тестировщик не хочет, чтобы кто-то еще тестировал. Я сталкивалась с обоими вариантами.

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

Доверие

Доверяете ли вы своей команде? Надеюсь, что большинство из вас работает в окружении, подталкивающем вас к ответу "да". Но что, если я спрошу, доверите ли вы вашей команде тестирование?

В прошлом я неохотно передавала задачи по тестированию коллегам, опасаясь, что они упустят то, что наверняка обнаружила бы я. Я беспокоилась, что они упустят баги. Я доверяла им в целом – я просто не доверяла им тестирование.

Я думаю, что мои сомнения были вызваны их типом мышления.

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

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

Если вы разделяете эти сомнения, или у вас есть свои, мешающие вам "поделиться" тестированием, как можно изменить ситуацию, чтобы вы согласились разрешить другим помочь вам?

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

Эти обсуждения могут положить начало установлению доверия, так как способствуют передаче мышления тестировщика другим членам команды. По прошествии времени тестировщик обнаружит, что его вклад в эти обсуждения снижается до момента, когда они станут вовсе не нужны.

Идентичность

Если ваша роль в команде – тестировщик, то эта идентичность может быть тесно связана с деятельностью, относящейся к тестированию. Что вы будете делать, если вы не тестируете? Если тестировать могут и другие, то что вы тут вообще делаете?

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

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

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

Уязвимость

Третий барьер, который я вижу – это нежелание тестировщиков просить о помощи. Эта особенность не уникальна для тестировщиков, многие не хотят о ней просить. В Agile-команде неспособность привлечь к тестированию коллег может ограничить вашу способность выпускать продукт.

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

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

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

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

***
Если вы работаете в Agile-команде и не решаетесь делиться своими задачами с коллегами, вы можете создать лишнюю нагрузку как на себя, так и на команду, ограничивая скорость разработки. Подумайте о том, что мешает вам просить помощи.

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

Подумайте об этих трех вещах и том, как они влияют на вашу работу. Пусть тестировщики делятся задачами по тестированию!

Обсудить в форуме