Agile-тестирование. Обучающий курс для всей команды
Шрифт:
Во второй части поговорим о ролях и компетенциях, связанных с тестированием и качеством, а также о том, какие навыки необходимы для создания высококачественного софта – от интеллектуальных до технических. В последней главе этой части подчеркивается важность обучения для каждого сотрудника в отдельности и для всего коллектива в целом.
• Глава 3. Роли и компетенции.
• Глава 4. Интеллектуальные навыки тестировщика.
• Глава 5. Техническая подготовка.
• Глава 6. Образовательные ресурсы.
Глава 3. Роли и компетенции
Ряд задач, с которыми сталкиваются любые команды, ежедневно расширяется. Ваш отдел может работать над веб-продуктами, и вдруг руководство решает, что непременно нужно еще и мобильное приложение. Команды внедряют новые технологии, разрабатывают методы, инструменты, фреймворки, а в это же время приоритеты клиентов меняются. Что означает, что и сам процесс тестирования должен измениться.
Один из способов справиться с такими переменами и не погрузиться в хаос – контролировать, чему и как вы обучаетесь.
Бернис Рухланд, директор по QA, делится своими мыслями о самоуправляемых командах.
Мы часто слышим о преимуществах и успехах самоуправляемых команд. Для кого-то такие изменения могут облегчить работу, а кому-то, наоборот, покажутся трудными. Перспектива отдать команде проект и позволить решать, как его вести, может быть пугающей. Мне приходилось встречать самоуправляемые команды, которые не могли и шагу сделать без согласования с руководством. Некоторым необходимо, чтобы им ставили четкие задачи. Другие не любят говорить работникам, что делать. Порой пара человек оказываются завалены работой под завязку.
Это не значит, что такие команды не могут стать самоуправляемыми. Им просто требуется помощь. Мне кажется, в таких случаях полезными будут собрания, где можно обсудить детали проекта, ответить на вопросы и помочь в установлении основных правил с присутствующими менеджерами, тренерами или координаторами. Как координатор, я могу направить сотрудников, позволив им самим решать и определять стиль работы. Если вы руководитель или менеджер, попробуйте делегировать большую часть ответственности команде. Если им трудно справиться с самоуправлением, позаботьтесь, чтобы тренер периодически посещал их встречи, собрания и при необходимости направлял их. Как только станет возможно, позвольте команде вновь самостоятельно проводить собрания.
Также хорошо себя зарекомендовали мероприятия, во время которых каждый сотрудник может обсудить свои навыки и потенциальный вклад в проект. Часто у людей бывают нераскрытые способности или какие-то умения, о которых коллегам неизвестно. Например, тестировщик может разбираться в языке программирования, что пригодится для автоматизации повторяющихся действий. Со временем, помимо технического мастерства, начинайте обсуждать такие навыки, как управление, умение находить компромиссы и отношения внутри и за пределами коллектива, которые тоже могут быть полезны. При необходимости для начала составьте матрицу навыков. Постепенно переключайтесь от освоенных умений к тем, что требуются для построения здоровых отношений внутри коллектива.
Доверие между сотрудниками особенно важно для самоуправляемых команд. Отдельные коллективы разделяют общие интересы и строят личные отношения. Существует множество вариантов для развития сплоченности. Просто найдите те, которые подходят вам.
Обсуждая принятые меры, интересуйтесь, какие нововведения способствовали улучшению, а что показалось сложным. Не забывайте отмечать успехи и помогайте внедрять изменения, когда это необходимо.
Мы видим значительный прогресс в том, что касается важности компетенций внутри команд, а не ролей или должностей. Когда происходят такие изменения, чаще вместо «Это не моя работа» можно услышать «Как я могу помочь?». Сотрудники по-прежнему имеют ключевые навыки в каких-то вопросах, но уже не так сильно привязаны к определенным ролям. Например, фраза «Я тестировщик» означает: «В основном я занимаюсь тестированием, потому что люблю это занятие и разбираюсь в нем. Я могу руководить и направлять остальных, а могу помочь и в других областях».
Однажды на конференции Пит Волен из Мичигана раздавал свои визитки. Джанет с радостью приняла одну из них. Однако ее привлекла указанная на ней должность. Она спросила об этом, и вот что Пит ответил.
На моей визитке, кроме имени и контактов, есть еще три вещи.
Самое очевидное – «тестировщик ПО». Это то, чем я занимаюсь. Я тестирую софт и помогаю коллегам улучшить показатели в этой области.
«Антрополог ПО» было добавлено после долгих раздумий на Conference of the Association for Software Testing (CAST) в 2011 году. Майкл Болтон выступал с докладом о развитии программного обеспечения, в частности тестирования как социальной науки. Это зацепило меня и заставило о многом задуматься. Главным образом мои мысли касались отношений между людьми и приложениями. При оценке принципов работы ПО эти взаимоотношения весьма важны и составляют существенную часть сути тестирования.
Это подводит нас к третьему и самому важному пункту – «постановщик вопросов». Это похоже на QA, и часто термин путают с тестированием. Сколько помню себя в сфере разработки ПО, так и было. Это раздражало меня некоторое время. В 2009 году я разговаривал с Майклом Болтоном, Фионой Чарльз, Линн МакКи, Нэнси Кельн и другими. В этой беседе постоянно использовалась формулировка: «Тестировщики задают вопросы, чтобы узнать, как реагирует или должно реагировать ПО». Постановка вопросов ведет к получению информации о софте, о том, как мы взаимодействуем с ним, и, определенно, к еще большему количеству вопросов. По крайней мере, до тех пор, пока на большинство вопросов не будут найдены ответы, удовлетворяющие заинтересованные стороны.
А это вновь возвращает нас к «тестировщику ПО».
Нам нравится термин «постановщик вопросов», который можно использовать и в планировании совещаний. Более подробно на этом остановимся в четвертой части.
В командах, с которыми работала Лайза, границы между ролями размылись. Некоторые программисты еще и опытные тестировщики. Иногда именно тестировщик находит простое решение для сложной задачи в написании кода. К тому же люди с широким кругом компетенций могут соответствовать более чем одной роли в коллективе. Например, в команде, где сейчас работает Лайза, есть программисты – системные администраторы с обязанностями DevOps-менеджеров.
В последние несколько лет термины типа DevOps стали широко использоваться, подчеркивая взаимосвязь между разработчиками ПО и сетевым оборудованием и операциями. Хотя термины и могут казаться новыми, отличительной особенностью Agile-команд
Триша Кху, инженер по тестированию из Австралии, делится опытом и говорит о том, что происходит, когда вся команда думает о тестировании.
В прошлом году я устроилась в небольшую команду, где разработчики действительно ценили тестирование и рассматривали его как неотъемлемую часть всего цикла создания продукта. Я никогда не забуду одну из первых планерок, где мы обсуждали новый элемент. Один из разработчиков насупился и сказал: «Да уж, но как мы собираемся его тестировать?». В результате весь проект изменили.
Я едва не упала в обморок, потому что не слышала о подобном за всю свою карьеру. Важным было то, что не команда спрашивала меня, тестировщика, как я собираюсь тестировать это. Вопрос задавался всей команде: «Как мы вместе собираемся это тестировать? Как нам сделать так, чтобы быть уверенными, что это будет работать так, как задумано?».
По ходу создания элементов разработчики всегда писали тесты: от модульных до браузерных. Кто-то из разработчиков всегда вручную проводил тестирование перед тем, как передать продукт мне. Именно благодаря этому я редко обнаруживала баги, вызванные невнимательностью. Большинство были связаны с пользовательскими или системными сценариями, которые не проявлялись раньше.
Вы можете подумать, что мне как тестировщику в таком случае не приходилось слишком много работать. Мой самый ценный вклад в процесс заключался в том, что я анализировала продукт с точки зрения тестировщика и пользователя. Я поняла, что тестирование было не так важно в конце процесса, но невероятно важно в его начале.
Чем больше внимания я уделяла тестированию на начальной стадии, тем меньше усилий требовалось в ручном тестировании в конце, потому что в результате возникало гораздо меньше багов. Я бы хотела выделить последнюю мысль в умную цитату, потому что, на мой взгляд, это важно.
Но основной частью этого было то, что я знала: разработчики тестировали продукт качественно, вдумчиво писали тесты, тестировали их вручную по мере разработки. Я точно знала, что, если на встрече планирования мы говорили о сценарии, он будет качественно разработан и к концу процесса протестирован с помощью автоматизированных регрессионных тестов.
В этом году мне часто приходилось обсуждать роль тестировщика. Давайте оставим это сейчас и подумаем о роли разработчика софта. Этот человек должен быть уверен, что его продукт будет функционировать так, как задумано. Знания о том, как делать это на элементарном уровне, – важное качество для хорошего разработчика. Именно поэтому требуется больше тестирований на стадии разработки. И они должны проводиться именно теми, кто создает продукт.
Иметь в команде тестировщика ценно, но не стоит возлагать всю ответственность за тестирование на одного человека. У вас может быть отдельный специалист по базам данных, но это не значит, что он единственный, кто работает над этим. То же самое справедливо и для тестирований. Специалист может помочь в действительно сложных вопросах, зная, что все остальные члены команды в состоянии справиться с более простыми задачами.
Это заметно сокращает время обратной связи, повышает уверенность и ускоряет процессы QA. Кому такое может не понравиться?
Во многих Agile-командах появились специалисты с различными компетенциями. Например, сейчас часто можно встретить как бизнес-аналитиков, так и тестировщиков, плотно занимающихся различными вопросами бизнес-анализа. Границы между ролями и обязанностями размываются. В то же время такое пересечение обязанностей внутри команды не означает, что можно совсем обойтись без определенных специалистов. По нашему опыту, коллективы заходят в тупик из-за отсутствия у них специалистов с конкретными навыками. Порой решение простое: нанять человека, обладающего этими навыками, или обучить уже имеющихся сотрудников.
Команда, с которой я недавно работала, находилась в растерянности из-за того, что мы взялись за несколько проектов, которые не были достаточно оценены бизнес-экспертами головного офиса. В результате мы постоянно обращались к заказчику за разъяснениями требований или показывали готовые разработки только для того, чтобы в ответ услышать, что мы все сделали неверно.
Мы, тестировщики, предложили нанять бизнес-аналитика, который бы помог клиенту прояснить, что именно ему нужно. Наш руководитель продукта не был знаком с новой головной компанией, и хотя он встретился с заинтересованными лицами, тем не менее не знал, какие вопросы задавать, чтобы добраться до сути того, что нужно. Опытный бизнес-аналитик знал бы, как вести переговоры с заказчиком, и задавал бы правильные вопросы.
К сожалению, менеджер не захотел нанимать бизнес-аналитика, так что мы создали свое сообщество по методам бизнес-анализа. Тестировщики, руководители продуктов, Scrum-мастера, менеджер-разработчик и заинтересованные программисты собрались вместе, чтобы прокачать свои аналитические навыки. Мы читали книги и статьи, посещали конференции, мастер-классы и участвовали в семинарах, чтобы разобраться в бизнес-аналитике. Мы постоянно встречались, делились информацией и записывали все в собственную вики-энциклопедию.
Возможно, лучше было бы нанять эксперта, но наши старания принесли плоды. Руководитель продукта обучился методам и техникам общения, которые мог использовать на встрече с представителями головной компании. В итоге он лучше стал понимать нюансы. Нам и теперь порой не хватает информации, какие именно задачи хочет решить клиент, но мы больше не тратим так много времени на то, чтобы ходить туда-сюда и спрашивать про каждую мелочь.
В «Гибком тестировании» мы говорили о десяти принципах для тестировщиков, касающихся отношения и технических навыков. Давайте быстро повторим их.
• Предоставлять постоянную обратную связь.
• Создавать выгодные предложения для клиента.
• Создать условия для личного общения.
• Не бояться.
• Не усложнять.
• Постоянно совершенствоваться.
• Принимать перемены.
• Быть самоорганизованным.