Страница 9 из 11
В «Гибком тестировании» мы говорили о десяти принципах для тестировщиков, касающихся отношения и технических навыков. Давайте быстро повторим их.
• Предоставлять постоянную обратную связь.
• Создавать выгодные предложения для клиента.
• Создать условия для личного общения.
• Не бояться.
• Не усложнять.
• Постоянно совершенствоваться.
• Принимать перемены.
• Быть самоорганизованным.
• Сосредоточиваться на людях.
• Наслаждаться.
Однако до сих пор мы получаем вопросы типа: «Должны ли тестировщики в 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) мета, – связанные со знаниями, которым «необходимо обучиться». Количество таких знаний варьируется в зависимости от категории: для основных – небольшое, для продвинутых – наоборот, очень большое, наконец, для метанавыков оно меньше, но все же не настолько мало, как для основных.
Модель показана на рисунке ниже.
Эта модель наглядно демонстрирует, как стать специалистом. Однако в ней содержатся и намеки на то, как стать универсалом. Как видите, каждый новичок должен сначала выучить основы своей специальности (тестирования или программирования). Это в равной мере справедливо и для специалистов широкого профиля, и для тех, кто только стремится к этому.