Home

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

Оригинал статьи: http://katrinatester.blogspot.ru/2017/10/identifying-and-influencing-how-people.html

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

Вклад в автотесты

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

Если я поменяю эти метки на роли, это может выглядеть так:

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

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

Тот, у которого есть только мотивация – это адвокат. Это источник энергии для всей команды.

Перекрестки этих границ:

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

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

Изобретатели – это те, у кого есть доступ и мотивация, но нет навыков. Они видят, что происходят, это приводит их в экстаз, но у них нет навыков для прямого участия. По моему опыту они будут делиться идеями – некоторые из идей будут безумными, а некоторые – гениальными. Эти люди – источник инноваций.

А в самом центре находятся вкладчики. Обычно именно они держат набор тестов на плаву. У них есть и доступ, и навыки, и мотивация.

Вклад людей в автоматизацию тестирования

Смена ролей

Теперь, когда вы пометили всех коллег по их отношению к вашей тест-автоматизации, подумайте, на «правильном» ли месте они находятся.

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

Подумайте о том, как люди относились к автоматизации в четырех вышеописанных командах.

Команда номер один

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

Команда номер два

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

Команда номер три

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

Команда номер четыре

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

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

Масштаб изменений

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

Доступ

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

В некоторых случаях «доступ» просто означает возможность просмотреть отчет о тест-результатах на сервере непрерывной интеграции вроде Jenkins. Такой уровень доступа может быть достаточным для бизнес-аналитика или продакт-оунера в плане покрытия автоматизацией продукта.

Раздумывая о доступе, спросите себя:

• Что могут видеть ваши наблюдатели?
• С какими типами проблем могут помогать те, кто их решает?
• Как уровень доступа ограничивает поток идей ваших изобретателей?
• What are your observers able to see?

Навыки

Навыки – это не просто умение программировать. Эш Уинтер (Ash Winter) разработал колесо тестирования. С моей точки зрения, это полезный шаблон для более широкого подхода к навыкам:

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

Каковы различия в навыках между вашими учителями, тренерами, «решателями» проблем? В чем вы опытны, и в чем вам опыта не хватает? Какой тренинг необходим вашей команде?

Мотивация

Мотивация – это не просто заявления «я хочу тест-автоматизацию» или «я не хочу тест-автоматизации». Это спектр – насколько человеку этого хочется? Ваш менеджер может голосовать за 100% тестовое покрытие, а ваш разработчик может полагать, что более одного UI-теста – это потеря времени.

Насколько вовлечены ваши адвокаты? Нужно ли им сильнее давить или, наоборот, слегка ослабить хватку?

Насколько вовлечены ваши тренеры и изобретатели?

Более широкая перспектива

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

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

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

Заключение

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

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

Тестировщики владеют ключевым навыком для перемен – мы ежедневно задаем вопросы.

Как ваши коллеги вкладываются в тест-автоматизацию?

Кто занимается дизайном, разработкой и поддержкой ваших тест-наборов?

Что произойдет, если вовлеченность людей в автоматизацию в вашей команде изменится?

Как вы можете повлиять на эти перемены?

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