Автор: Хосе Каррера (Jose Carrera)
Оригинал статьи
Перевод: Ольга Алифанова

Что такое тестирование, управляемое через страх?

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

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

• Разделяется ли ответственность за качество между всеми участниками команды?
• Где находятся контрольные точки качества (quality gates)?

Если процесс построен так, что QA-инженеры становятся единственными "хранителями качества", без полноценного участия других специалистов, это приводит к тому, что тестирование превращается в деятельность, движимую страхом — страхом быть обвинёнными в том, что баг не был обнаружен до выхода в продуктив.

FDT может серьёзно навредить проекту разработки и помешать лучшим практикам тестирования. Он не только снижает способность команды стабильно поставлять ценность пользователям, но и негативно сказывается на моральном духе и удовлетворённости команды: из-за таких практик возникает дополнительная работа, которая мало что даёт.

Вот примеры последствий FDT:

• Медленная обратная связь из-за длительных циклов выполнения тестов,
• Чрезмерная концентрация на сквозном (end-to-end) тестировании,
• Концентрация ответственности за качество только на QA.

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

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

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

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

Проблемы начинаются, когда страх становится нашим единственным ориентиром, из-за чего мы начинаем игнорировать такие важные аспекты, как:

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

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

Разберемся в причинах FDT

Выявление первопричин — распространённый подход в разработке ПО, и мы точно так же можем лучше понять FDT, если определим факторы, которые к нему приводят.

Как только мы разберёмся, что именно влияет на возникновение FDT, мы сможем оценить это влияние и определить, как двигаться дальше.

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

Недостаток знаний в предметной области

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

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

Однако недостаток этих знаний может быстро перерасти в проблему, особенно если:

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

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

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

Решение
Эффективная документация и обмен знаниями.

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

Это, в свою очередь, даёт возможность:

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

Плохое знание архитектуры и кодовой базы

Для того, чтобы спроектировать и реализовать эффективную стратегию тестирования — от старта проекта до выпуска функционала конечным пользователям — необходимо обеспечить полноценную валидацию на каждом этапе: от юнит-тестов до сквозных сценариев (end-to-end).

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

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

Проблема
Слабое или отсутствующее взаимодействие между тестировщиками, разработчиками и другими ролями обосабливает знания. Это ведёт к дублированию усилий на разных уровнях тестирования и к снижению доверия внутри команды.

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

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

Плохое понимание взаимодействия между разными частями системы

Сэм Ньюман [1] определяет микросервисы как независимо разворачиваемые сервисы, спроектированные вокруг бизнес-домена. Каждый сервис инкапсулирует функциональность и предоставляет её другим участникам системы через сеть.

Например, один сервис может отвечать за управление складом, другой — за обработку заказов, третий — за доставку. Вместе они формируют полноценную систему электронной коммерции.

С ростом числа приложений, построенных на микросервисной архитектуре [2][3], жизненно важно понимать, какую роль играет каждый сервис, чтобы грамотно планировать работу. Необходимо задать себе следующие вопросы:

• На какие сервисы мы полагаемся?
• Как мы можем проверить корректность нашей интеграции с ними?
• Как узнать, вносим ли мы изменения, нарушающие совместимость?
• Есть ли у нас нужные инструменты для этого?

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

Проблема
Плохое понимание внутренних или внешних интеграций.

Решение
Наличие эффективной документации и коммуникации о том, как компоненты взаимодействуют между собой.

Использование специализированных инструментов — например:

• средств API-тестирования,
• системы управления тестами,
• системы управления контрактами между сервисами,
• системы контроля версий API.

Это позволяет отслеживать зависимости и управлять точками интеграции осознаннее и безопаснее.

Недостаточная изоляция сервисов

Одно из ключевых преимуществ микросервисной архитектуры — возможность проверять каждый сервис независимо от остальных.

Чтобы это было возможно, необходимо:

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

Для этого критически важны:

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

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

Проблема
Отсутствие возможности валидировать сервисы изолированно.

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

Жёсткие сроки

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

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

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

Если тестированию отводится второстепенная роль, риск неэффективного и хаотичного этапа проверки в самом конце возрастает многократно.

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

Решение
Тестирование должно быть встроено во весь жизненный цикл разработки программного обеспечения.

Автоматизация должна присутствовать на разных уровнях, а подход к непрерывному тестированию должен включать:

• исследовательское тестирование,
• приёмочное тестирование,
• старт тестирования, как только функциональность становится доступной.

Давление со стороны руководства

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

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

В таких условиях QA-специалисты часто воспринимаются исключительно как черные вестники, потому что именно они выявляют проблемы, тормозящие релиз.

Другая распространённая проблема — восприятие тестирования как «простой» задачи, которую может выполнить кто угодно. Это приводит к:

• низкой эффективности тестов,
• недостаточному покрытию,
• плохо оформленным баг-репортам, которые мешают движению вперёд, а не помогают найти решение.

Проблема
Отсутствие совместной ответственности команды за качество продукта. В итоге тестирование воспринимается как узкое место.

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

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

Неэффективное управление тестовыми данными

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

Именно наличие релевантных данных позволяет нам:

• воспроизводить реалистичные пользовательские сценарии,
• и повышать уверенность в корректной работе ПО.

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

Проблема
Невозможность определить и подготовить подходящие тестовые данные.

Решение
Определять требования к тестовым данным как можно раньше. Обеспечить наличие эффективных механизмов для предоставления необходимых данных на всех уровнях тестирования.

Ограничения тестовой среды

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

Ограничения всегда будут присутствовать, например:

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

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

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

Решение
Определить требования к каждой тестовой среде, чётко указав её цель, и спланировать, какие наборы тестов должны выполняться в каждой среде.

Дублирование тестов

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

Однако вредное дублирование увеличивает время тестирования без существенной пользы:

• Тестирование поведения сервисов, которыми мы пользуемся (внутренних или внешних), расширяет объём тестирования за пределы того, что мы сделали сами, и повторяет тесты, уже проведённые владельцами сервисов.
• Повторное тестирование логики через UI несмотря на то, что она уже была протестирована на более низком уровне.
• Ручное тестирование сценариев, которые уже покрыты автоматизацией.
• Создание end-to-end тестов, охватывающих несколько команд, когда разные команды тестируют одни и те же сценарии.

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

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

Бесконечное тестирование

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

• Повторное выполнение тестов, которые не были затронуты недавними изменениями.
• Установка нереалистичных критериев для завершения этапа тестирования, например, отсутствие новых проблем, независимо от их серьёзности.
• Требование повторно тестировать исправленные проблемы несколькими сторонами.

Проблема
Отсутствие чётких и хорошо определённых критериев завершения тестирования.

Решение
Определение чётких и реалистичных критериев завершения тестирования, вместе с непрерывным анализом изменений при планировании следующей итерации тестирования.

Чрезмерный фокус на end-to-end тестировании

Согласно глоссарию ISTQB [4], end-to-end тестирование — это «вид тестирования, при котором бизнес-процессы тестируются от начала до конца в условиях, максимально приближенных к производственным». Обычно это тестирование проводится через пользовательский интерфейс в среде, максимально похожей на производственную, что имеет большую ценность и позволяет закрыть пробелы, оставшиеся от предыдущих уровней тестирования.

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

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

Проблема
Неправильное понимание возможностей тестов более низких уровней в выявлении проблем. Предположение, что только end-to-end тесты могут гарантировать, что приложение работает как ожидается.

Решение
Ограничить количество end-to-end тестов до минимума, обеспечив эффективное покрытие другими уровнями тестирования.

Оформление багов вместо общения внутри команды

Баги и улучшения— это формальный способ, при помощи которого тестировщики (QA) сообщают о своих находках команде - обычно через инструмент управления дефектами, например, JIRA. Это полезный механизм, упрощающий общение со всеми заинтересованными, помогающий в приоритизации проблем и определении их важности/серьезности.

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

Поощрение создания дефектов до того, как заданы вопросы и исследовано поведение, приводит к возникновению дефектов с рядом проблем:

• Отсутствие информации
• Неверная серьёзность/приоритет
• Невалидные проблемы

Проблема
Баги рассматриваются как единственный способ коммуникации и обсуждения находок или проблем.

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

Множественные проверки / утверждения артефактов тестирования

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

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

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

Проблема
Длительные процессы утверждения, отсутствие доверия и ответственности.

Решение
Внедрение более лёгких процессов проверки артефактов, которые поощряют ответственность и делегируют обязанности.

Избыточная документация

Документация тестирования ПО может принимать различные формы: планы тестирования, тест-кейсы, отчёты и т. д. Её цель — дать команде информацию о том, как мы подходим к качеству, что охвачено нашими тестами и какие результаты были достигнуты. Через обзор документации мы можем улучшить наш подход и предоставить более эффективную и надёжную информацию заинтересованным сторонам.

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

Например, может быть создан и запущен набор автоматизированных end-to-end тестов:

• Cucumber как фреймворк BDD для обеспечения читаемости сценариев и их связи с юзер-стори.
• Документирование связи между тестами и юзер-стори.
• HTML-отчёты после каждого выполнения тест-пайплайнов.
• Результаты автоматизированных тестов включены в общий цикл выполнения тестов
• Финальный отчёт по качеству добавляется в вики для каждого релиза.

Проблема
Дублирующаяся в нескольких местах документация.

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

Влияние и последствия игнорирования FDT

Замедленная обратная связь

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

Недовольство команды

То, как мы работаем как команда и наша способность влиять на наши процессы – это важный фактор удовлетворённости команды. Тестирование, управляемое страхом, влияет на моральный дух и удовлетворённость команды несколькими способами:

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

QA становится узким местом

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

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

Как минимизировать влияние тестирования, управляемого страхом

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

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

Описание подхода:

1. Определение, какая деятельность/процессы – это результат действий, основанных на страхе, а не на информации.
2. Разбиение проблем на части и определение необходимых изменений, которые нужно внедрить в тестирование или процессы. Идеально, если эти задачи будут как можно меньше, чтобы их было легче выполнить.
3. Приоритизация задач и назначение ответственных за каждый тип задач, что позволяет команде сначала разобраться с наиболее проблемными областями.
4. Внедрение нужных улучшений, как технических, так и процессных, с отделением тех, которые находятся под контролем, от тех, которые требуют дополнительной коммуникации.

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

Заключение

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

Уход от тестирования, управляемого страхом

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

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

Ссылки

1. Building Microservices - Sam Newman
2. New Research Shows 63% of Enterprises Are Adopting Microservices Architectures
3. Microservices Adoption in 2020
4. ISTQB - International Software Testing Qualification Board - Glossary
5. Pitfalls & Challenges Faced During a Microservices Architecture Implementation | Cognizant
6. Understanding End-to-End Microservices Testing | BrowserStack
7. Testing Strategies in a Microservice Architecture
8. Testing Microservices: an Overview of 12 Useful Techniques - Part 1 - InfoQ
9. Fear Driven Development and How To Tackle It | Codurance
10. Fear-driven Development - Paul Stiffler
11. Fear-Driven Development - Glossary
12. Fear Driven Development - FDD - Scott Hanselman's Blog
13. What is the project management triangle and how can it help your team?
14. Beyond the iron triangle