Автор: Джеймс Эспи (James Espie)
Оригинал статьи
Перевод: Ольга Алифанова

 Исследование

Если подумать о великих путешественниках, кто приходит вам в голову? Возможно, Тинтин, знаменитый журналист из комикса, исследующий мир в поисках разгадок тайн? Или Доктор (Доктор Кто), исследователь времени и пространства, спасающий вселенную от одной напасти за другой? А как насчет Даши-путешественницы? Она учит детей читать по слогам при помощи своих приключений и преодоления препятствий.

У всех них есть нечто общее – они никогда не исследуют в одиночку! У Доктора почти всегда есть компаньон или даже трое. У Тинтина всегда рядом его верный пес Снежок, и другие персонажи, помогающие ему в пути. Даже Даша-Путешественница всегда вместе с любимой обезьянкой Башмачком! Исследование редко бывает одиночным плаванием. Поэтому, когда приходит время для исследовательского тестирования, не будьте единоличником! Bug Bash – один из способов привлечь остальных к исследованию.

Что такое Bug Bash?

Bug Bash – это когда люди из компании собираются вместе для теста фичи или приложения. Хороший Bug Bash включает разнообразных людей из разных команд и профессий. Конкретная форма Bug Bash зависит от контекста, размера и структуры организации. Обычно это 10-15 человек, которые в течение часа находятся в помещении вместе. Каждый из них имеет свое собственное устройство и проводит время, исследуя фичу.

Bug Bash состоит из набора людей, включая

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

Почему Bug Bash так полезен?

Итак, почему же Bug Bash – такая полезная техника исследовательского тестирования?

Снежная слепота

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

Товарищеский опыт

У каждого в команде и компании разный опыт, влияющий на их восприятие фичи. Объединение этих людей может выявить нове баги! Допустим, мы проводим Bug Bash для тестирования новой функции корзины, созданной командой "корзина". Один из участников принадлежит к команде, не работавшей над функцией – он из команды "платежи". Команда платежей работает над совершенно другой возможностью – над новым порталом платежей. Человек из команды платежей имеет опыт работы с этими порталами. Его опыт может естественно привести его к соответствующим тестам. Как новая корзина ведет себя, взаимодействуя с новым порталом? Есть существенный шанс, что там могут скрываться баги. К тому же, скорее всего, никто в команде корзины и не подумал пока это протестировать!

Новые точки зрения

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

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

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

Как проводить Bug Bash

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

Будьте готовы!

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

В большинстве случаев лучше дать возможность участникам исследовать самостоятельно. Однако в некоторых ситуациях полезно дать указания - к примеру, "желательно проверить ряд различных браузеров". Полезно задуматься об этом заранее, а затем назначить браузеры каждому участнику по мере их прибытия. Выдайте одному человеку Firefox, одному – Internet Explorer, и так далее.

Приоритезация – после Bug Bash, не во время

Когда десяток человек одновременно находит баги, поступает очень много информации! Непросто разбираться с ней по мере ее получения. Хорошее решение – просто фиксировать всю информацию, чтобы обработать ее позднее. Рабочий метод – создать общее пространство, куда участники могут скидывать свои находки. Это может быть канал в Slack, страница в Confluence, документ Word. Участники обнаруживают то, что, с их точки зрения, может быть багом, и фиксируют информацию об этом в этом пространстве, переходя к дальнейшим исследованиям. Возможно, стоит создать шаблон для логирования находок. Некоторые участники могли никогда раньше не тестировать и не иметь представления о том, какая информация будет полезна. Подсказки вроде "ожидаемого поведения" и "скриншотов или логов" могут помочь.

После завершения Bug Bash организатор разберется с этой информацией – отсортирует ее, уберет дубликаты и начнет логировать и приоритезировать найденное.

Веселитесь

Если участники Bug Bash отлично провели время, то с шансами придут и в следующий раз! Поэтому важно дать им положительный опыт. Закуски очень в этом помогут! Хороший перекус – отличный способ сделать Bug Bash запоминающимся, и люди придут за едой снова. В некоторых компаниях хорошей идеей может быть элемент состязательности. Призы за "первый найденный баг" или "самый значимый баг" могут вдохновить людей участвовать. Однако тут есть и обратная сторона. К примеру, если приз вручается за "наибольшее количество найденных багов", будет очень соблазнительным наводнить Bug Bash минорными багами в надежде получить приз. Соревнования – это хорошо, но этот инструмент надо использовать с умом!

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

Другие преимущества

Есть и другие отличные причины для проведения Bug Bash.

Нагрузочное тестирование

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

Обмен знаниями

Такие сборища – отличный способ познакомиться с коллегами. Участник может протестировать что-то такое, чего не заметили другие (или не подумали об этом). Это даст возможность чему-то научиться и поделиться опытом.

Тимбилдинг

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

Социализация: ценность тестирования

Многие участники Bug Bash не занимают должность тестировщика. Это отличный способ познакомить команду с некоторыми трудностями тестирования! Узнав об этом, команда может больше задумываться о тестировании, выполняя свою обычную работу. Если это научит людей больше заботиться о тестировании, это отличный результат!

Заключение

В заключение скажу, что Bug Bash – отличный способ привлечь помощников к исследовательскому тестированию. Такие мероприятия объединяют людей из разных команд и дисциплин. Это снизит "снежную слепоту" и поможет извлечь выгоду из опыта и угла зрения многих людей. В свою очередь, это поможет выловить больше багов, а, следовательно, сделать продукт лучше, а пользователей и заказчиков – счастливее! Конечно, если баги будут исправлены)

Обсудить в форуме