Добро пожаловать в серию «Лидерство в тестировании» от гуру и консультанта по тестированию программного обеспечения Пола Джеррарда. Эта серия предназначена для того, чтобы помочь тестировщикам с многолетним опытом работы, особенно в Agile командах, преуспеть в своей роли руководителя тестирования и менеджера.

В предыдущей статье мы рассказали о том, как управлять выполнением проекта по тестированию. Сегодня расскажем о меняющейся роли тестировщика в проектной команде и о том, как улучшить взаимодействие с коллегами как в офисе, так и удаленно.

В последние годы ответственность за тестирование стала более распределенной. Вместо того, чтобы выделять команды для тестирования, команды теперь поощряют пользователей, аналитиков, разработчиков и тестировщиков к перераспределению ответственности за тестирование для улучшения совместной работы. Поэтому некоторые виды деятельности по тестированию и обязанности переносятся влево.

В этой статье мы поговорим о:

• Shift Left (сдвиге процессов тестирования влево)

• Тестировании как о виде деятельности, а не как о роли

• Новой роли

• Гибких методах тестирования

• Взаимоотношениях с разработчиками 

• Проблемах распределенных и аутсорсинговых команд 

Shift Left (сдвиг процессов тестирования влево)

Shift-Left, или сдвиг влево, может относиться к нескольким различным сценариям. Это может означать, что разработчики берут на себя больше ответственности за собственное тестирование. Это также может означать, что тестировщики вовлекаются в проект на более ранней стадии, анализируя сложные требования и предоставляя разработчикам примеры в рамках процесса разработки, основанного на поведении (BDD).

Иногда это может означать полное отсутствие тестировщиков, когда бизнес‑аналитики и разработчики берут на себя полную ответственность за тестирование.

Сдвиг влево не нов — сторонники тестирования уже много лет твердят как мантру: «тестируй как можно раньше, тестируй чаще». Еще в 1993 году было высказано предположение, что все артефакты поэтапного процесса — как документальные, так и программные — могут (и должны часто) тестироваться.

Сдвиг влево в основном предназначен для того, чтобы заставить задуматься о тестировании на более ранней стадии процесса.

Хотя в то время доминирующим подходом к жизненному циклу был «водопадный подход», количество или продолжительность этапов не имели значения. Основополагающий принцип заключался в том, что источники знаний, которые определяют направление проектирования и разработки программного обеспечения, должны подвергаться проверке.

В поэтапном проекте это может включать в себя формальные проверки. В гибком проекте тестировщик (или разработчик, или бизнес‑аналитик, или пользователь) может предложить сценарии, в которых автору требования или истории (Story) предлагается продумать конкретные примеры и обсудить их до написания какого‑либо кода.

Вот основные изменения, связанные с феноменом «сдвига влево»:

1. Подход к разработке, основанный на поведении (BDD), позволил разработчикам, пользователям/ бизнес‑аналитик и тестировщикам взаимодействовать с тем, что можно назвать бизнес‑историями. Разработка, основанная на тестировании (TDD), используется многими разработчиками в течение 15 или более лет. Сегодня BDD внедряется все шире, поскольку способствует улучшению совместной работы в гибких командах, а также внедрению инструментов BDD, которые могут быть использованы разработчиками. Это более простой подход, основанный на тестировании.

2. Система непрерывной доставки (CD) существует уже 5–10 лет, и ее корни уходят в высокоавтоматизированные подходы к автоматизации сборки и выпуска, впервые примененные крупными онлайн‑компаниями. В настоящее время она используется большинством организаций, работающих в Интернете.

3. CD систематизировал и ускорил процесс выпуска за счет автоматизации. Но это также выявило задержки в производстве, развертывании и изменении инфраструктуры, которые ранее скрывались за медленными процессами сборки, тестирования и релиза. DevOps — это изменение культурного уклада, при котором разработчики гораздо теснее сотрудничают с операционным персоналом. Сейчас новые инструменты появляются почти ежедневно, и вендоры рекламируют DevOps как «следующую крупную технологию». Это очень раскрученная и динамичная ситуация.

4. SMAC, или социальные сети, мобильные устройства, аналитика и облака, представляют собой изменение в способах управления бизнесом и системными изменениями в мобильном пространстве. Собранные «большие» данные обрабатываются, и на основе полученных аналитических данных принимаются бизнес‑решения.

Частые эксперименты с производственными системами позволяют внедрять бизнес‑инновации «со скоростью маркетинга». Эксперименты лежат в основе того, что стало самым важным достижением 2010–х годов, — цифровой трансформации.

Тестирование как деятельность, а не роль

Сдвиг влево меняет роль тестировщиков. Перераспределение тестирования, вызванное сдвигом влево, дает понять, что тестировщики не несут единоличной ответственности за тестирование, т. е. тестировщики больше не являются собственниками тестирования.

Если вдуматься, они никогда по‑настоящему не проводили собственное тестирование, но в проектах существовало негласное понимание того, что независимо от того, что остальная часть команды, в частности разработчики, делала при тестировании, тестировщики обеспечивали безопасность. Если разработчики были стеснены во времени и сокращали время тестирования, чтобы выполнить поставленную задачу, тестировщики обеспечивали им защиту.

Тестирование теперь — это деятельность, а не роль.

Разработчики внедряют более совершенные методы тестирования и повышают прозрачность своей работы. Хорошее компонентное или модульное тестирование преследует конкретные цели, отличные от системного тестирования (в качестве примера). Поэтому объем тестирования на системном уровне может быть сокращен.

Правильное распределение целей тестирования и проведение тестирования для достижения этих целей является основной целью стратегии тестирования. К сожалению, до недавнего времени разработчики не несли эффективной ответственности, поэтому они полагались на позднее тестирование системы, чтобы компенсировать это.

Сдвиг влево повышает ответственность разработчиков.

В целом, ответственность за тестирование перераспределяется, поэтому роль тестировщика меняется. Тестировщики могут проводить меньше тактического тестирования, но их стратегический вклад возрастает. У тестировщиков может быть своя стратегия тестирования, они могут оспаривать требования, консультироваться с заинтересованными сторонами и налаживать более тесные отношения с разработчиками для улучшения тестирования разработчиками и автоматизации тестирования.

Новая роль

Сдвиг влево подразумевает, что всякий раз, когда есть возможность предоставить обратную связь, которая поможет команде понять, оспорить и улучшить цели, требования, дизайн или реализацию, такая обратная связь должна предоставляться.

Пользователи, разработчики и вся команда разработчиков программного обеспечения должны быть готовы к обмену обратной связью таким образом. Иногда возникает сопротивление, но общая цель заключается в том, чтобы сделать проект лучше и с большей степенью информированности — вот и все.

Проще всего подвести итог такому поведению: «принимайте участие как можно раньше». Участвуйте в обсуждении и совместной работе над идеями, требованиями и на каждом этапе, когда результат этого этапа влияет на ценность конечного результата проекта.

Проще говоря, тестировщик проверяет источники знаний, будь то заинтересованные стороны, пользователи, разработчики, бизнес‑истории, документы или прецеденты.

Наиболее распространенным подходом является проверка с помощью примеров. На всех этапах эти примеры можно рассматривать как тесты. Они могут быть быстро отброшены после использования или систематизированы для автоматизации тестирования или проверки вручную. Эти примеры можно использовать просто в тактических целях, чтобы указать на недостатки в мышлении людей, или предоставить разработчикам, скажем, в качестве идей для тестов. Их также можно использовать в качестве учебных пособий, чтобы показать пользователям или разработчикам, как можно создавать более качественные тесты.

Рассматривайте свой программный проект как процесс приобретения знаний. Эти знания накапливаются на протяжении всего проекта и часто совершенствуются с течением времени. Цель shift‑left — обеспечить достоверность этих знаний путем проверки и тестирования в непосредственной близости от их источника и, по возможности, обеспечить им доверие до того, как они будут заморожены в коде.

Shift‑Left развивает философию «сначала тестирование». Agile всегда поощрял сотрудничество и быструю обратную связь — shift‑left можно рассматривать как согласованный подход к быстрой обратной связи. Если ваша команда применяет подход «сначала тестирование», то наличие правильных инструментов может иметь решающее значение.

Гибкие методы тестирования

Подход «сдвиг влево» является основополагающим для стратегии тестирования гибких проектов. В контексте agile стратегию тестирования можно рассматривать как серию тестовых вмешательств. Во всех проектах бывают критические моменты, когда появляется возможность собрать информацию и предоставить обратную связь. Тестировщик должен сосредоточиться на этих критических моментах и быть готовым внести свой вклад в их решение.

В ваших собственных проектах вам необходимо определить критические моменты, когда возможно вмешательство, и определить варианты, которые вы можете сделать при тестировании в команде. Например, должен ли тестировщик писать модульные тесты для разработчиков, предоставлять примеры, которые помогут им начать работу, или обучать их, чтобы улучшить их навыки тестирования? Это можете решить только вы и ваша новая команда по тестированию программного обеспечения.

Мы будем использовать типичный Scrum‑процесс, чтобы продемонстрировать, как можно использовать тестовые вмешательства в рамках Scrum‑подхода. Вмешательства выполняются либо на уровне проекта (или релиза), либо на уровне спринта. На диаграмме ниже показано представление на уровне проекта и пять ключевых вмешательств.

Тестирование истории и определение истории — это этапы, при которых тестировщик проверяет историю пользователя и предлагаемые критерии приемлемости для истории соответственно. Интеграционные тесты проверяют правильность связи новых фич с другими фичами и системой в целом. Системные и пользовательские (приемочные) тесты проводятся по мере необходимости.

Проект обычно состоит из нескольких этапов, и четыре этапа спринта показаны на диаграмме ниже. Ежедневный стендап — это возможность сообщить о прогрессе, высказать опасения, выявить риски или обсудить поднятые вопросы и ответы, полученные в ходе спринта.

Доработка истории и участие в тестировании для разработчиков — это повседневные действия, которые проводятся в рамках обсуждений с пользователями, аналитиками и разработчиками. Тестировщик объединяет тесты для разработчиков и новые системные тесты в постоянно растущую коллекцию тестов, подлежащих автоматизации.

В таблице ниже вы можете увидеть сводную информацию о вмешательствах тестировщиков. Ваш процесс может отличаться или основываться на Scrum с вариациями, но в таблице указаны типичные типы вмешательств в типичный Scrum-процесс. У вас может быть больше или меньше активных вмешательств на разных этапах вашего собственного уникального процесса.

Я предлагаю вам определить критические моменты, предложить свой вклад и провести переговоры со своей командой. Вы предлагаете больше лидерства в тестировании и рекомендаций, а не просто добровольно берете на себя ответственность за работу по тестированию. При таком подходе будет намного проще продемонстрировать свою ценность команде.

Взаимоотношения с разработчиками

В некоторых организациях отношения между разработчиками могут быть недоверчивыми, заслуживающими порицания и антагонистическими. В худшем случае отношения становятся токсичными: разработчики вообще мало тестируют, а тестировщики считаются слугами разработчиков. Тестировщики перенимают то, что можно было бы назвать созависимым поведением, и ведут себя как жертвы. Это именно то, чего стремится избежать подход «сдвиг влево».

Существует множество метафор, которые использовались для описания хороших отношений разработчика и тестировщика. Мы будем использовать стиль работы пилот-штурман, чтобы проиллюстрировать, как могут работать сопоставимые отношения разработчика и тестировщика. Но сначала давайте рассмотрим дисфункциональную ситуацию.

Штурман не садится в самолет, а машет пилоту при взлете. Штурман путешествует на автобусе, отдельно, но медленно. В конце концов, штурман прибывает в пункт назначения, но через некоторое время выясняется, что самолет полетел не в том направлении и врезался в гору. 

Наверняка штурман должен был находиться в самолете? Представьте, как пилоты и штурманы работают вместе в реальности. 

• Пилот не может управлять самолетом без штурмана. Штурман не может управлять самолетом.

• Пилот и штурман согласовывают план полета до начала путешествия.

• Пилот взлетает и управляет самолетом.

• Штурман отслеживает курс и сравнивает его с планом полета и/или конечным пунктом назначения с учетом неблагоприятных событий, в частности погоды.

• Штурман ищет отклонения, прокладывает новый курс и уведомляет пилота, который вносит коррективы в траекторию полета.

• И так далее. 

Отношения пилота/штурмана сравнимы с отношениями программиста/тестировщика. Разделение разработчиков и тестировщиков на отдельные команды, работающие последовательно, также не имеет смысла. Тем не менее, это то, что мы традиционно делали в течение последних тридцати лет или около того, особенно в более крупных и долгосрочных проектах.

Сдвиг влево перераспределяет представления о тестировании и эффективно продвигает его вперед. Тестировщики действуют как полноправные партнеры разработчиков точно так же, как штурманы действуют по отношению к пилотам: 

• Тестировщик и разработчик совместно сопоставляют информацию о требованиях.

• Как правило, тестировщик оспаривает требования на примерах (потенциальных или реальных идей для тестирования).

• Разработчик думает о реализации, используя примеры для определения направления своего проектирования.

• Тестировщик, разработчик, заинтересованные стороны, пользователи и аналитики согласны с общим пониманием требований, которым доверяют.

• Тестировщик находится в постоянном контакте с разработчиком, обсуждая изменения требований, риски сбоев и то, как тестирование может показать работоспособность фич или выявить сбои.

• Тестировщик рассматривает, как фича, над которой ведется работа, будет интегрироваться как на техническом уровне, так и на уровне взаимодействия с пользователем, и как можно протестировать интеграцию.

• Тестировщик смотрит за пределы текущей фичи, над которой работает разработчик, чтобы определить будущие проблемы, риски, изменения и неопределенности.

• И так далее.

Только что описанные отношения разработчика и тестировщика в идеальном мире не возникают автоматически. Это должно быть разработано командой. Вы можете рассматривать каждое из вышеперечисленных действий как вмешательство, но вмешательство не всегда удобно для всех сторон. Дайте этому подходу наилучшие шансы на успех, обсудив каждый тип вмешательства со своими партнерами в самом начале, когда вы точно знаете, что вам придется тесно сотрудничать.

Вмешательства, как и хорошие истории пользователей, являются триггерами для разговоров. 

Каждый тип вмешательства требует согласия обеих сторон на то, что это допустимое действие. Чтобы чувствовать себя комфортно, каждый должен доверять другому в том, что есть веские причины задавать вопросы, поднимать проблемы и оспаривать требования или понимать друг друга на встречах, сессиях планирования или ретроспективах.  

Проблемы распределенных и аутсорсинговых команд

В обсуждениях выше по умолчанию предполагалось, что все работают в одной команде и находятся в одном месте. Когда рабочая нагрузка команды по тестированию программного обеспечения передается на аутсорсинг и/или переводится в офшор, в игру вступает несколько негативных факторов. В таблице приведены три типичных фактора, которые следует учитывать. 

Некоторые компании расширяют существующие группы тестирования программного обеспечения, чтобы расширить возможности для более крупных проектов, или нанимают специализированные компании по тестированию, а не полагаются при тестировании на подрядчиков или внутренних пользователей. В других ситуациях вся разработка и/или тестирование могут быть переданы поставщикам. Во всех случаях компания-клиент должна управлять своими поставщиками. Это не означает, что будет достаточно заключения ограничительного контракта с суровыми пунктами о штрафных санкциях.

Когда что-то идет не так, вам нужны быстрые реакции и сотрудничество со стороны вашего поставщика; вы не хотите, чтобы они прикрывались юридическими положениями контрактов.

Секреты успеха заключаются в следующем:

• Если вы не управляете своим поставщиком, они будут управлять вами (если вы не являетесь полноправными партнерами и предоставляете поставщику определять условия, все карты остаются у поставщика).

• Цель — установить хорошие рабочие отношения. Их необходимо установить на всех уровнях — заинтересованных сторон, менеджера, а также специалиста‑практика.

• В контрактах должны быть сформулированы все обязанности обеих сторон, с соответствующими мерами, пороговыми значениями, поэтапными платежами и критериями приемлемости, определенными для поощрения хорошего поведения (с обеих сторон соглашения).

• Соглашения должны поощрять открытость и заинтересованность в достижении общей цели успеха проекта.

Пища для размышлений

И, наконец, несколько вопросов, которые заставят вас задуматься.

Какие отношения у вас как тестировщика с вашими разработчиками? Или, если вы разработчик, читающий это, каковы ваши отношения с тестировщиками? Возможно, спросите своих партнеров по разработке или тестированию, как бы они описали ваши отношения. Сравните заметки!

Чтобы команды по тестированию программного обеспечения были продуктивными, они должны общаться и сотрудничать.