BugCatcher - "скринкастер" для QA

Константин Осипенко, основатель компании BugCatcher.pro

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

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

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

На тот момент fire.to мог записывать длинные видео как трансляцию. Т.е делаем трансляцию на Youtube или wowza и во время прямого эфира пользователи могли размечать контент. На основе этого мы и создали первый прототип BugCatcher.

С этим проектом мы прошли в акселератор А:Старт новосибирского Академпарка.

Но уже во время сборки первого MVP поняли, что этим пользоваться нереально по нескольким причинам:

Пример разметки видео протокола тестирования:

3апись видео локально.

В итоге мы отказались от онлайн трансляции и пришли к записи видео локально и дальнейшей ее выгрузки в онлайн хранилище. При этом для уменьшения траффика предварительно видео конвертировалось и сжималось. Мы сформировали выборку возможных хранилищ для видео контента:

Youtube

Google Drive

Dropbox

S3

Изучив варианты и сделав первые сборки с данными типами хранилищ, мы перешли на выбор среди объектных хранилищ типа S3.

Яндекс
Не подошел, так как из-за санкций его сервисы недоступны в некоторых странах.
Amazon
В итоге, мы остановились на интеграции с облаками Amazon.

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

На текущем этапе, помимо внедрения данного инструмента в компании QASQUAD, мы проводили CustDev и на других сегментах - продуктовые, игровые и аутсорс команды.

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

Исследования рынка, CustDev.

Для проведения кастдева выбрали аудитории:

Провели примерно 50-70 интервью и презентаций.

Использовали разные каналы для работы с аудиторией.

Linkedin

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

Reddit

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

Facebook

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

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

Если группа на английском (а таких на порядок больше), то отклик определяется по качеству контента. Английский язык группы не означает аудиторию из англоговорящих стран. Хорошее качество показывают группы на локальных языках. Также имеет смысл стучаться в закрытые группы с активными модераторами вместо самых больших групп. Но модераторы могут реагировать бесконечно долго.

Как работают посты в группах? Текст поста оттачивается с каждой итерацией, новым комментом или новым вопросом. И конечно, действует правило: есть коммент — надо отвечать. Есть интерес — надо договариваться о презентации интервью сразу же. Через день-два, тем более неделю, люди забывают обо всем и любой разговор надо начинать уже с самого начала.

Итого, проверяли ряд гипотез. Ниже приведу часть основных:

Первая гипотеза.

Скринкасты (запись видео с экрана) активно используются для репорта багов.

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

Вторая гипотеза.

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

Не подтвердилась)

Главные контраргументы: «если они трудноуловимые, может они не такие уж и важные? А если и действительно фатальные, то не факт, что видео поможет в их поиске :(. А если все-таки надо записать длинное видео, то существует длинный ряд таких инструментов, которые можно найти в случае необходимости.»

Третья гипотеза:

Репортить баги «нравится» не всем и не все репортеры сопровождают информацию о проблеме достаточной информацией.

Тут мы нашли единодушное понимание у аудитории и услышали кучу историй о том,

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

Полный набор функций на сегодняшний день выглядит так:

скриншот/запись видео -> хранение в облаке -> сбор контекста -> сбор логов -> экспорт в багтрекер.

И тогда мы приняли важные решения.

Теперь мы вместе с картинкой собираем следующие данные:

Как это выглядит:

В отдельной вкладке мы собираем

Настроили интеграции с багтрекерами Jira и Redmine.

Вот так выглядит форма с заполнением обязательных полей, перед передачей информации в Jira:

Так выглядит переданный репорт в Jira:

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

BugCatcher, как профессиональный QA — скриншотер направлен на:

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

Если вы дочитали до конца нашу историю и тема репорта багов вам актуальна и понятна, заполните наш опросник за 2 минуты и получите дополнительные 2 недели почти полнофункционального использования багкетчера!

Протестировать BugCatcher в деле можно скачав его тут. Мы будем рады вашим фидбекам и готовы помогать внедрению нашего инструмента в ваши процессы.

Полезные ссылки: