Agile-тестирование. Обучающий курс для всей команды
Шрифт:
• Сосредоточиваться на людях.
• Наслаждаться.
Однако до сих пор мы получаем вопросы типа: «Должны ли тестировщики в Agile-командах быть еще и программистами?».
Мы отвечаем, что тестировщикам необходима Т-образная схема навыков, которую впервые придумал Дэвид Гест (Guest, 1991). Чтобы эффективно работать в любой команде, вы должны обладать навыками настолько же широкими, насколько и глубокими. Обширные знания не только в своей сфере позволяют продуктивно общаться со специалистами разных областей. Глубокое понимание и разнообразные методы в одной сфере способствуют внесению значительного вклада в работу команды (Lambert, 2012).
Верхняя часть буквы «Т» у тестировщиков обычно включает технические навыки, например базовое понимание структуры системы, знание основного программного продукта и принципов дизайна, умение создавать простые запросы базы данных, а также обращаться с такими инструментами, как платформа управления проектом и исходным кодом (Integrated Development Environments, IDEs) и непрерывно интегрируемые (Continuous Integration, CI) панели инструментов.
Другие члены команды должны, помимо навыков в верхней части «Т», владеть основными понятиями тестировщика. Поверхностное владение материалом может быть приемлемо в определенных ситуациях.
Умение приносить прибыль требует, чтобы некоторые члены команды, возможно даже бизнес-аналитики, обладали более глубокими знаниями. Соберите весь коллектив, чтобы обсудить Т-образную
Адам Найт, директор по 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). За двадцать лет изучив десятки проектов по разработке софта, Кокберн пришел к выводу, что общим фактором, обеспечивающим успех для всех, было то, что «в нужный момент подключались нужные люди». Именно хорошие специалисты, а не язык программирования, инструменты или методология делают проект успешным.
Наш опыт подсказывает, что крайне важно набрать в команду людей с правильным отношением. Не торопитесь, ищите тестировщиков, которые впишутся в ваш проект. Если люди, которых вы наняли, любопытны, хотят учиться и не боятся выйти из зоны комфорта, мы можете обучить их всем необходимым навыкам. Безусловно, работа в одном офисе имеет преимущества перед удаленкой, однако все же советуем расширить географию поиска. Удаленные тестировщики могут быть эффективны в командах, где правильно выстроен процесс коммуникации, где умеют извлекать пользу из современных технологий.