Текст книги "Agile-тестирование. Обучающий курс для всей команды"

Глава 3. Роли и компетенции

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

Один из способов справиться с такими переменами и не погрузиться в хаос – контролировать, чему и как вы обучаетесь.

Самоуправляемые команды

Бернис Рухланд, директор по QA, делится своими мыслями о самоуправляемых командах.

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

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

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

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

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

КОМПЕТЕНЦИИ ПРОТИВ РОЛЕЙ

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

Важны ли должности?

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

На моей визитке, кроме имени и контактов, есть еще три вещи.

Самое очевидное – «тестировщик ПО». Это то, чем я занимаюсь. Я тестирую софт и помогаю коллегам улучшить показатели в этой области.

«Антрополог ПО» было добавлено после долгих раздумий на Conference of the Association for Software Testing (CAST) в 2011 году. Майкл Болтон выступал с докладом о развитии программного обеспечения, в частности тестирования как социальной науки. Это зацепило меня и заставило о многом задуматься. Главным образом мои мысли касались отношений между людьми и приложениями. При оценке принципов работы ПО эти взаимоотношения весьма важны и составляют существенную часть сути тестирования.

Это подводит нас к третьему и самому важному пункту – «постановщик вопросов». Это похоже на QA, и часто термин путают с тестированием. Сколько помню себя в сфере разработки ПО, так и было. Это раздражало меня некоторое время. В 2009 году я разговаривал с Майклом Болтоном, Фионой Чарльз, Линн МакКи, Нэнси Кельн и другими. В этой беседе постоянно использовалась формулировка: «Тестировщики задают вопросы, чтобы узнать, как реагирует или должно реагировать ПО». Постановка вопросов ведет к получению информации о софте, о том, как мы взаимодействуем с ним, и, определенно, к еще большему количеству вопросов. По крайней мере, до тех пор, пока на большинство вопросов не будут найдены ответы, удовлетворяющие заинтересованные стороны.

А это вновь возвращает нас к «тестировщику ПО».

Нам нравится термин «постановщик вопросов», который можно использовать и в планировании совещаний. Более подробно на этом остановимся в четвертой части.

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

В последние несколько лет термины типа DevOps стали широко использоваться, подчеркивая взаимосвязь между разработчиками ПО и сетевым оборудованием и операциями. Хотя термины и могут казаться новыми, отличительной особенностью Agile-команд всегда было то, что здесь выполняют работу, которую раньше обычно делал человек, занимающий другую должность. (Мы поговорим о взаимовыгодном сотрудничестве между специалистами DevOps и тестировщиками в главе 23.)

Забудьте о разработчиках в тестировании. Нам нужны тестировщики в разработке

Триша Кху, инженер по тестированию из Австралии, делится опытом и говорит о том, что происходит, когда вся команда думает о тестировании.

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

Я едва не упала в обморок, потому что не слышала о подобном за всю свою карьеру. Важным было то, что не команда спрашивала меня, тестировщика, как я собираюсь тестировать это. Вопрос задавался всей команде: «Как мы вместе собираемся это тестировать? Как нам сделать так, чтобы быть уверенными, что это будет работать так, как задумано?».

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

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

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

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

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

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

Это заметно сокращает время обратной связи, повышает уверенность и ускоряет процессы QA. Кому такое может не понравиться?

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

История Лайзы

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

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

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

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

Т-ОБРАЗНАЯ СХЕМА НАБОРА НАВЫКОВ

В «Гибком тестировании» мы говорили о десяти принципах для тестировщиков, касающихся отношения и технических навыков. Давайте быстро повторим их.

• Предоставлять постоянную обратную связь.

• Создавать выгодные предложения для клиента.

• Создать условия для личного общения.

• Не бояться.

• Не усложнять.

• Постоянно совершенствоваться.

• Принимать перемены.

• Быть самоорганизованным.

• Сосредоточиваться на людях.

• Наслаждаться.

Однако до сих пор мы получаем вопросы типа: «Должны ли тестировщики в Agile-командах быть еще и программистами?».

Мы отвечаем, что тестировщикам необходима Т-образная схема навыков, которую впервые придумал Дэвид Гест (Guest, 1991). Чтобы эффективно работать в любой команде, вы должны обладать навыками настолько же широкими, насколько и глубокими. Обширные знания не только в своей сфере позволяют продуктивно общаться со специалистами разных областей. Глубокое понимание и разнообразные методы в одной сфере способствуют внесению значительного вклада в работу команды (Lambert, 2012).

Верхняя часть буквы «Т» у тестировщиков обычно включает технические навыки, например базовое понимание структуры системы, знание основного программного продукта и принципов дизайна, умение создавать простые запросы базы данных, а также обращаться с такими инструментами, как платформа управления проектом и исходным кодом (Integrated Development Environments, IDEs) и непрерывно интегрируемые (Continuous Integration, CI) панели инструментов.

Другие члены команды должны, помимо навыков в верхней части «Т», владеть основными понятиями тестировщика. Поверхностное владение материалом может быть приемлемо в определенных ситуациях.

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

Команда квадратного типа

Адам Найт, директор по QA и поддержке в Великобритании, рассказывает о своем опыте использования Т-образной схемы для создания команды квадратного типа.

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

• Знание Linux/UNIX для создания и поддержания тестовой среды и ее мониторинга, чтобы оценивать влияние софта.

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

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

• Знание программирования для развития и поддержания средств, необходимых для функционального тестирования и масштабирования клиентского программного интерфейса, если он отличается от основного языка программирования C и C++.

• Знание SQL и баз данных для понимания области применения и тестирования расширенного движка SQL на примере реальных запросов.

• Навыки исследовательского тестирования для определения и работы с рядом состояний и комбинаций операций, которые могут оказать влияние на уровне хранения данных.

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

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

Когда я впервые прочел о Т-образной схеме, я понял: это то, что делали мы. Идея широкого спектра основных навыков, совмещенная с глубокими знаниями узкоспециальных умений, – это описание именно того сотрудника, которого мы искали. Так, мне очень повезло работать с одним тестировщиком, который довольно хорошо знал базы данных и SQL благодаря прошлому месту работы администратором баз данных (DBA).

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

Три тестировщика с различными навыками

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

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

Команда квадратного типа

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

СПЕЦИАЛИСТЫ ШИРОКОГО ПРОФИЛЯ

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

Как стать специалистом широкого профиля

Мэтт Баркомб, специалист по организационному дизайну, делится своими идеями о том, откуда берутся специалисты широкого профиля.

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

Кого не назвать специалистом широкого профиля

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

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

Так кто же такой специалист широкого профиля?

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

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

Как стать специалистом широкого профиля

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

Один из подходов заключается в том, чтобы придать приобретаемым навыкам Т-образную форму. Здесь существует множество моделей освоения тех или иных умений, но с целью стать именно специалистом широкого профиля я использую три категории навыков: (1) основные, (2) продвинутые, (3) мета, – связанные со знаниями, которым «необходимо обучиться». Количество таких знаний варьируется в зависимости от категории: для основных – небольшое, для продвинутых – наоборот, очень большое, наконец, для метанавыков оно меньше, но все же не настолько мало, как для основных.

Модель показана на рисунке ниже.

Эта модель наглядно демонстрирует, как стать специалистом. Однако в ней содержатся и намеки на то, как стать универсалом. Как видите, каждый новичок должен сначала выучить основы своей специальности (тестирования или программирования). Это в равной мере справедливо и для специалистов широкого профиля, и для тех, кто только стремится к этому.

Модель становления специалиста широкого профиля

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

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

Ответ на этот вопрос лежит в понимании самой природы развитых метаспособностей. Метазнания – это та самая интуиция, тактика, которые развиваются у человека, когда он годами практикует продвинутые навыки по своей специальности, применяя их в самых разных ситуациях. Это практически шестое чувство в конкретной области. Специалист может использовать в описании кода, дизайна или структуры продукта такие выражения, как «Кажется, что-то не так», «Довести до ума» или «Чувствуется, что…» Суть в том, чтобы специалист замечал признаки чего-то, что нужно доработать.

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

Примером такого развития тестировщика в сторону программиста может быть овладение правилами чистого кода (Martin, 2009), принципами неповторения своих ошибок, продолжительность или количество уроков, обоснованные аргументы или множество «если» в его подходе. Универсалу не всегда нужно знать, как исправить те или иные ошибки. Иногда находятся веские причины для того, чтобы нарушить правила. Дополнительные ресурсы помогают обнаруживать признаки, а не исправлять ошибки.

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

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

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

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

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

ПОДБОР НУЖНЫХ ЛЮДЕЙ

В начале карьеры на Лайзу сильное впечатление произвела статья Алистера Кокберна Characterizing People as Non-Linear, First-Order Components in Software Development (Cockburn, 1999). За двадцать лет изучив десятки проектов по разработке софта, Кокберн пришел к выводу, что общим фактором, обеспечивающим успех для всех, было то, что «в нужный момент подключались нужные люди». Именно хорошие специалисты, а не язык программирования, инструменты или методология делают проект успешным.

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

Книга «Чудаки на своем месте» Джоанны Ротман (Geeks That Fit, Rothman, 2012b) поможет найти и нанять на работу тестировщиков, обладающих необходимыми навыками и способных вписаться в вашу корпоративную культуру. Каждый сотрудник привносит в коллектив свои сильные стороны и свой взгляд, и важно учитывать все аспекты при оценке вклада того или иного члена команды. Разнообразие внутри коллектива необходимо для того, чтобы появлялись различные точки зрения. Иногда человек, который не вписывался в коллектив в самом начале, может быть полезным благодаря желанию разрабатывать качественный продукт для клиента.

АДАПТАЦИЯ ТЕСТИРОВЩИКОВ

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

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

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

История Лайзы

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

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

Урок: не пренебрегайте тем, что замечает новый тестировщик!

Проявите творческий подход и в обучении нового специалиста. Сведите его с кем-то, кто объяснит структуру системы. Выделите время для программиста или системного администратора, чтобы ввести новичка в курс непрерывных интеграционных процессов. Организуйте обучение по автоматизированным тестам и сопроводительной документации. Открытые обсуждения полезны в совокупности с изучением документации, поскольку новый сотрудник в это время может задавать вопросы. Новичкам может быть непросто все сразу выучить. Попробуйте разбить обучение на небольшие отрезки. Возможно, после курса следует предоставить руководство по тестированию в печатном виде, чтобы человек мог еще раз прочесть все и изучить вопрос. (Подробнее о документах и исследовательском тестировании мы поговорим в главе 12.)