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

Что такое bug bash?

Вам когда-нибудь хотелось превратить тестирование в вечеринку? Bug bash как раз позволяет это сделать! Ну, не всё там сводится к веселью и играм: обычно самый крепкий напиток — это чёрный кофе, и вряд ли вам захочется нанимать диджея – но при этом можно неплохо провести время и заодно узнать важные вещи о продукте и качестве.

Bug bash укрепляет сотрудничество, даёт возможность выслушать разные точки зрения и помогает формировать и укреплять культуру качества. Обычно bug bash выглядит примерно так:

• Вы приглашаете кросс-функциональную команду: тестировщиков, разработчиков, продакт-оунеров, дизайнеров, стейкхолдеров. Иногда это просто продуктовая команда, а иногда — люди, которые обычно не ходят на ваши встречи – например, юристы или маркетологи. Важно пригласить и тех, кто ещё не пользовался продуктом (или не пробовал новые фичи).
• Вы задаёте общие правила тестирования продукта. Как и на обычной вечеринке, хороший хозяин должен обозначить ожидания и рамки.
• Веселитесь! Геймифицируйте тестирование (несколько идей ниже).
• В течение нескольких часов или даже нескольких сессий по паре часов команда сосредоточенно тестирует продукт, следуя заданным правилам.
• Обязательно заложите время на перерывы.
• Закуски и напитки тоже всегда приветствуются.

Подготовка к bug bash

Сделайте шаблон

Хорошая идея — создать переиспользуемый шаблон для планирования bug bash. Проведёте один — и, скорее всего, он не станет последним. Шаблон всегда можно доработать, и со временем у вас появится отличный список идей и практик для подготовки. Кроме того, шаблон упростит задачу, если кто-то ещё в компании захочет провести bug bash в будущем.

Наш шаблон включает перечисленные ниже разделы:

• Объяснение, что такое bug bash и зачем он нужен: формулировка цели
• Что входит и что не входит в область тестирования
• Тест-чартеры, которые могут использовать работающие в паре тестировщики
• Тестовые данные и окружения
• Инструкции по оформлению багов
• Пустые шаблоны стикеров, которые каждая пара тестировщиков заполняет сама:
  • имена тестировщиков,
  • их тест-чартер,
  • инструкции по ведению заметок для фиксации проблем, вопросов, идей и положительных находок (см. What Is Exploratory Testing? PQIP: Four Simple Words To Level Up Your Testing Efforts)

Заранее разберитесь с технической частью

Структурированный подход решает всё. Один bug bash я готовила вместе с разработчиком, и мы заранее подготовили всё необходимое: тестовые данные, ориентированные на риск тест-чартеры и ссылки на инструменты вроде CloudWatch, Lambda-функции, API и DynamoDB.

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

Создайте хорошие тест-чартеры

Тест-чартеры критически важны для успешного bug bash. Они помогают участникам сосредоточиться на вопросах, «что» и «зачем» исследовать, и дают достаточно структуры, чтобы определить цель, при этом оставляя пространство для творчества и открытий. Этот баланс был особенно важен в нашем случае: нам нужно было, чтобы участники понимали, что и почему исследовать, но при этом не были зажаты жёсткими инструкциями.

Ниже приведён пример тест-чартера для Restful-приложения бронирования:

Исследовать эндпойнт /booking для создания новых бронирований

С различными комбинациями тела запроса (валидные, неполные, с некорректными типами данных)

Чтобы выявить:

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

Приглашение участников

Когда всё готово, отправьте приглашения всем участникам и дайте ровно столько информации о плане и тест-чартерах, сколько им необходимо. В детали можно углубиться уже в начале самого bug bash.

Этот день настал: что делать и чего ожидать

Начало

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

Когда я провожу bug bash, я начинаю сессию с описания контекста и даю всем участникам выбор: взять готовый тест-чартер, создать свой собственный или просто исследовать продукт. Это даёт каждому возможность изучить ту фичу или часть системы, которая ему интересна.

Процесс: настолки и танцы!

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

Чтобы сделать bash более увлекательным и весёлым, попробуйте вот что:

Таблицы лидеров: «Больше всего найденных багов» или «Лучшая пара охотников за багами».

Призы: вознаграждения вроде подарочных карт или ваучеров. Например: подарочная карта на £50 за «Самый креативный баг», трофей за «Лучшую пару охотников за багами».

После

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

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

В заключение: наш опыт и что дальше

Организация bug bash оказалась сложнее, чем казалось на первый взгляд. Некоторые члены команды сомневались в его ценности и задавались вопросом, стоит ли это потраченного времени, а другим было трудно представить, как такой формат может работать для бэкенд-продукта. Без UI для тестирования и с API, которые использовались фронтендом другой команды, было сложно понять, как вовлечь участников и получить полезные результаты.

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

Несмотря на все сложности, участники поняли ценность этой сессии, и теперь наша команда проводит bug bash регулярно.

Дополнительная информация:

• Two Heads Are Better Than One: The Benefits of Pair Testing Across Disciplines, Anneliese Herbosa
• What Is Exploratory Testing? PQIP: Four Simple Words To Level Up Your Testing Efforts - Simon Tomes
• Testing Treasure Maps: The Art of Crafting Charters, Jenna Charlton
• The Awesome Power Of The Debrief: Why Debriefing Is The Key To Successful Exploratory Testing, Callum Akehurst-Ryan