Что за тестировщик без команды по контролю качества?
Организации, которые хотят, чтобы их переход к Agile прошёл успешно, должны убедиться, что никто не окажется в изоляции. Как и вся остальная Agile-команда, тестировщики для достижения хороших результатов нуждаются в правильном тренинге и поддержке. Им нужно научиться сотрудничать с программистами, экспертами по базам данным, ключевыми фигурами со стороны бизнеса и прочими людьми, с которыми, возможно, они никогда раньше не контактировали. Возможно, им понадобятся и новые технические навыки. Хорошо функционирующая Agile-команда обязательно должна охватить и тестировщиков, предоставив им такую инфраструктуру, которая поможет им преуспеть. Как единая командаВ успешных Agile-командах за качество отвечает каждый человек. Это означает, что хоть тестировщики и привносят в команду свой особый опыт и уникальное видение, не только они одни отвечают за конечное качество продукта. Другие члены команды тоже играют свою роль в тестировании, кроме того, тестировщики могут попросить остальных о помощи. Хорошая новость для тестировщика, включенного теперь в состав команды разработчиков, в том, что его сфера влияния стала шире - он вступает в игру уже с самого начала проекта и сотрудничает со всей командой на протяжении итерации. Это сотрудничество начинается, когда тестировщик работает с заказчиком или владельцем продукта, определяя приёмочные (пользовательские) тесты, и продолжается, когда он оценивает результаты тестирования историй вместе с программистами и просит их внести свой вклад в тестирование во имя того, чтобы направить разработку в правильное русло. Данный подход «единой команды» - очень мощная вещь. Например, когда часть приложения трудно протестировать, мы просим команду рассмотреть данную проблему. Поскольку написание кода и тестирование больше не разъединены, разработчики могут найти способ улучшить возможности для тестирования. Если же это требует слишком много времени или изменение кода поломает существующий функционал, может помочь специалист по сборке, ускорив процесс непрерывной интеграции. Когда все придерживаются подхода «единой команды», никто не остаётся в изоляции. Каждый член проектной команды становится ценен наравне со всеми остальными, все помогают друг другу на протяжении всего проекта. Нам доводилось встречать команды, где аналитики по качеству и руководители разработки работали вместе ещё до перехода к Agile с тем, чтобы определить, в чём их роли и как они могут лучше всего помочь своим командам. В результате тестировщики получают огромную поддержку в том, чтобы научиться быть частью новой Agile-команды. Пример «единой команды»Когда Лайза впервые примкнула к своей первой Agile-команде, ей пришлось отказаться от убеждения, что она судья качеству продукции. Взамен ей понадобилось научиться тому, как помочь заказчикам определить критерии качества и готовности ещё до того, как началось написание кода. Она участвовала в дискуссиях с программистами и администраторами баз данных, где заказчики давали примеры желаемого поведения. Поначалу автоматических регрессионных тестов ещё не было, поэтому всем в команде приходилось выполнять тесты вручную каждую итерацию. Каждый человек в команде стремился закончить историю до конца итерации. Если тестирование начинало отставать, Лайза просила помощи, и вся команда выполняла задачи по тестированию. Системный администратор помог наладить процесс непрерывной интеграции и сборки, что помогло получать быструю обратную связь по регрессионным тестам. Несколько месяцев спустя у команды уже были адекватные автоматизированные регрессионные тесты, что освободило команде больше времени на сотрудничество с экспертами со стороны бизнеса и лучшее понимание предметной области. Теперь команда могла сфокусироваться на разработке нового функционала, а не исправлении старого, а у тестировщиков появилось время на выполнение важных исследовательских тестов. Ресурсы для внедрения подхода «единой команды»«Это всё здорово, - скажете вы, - но мы-то всё ещё работаем в разрозненных группах. Как нам перейти к подходу «единой команды»?» Мы рекомендуем новым Agile-командам привлечь к проекту опытного Agile-коуча или нанять разработчиков и тестировщиков, уже имевших дело с Agile, чтобы они помогли преодолеть культурные и логистические барьеры. Может помочь скрам-концепция самоорганизующихся команд; команда может принять для себя, что нужно разработать наилучшее ПО, какое только может быть, а потом поэкспериментировать с разными практиками, чтобы добиться этой цели. Однако руководство должно дать команде достаточно времени, чтобы научиться, и устроить тренинги по тем навыкам, которых команде не хватает. К примеру, команде может понадобиться формальный тренинг по разработке через тестирование и через приёмочные тесты. Собирайте команду на ретроспективное совещание по итогам каждой итерации, причём убедитесь, что каждый член новой интегрированной команды принимает участие и чувствует себя вправе заострять внимание на проблемах. Если ретроспективы - новая для вас вещь, рассмотрите возможность привлечь опытного тренера, который поможет вам начать. Такие книги, как «Ретроспективы в Agile: как сделать хорошую команду отличной (Agile Retrospectives: Making Good Teams Great)» Эстер Дерби (Esther Derby) и Дианы Ларсон (Diana Larson) и «Изменения без страха: шаблоны, как представить новые идеи (Fearless Change: Patterns for Introducing New Ideas)» Мэри Линн Маннс (Mary Lynn Manns) и Линды Райзинг (Linda Rising) дадут вам пищу для размышлений, как запустить ретроспективы и представлять изменения. Сообщество тестировщиковЕщё один источник поддержки тестировщика - это сообщество тестировщиков в его компании. Вместо того, чтобы исключать роль менеджера по качеству и распускать команду аналитиков по качеству, мы предлагаем создать сообщества практики. Менеджер по качеству или по тестированию, прежде возглавлявший команду тестировщиков, становится менеджером практики, и его роль будет заключаться в том, что проверять, что у тестировщиков есть достаточная поддержка, необходимые тренинги, и что они могут собираться вместе, чтобы делиться опытом и инновациями в тестировании. Такой «руководитель практики» может помочь тестировщикам найти новые инструменты, чтобы скоординировать тесты и работу на уровне интеграции и создать таким образом жизнеспособные тестовые лаборатории. Кроме того, он играет важную роль в поддержке обучения тестировщиков путём тренингов, в поощрении внутрипроектного взаимодействия и, возможно, даже в подогревании настроя в тестировщиках. Пример построения сообществаУ Дженет был действительно успешный опыт в построении сообществ для команд тестирования с фокусом на обучении и обмене опытом. В одной большой команде (40 тестировщиков, 4 менеджера по качеству и директор по качеству), тестировщики отчитывались менеджерам по качеству относительно производительности, тренингов и поддержки. Повседневный операционный менеджмент осуществлялся внутри каждой из команд - тестировщиков, программистов и т.д. Отчёты о производительности всегда выполнялись менеджерами по качеству при участии проектных команд. Тестировщики регулярно устраивали «уроки за обедом», тимбилдинги и таким образом действительно создали ощущение сообщества. Между этим «сообществом» и проектными командами не было никаких трений - они работали в тесном контакте. Если один тестировщик не ладил с какой-то конкретной командой, менеджеры по качеству работали с командами, чтобы решить этот вопрос. Ресурсы для создания практического сообществаКогда Лайза хотела построить такое сообщество в организации с 25 скрам-командами, она поискала похожие успешные сообщества в качестве примера. Одним из хороших примеров являлось сообщество «Weekend Testers» (www.weekendtesting.com), группа тестировщиков, которая по выходным собирается на двухчасовые сессии тестирования и обсуждения с помощью группового чата и онлайн-инструментария. Другим вдохновляющим примером стал «Software Testing Club» (www.softwaretestingclub.com), онлайн-сообщество тестировщиков с форумом, журналом и другими ресурсами. Онлайн-группы, такие, как agile-testing@yahoogroups.com, тоже являются прекрасным местом, где можно задавать вопросы или делиться идеями с другими участниками, тоже имеющими интерес к Agile-тестированию. Лайза воспользовалась новой корпоративной вики, чтобы создать пространство для сообщества тестировщиков с форумом, ссылками на персональные блоги тестировщиков и расписанием событий. Тестировщики и программисты добровольно вызвались как минимум раз в месяц проводить часовые презентации и лекции по тестированию и автоматизации тестирования. У этих лекций была хорошая посещаемость, и на удивление, в них приняло участие и множество программистов. Обмен знаниямиКогда у тестировщиков есть ощущение сообщества, у них возникает и желание делиться опытом с тестировщиками из других проектных команд. Так возникают общие знания, передаваемые между командами. Когда одна команда находит инструмент, который, по её мнению, может помочь другой команде, она делится этой находкой, чтобы сэкономить и время, и энергию. Такой обмен знаниями идёт на пользу всей компании. Тестировщики получают необходимую поддержку и помощь в разрешении сложнейших проблем тестирования. Как только тестировщику перестаёт казаться, что он находится в изоляции или является жертвой процесса, но ощущает себя человеком, у которого есть поддержка целой команды, он может начать и собственное развитие. Компания, в качестве части процесса обучения, поощрит его читать статьи, профессиональные блоги, писать статьи самому, выступать с командными инициативами в отношении других команд, участвовать в жизни более крупных сообществ, таких, как местные группы по качеству или Agile, принимать участие в конференциях или даже выступать на них. Участие в жизни сообщества тестировщиков внутри компании, а так же в жизни сообществ тестировщиков и разработчиков на местном, национальном и международном уровнях, помогает нам и нашим девелоперским командам постоянно находить способы работать лучше. Расширение горизонтовКак видите, тестировщикам важно не быть в одиночестве, даже если они не принадлежат отдельной команде по качеству. У них есть наготове огромная группа поддержки, готовая прийти на помощь, если только они найдут её и обратятся. Что ещё более важно, тестировщики несут свой опыт команде разработчиков, где каждый человек, не только тестировщики, радеет за качество. Требуется смелость, чтобы выбраться из зоны комфорта и впервые объединиться с разработчиками. Возможно, вам понадобится освоить новые навыки, чтобы помочь заказчикам сформулировать критерии качества для каждой новой части функционала. Откройте свой разум новым возможностям. Объединитесь с разработчиками, чтобы разрешить проблемы тестирования новыми способами. Поддерживайте прочную связь с сообществом тестировщиков для обмена опытом и удачными примерами из практики. Извлекайте пользу из всех ресурсов в интернете, печатных изданиях, местных и онлайн пользовательских групп и не переставайте учиться. Возможно, ваша работа понравится вам даже больше, чем когда вы были частью команды по качеству.
Источник: http://www.agileconnection.com/print/art[...]le/what%E2%80%99s-tester-without-qa-team Об авторе: специализация Дженет Грегори - помогать командам выстраивать системы качества. И как тестировщик, и как коуч, она помогала компаниям изучить практики разработки Agile и способствовала успешному переходу нескольких традиционных команд в мир Agile. Дженет часто выступает на конференциях, посвящённых Agile и тестированию ПО, в том числе на конференциях STAR. Перевод: Алксандра Родсет |
Еще интересные статьи на эту тему:
|