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