Тестирование в команде

 

 

->

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

Знакомство с Shift-Left

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

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

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

Shift-Left в основном позволяет задуматься о тестировании на более раннем этапе процесса.

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

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

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

1. Подход Behavior Driven Development (BDD) позволил разработчикам, пользователям, бизнес-аналитикам и тестировщикам участвовать в том, что можно было бы назвать бизнес-историями. Разработка через тестирование используется многими разработчиками уже 15 и более лет. Сегодня BDD получает более широкое распространение, потому что он способствует лучшему сотрудничеству в agile-командах, а также представляет инструменты, которые могут использовать разработчики. Это более простой подход Test-First.
2. Непрерывная поставка (CD) существует уже 5-10 лет, и ее корни уходят в высокоавтоматизированные подходы к автоматизации сборки и выпуска, впервые примененные крупными онлайн-компаниями. В настоящее время он принят большинством организаций, присутствующих в Интернете.
3. CD систематизировал и ускорил процесс выпуска за счет автоматизации. Но это также выявило задержки в производстве, развертывании и изменении инфраструктуры, которые ранее маскировались медленными процессами сборки, тестирования и выпуска. DevOps — это изменение культурного мышления, благодаря которому разработчики гораздо более тесно сотрудничают с операционным персоналом. Прямо сейчас новые инструменты появляются почти ежедневно, и поставщики продвигают DevOps как «следующую большую вещь». Это очень раздутая и динамичная ситуация.
4. SMAC, или Social, Mobile, Analytics и Cloud, представляет собой сдвиг в том, как организации управляют бизнесом и системными изменениями в мобильном пространстве. Эксперименты в бизнесе, реализуемые как изменения производственных систем, отслеживаются на детальном уровне. Собранные «большие» данные обрабатываются, и на основе полученной аналитики принимаются бизнес-решения.

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

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

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

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

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

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

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

Shift-left делает разработчиков более ответственными .

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

Новая роль

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

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

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

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

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

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

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

Вмешательства Agile-тестирования

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Физическое (и временное) разделение	Команды могут быть распределены по офису, разным зданиям, городам, странам и часовым поясам. Коммуникация нарушена, каналы стеснены, и информации поступает меньше.
Различные мотивы	Команда поставщика работает на организацию, которой платят за тестирование. В конечном счете, их мотивацией является получение прибыли. В контрактах с фиксированной ценой давление заключается в том, чтобы работать быстро. Контракты на сроки и материалы, есть искушение раскрутить работу.
Культурные различия	Национальные, культурные различия могут быть значительными. Иногда это может занять время, чтобы признать и принять во внимание.
Компания/Корпоративная культура	Корпоративные культуры также различаются — компании, как правило, лучше всего сотрудничают с компаниями сопоставимого размера, гибкости и формальности. Компании более или менее осторожны, когда речь идет о конфиденциальности, безопасности, конфиденциальности и так далее. У компаний разные стили руководства, и к разнице между государственными и коммерческими организациями тоже нужно привыкнуть.
Поставщики работают по контрактам	Ваш поставщик не проявляет лояльности к заинтересованным сторонам вашего проекта или их бизнес-целям. Они работают по правилам, указанным в их контракте. Если можете, убедитесь, что в ваших контрактах указаны все обязанности обеих сторон, и что контракт вознаграждает за хорошее поведение и наказывает за плохое.

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

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

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

• Если вы не управляете своим поставщиком, он будет управлять вами (если вы не являетесь полноправным партнером и предоставляете поставщику возможность определять условия, поставщик будет держать все карты).
• Цель состоит в том, чтобы определить хорошие рабочие отношения. Они должны быть установлены на всех уровнях – заинтересованной стороны, менеджера, а также практикующего специалиста.
• Контракты должны быть сформулированы так, чтобы определять все обязанности обеих сторон, с указанием соответствующих мер, порогов, поэтапных платежей и критериев приемлемости, определенных для поощрения хорошего поведения (с обеих сторон соглашения).
• Соглашения должны поощрять открытость и поддержку общей цели успеха проекта.

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

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

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

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