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

Проблема

Находить баги — занятие, мягко говоря, не самое увлекательное. Но ещё более скучно — докапываться до сути и пытаться воспроизвести найденную кем-то проблему. Мы создали bugbox.io, чтобы решить эту проблему.

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

Выглядит он примерно так:

— 🕵‍♀ Логотип съехал, поправь, плиз
— 👨‍🔧 Где?
— 🕵‍♀ На главной
— 👨‍🔧 У меня норм
— 🕵‍♀ скриншот.jpg
— 👨‍🔧 Странно, у меня не так, как на скрине. Какой браузер?
— 🕵‍♀ Safari
— 👨‍🔧 Теперь вижу. А как надо?
— 🕵‍♀ Чтобы во всех браузерах отступ от левого края был 20px
— 👨‍🔧 Хорошо, заводи багу

Потом такие сообщения теряются за сотней других и завтра про проблему уже никто не вспомнит. А если и вспомнит, придётся потратить время на поиски той самой переписки.

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

Решение

Нам кажется, что такое взаимодействие, ставшее нормой во многих компаниях, совсем нездоровый процесс.

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

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

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

Аналоги

Они есть, например bugplug или bugherd.
Зачастую такие сервисы предоставляют даже больше возможностей за $5+. Нам же хотелось создать простое и бесплатное решение для себя и всех, кому это может быть интересно.

Планы на будущее

Если наш мини-продукт будет пользоваться спросом, добавим:

  • автоматическое создание скриншота
  • выделение области на скриншоте
  • управление перечнем собираемых параметров
  • интеграция с trello
  • внешний интерфейс управления багами (заменит гугл-таблицы)

Устанавливайте виджет, делитесь мнениями и отзывами, особенно негативными. Нам это важно.

И да прибудут ваши проекты без багов.

0
37 комментариев
Написать комментарий...
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Александр Савченко
Автор

В коде ничего, что может как-то навредить вашему сайту нет. К тому же, сейчас проект полностью открытый. Можете убедиться сами https://github.com/vmikh/bugbox

По поводу гугл-таблиц, да, понимаем, что это не самое элегантное решение.
Есть планы по интеграции с trello + самостоятельным кабинетом.

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Всвиторе

Для redmine будет плагин?

Ответить
Развернуть ветку
Александр Савченко
Автор

В скором времени точно нет.

Ответить
Развернуть ветку
Mercator

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

Ответить
Развернуть ветку
Александр Савченко
Автор

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

Ответить
Развернуть ветку
Philip Levin

Если баги находить скучно - зачем вообще в кьюэй подался? Чтобы скучать и выгорать на работе? 

Ответить
Развернуть ветку
Александр Савченко
Автор

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

Ответить
Развернуть ветку
Alexander Belousov

Отличная идея! Прикольно, если бы еще сразу скриншот автоматически делался бы и отправлялся

Ответить
Развернуть ветку
Александр Савченко
Автор

Да, будет прям кайф, вот прям сейчас работаем над этим.
К сожалению, это самая сложная часть )

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Azat Minvaliev

Любопытно, а гарантируется что проект будет всегда бесплатен?

Ответить
Развернуть ветку
Александр Савченко
Автор

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

Ответить
Развернуть ветку
Валентин Потапов

Делал мвп в эту тему. Больше про боевые сайты. Но в одиночку трудно, бросил. Идея была в стимулировании нашедших баг. По 2 кликам экран направлялся куда надо, те сайты которые стимулировали багоискателей были на виду. 

Ответить
Развернуть ветку
Александр Савченко
Автор

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

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

Ответить
Развернуть ветку
Валентин Потапов

Тут бесполезно что то предугадать. Только пробовать

Ответить
Развернуть ветку
Alexander Mikhaylov

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

Ответить
Развернуть ветку
Александр Савченко
Автор

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

Ответить
Развернуть ветку
Alex Chernyshev

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

Это в нынешнее время настолько редкий и экзотический товар что ориентироваться на него никак нельзя.

На моей практике типичное поведение пользователей это громкий крик 'Ничего не работает',  вне зависимости от ранга или знаний.
'Сделайте чтоб работало' это сейчас общий тренд, даже коды ошибок никого не интересуют. Да и  вы сами наверное видели 'Aw snap!' в браузере не раз )

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

Я сам активно применяю Senty (https://sentry.io/welcome/) , с агентами  в Angular и Java.

Ответить
Развернуть ветку
Александр Савченко
Автор

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

К sentry присмотримся, за линк отдельное спасибо.

Ответить
Развернуть ветку
Alex Chernyshev

Sentry лишь маленький пример, мне он интересен из-за self-hosted серверной части.
Но лидер в этом направлении это New Relic https://newrelic.com/ .

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

Ответить
Развернуть ветку
Vladislav Mikhailov

Лучшее МВП, что я делал!)

Ответить
Развернуть ветку
Александр Савченко
Автор

Лайк тебе!

Ответить
Развернуть ветку
Антон Кутурженко

Кайф

Ответить
Развернуть ветку
Леха Канунников

А почему решили через встраиваемый виджет, а не через стороннее десктоп приложение? 

Ответить
Развернуть ветку
Александр Савченко
Автор

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

Браузерное расширение — ещё куда ни шло, но оно ограничено 1 браузером, к сожалению.

Ответить
Развернуть ветку
Леха Канунников

через WPF, к примеру, можно получать информацию по userAgent

Ответить
Развернуть ветку
Владислав Егоров

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

Ответить
Развернуть ветку
Александр Савченко
Автор

Скорее да, чтобы начать хоть как-то систематизировать тестирование и контроль отладки.

Ответить
Развернуть ветку
Всвиторе

Мне кажется нужно чтобы ваше приложение ещё могло записывать путь к баге. Допустим человек нажал на меню и тут верстка поехала. Это важно.

Ответить
Развернуть ветку
Александр Савченко
Автор

URL пишем. Полный путь воспроизведения можно заполнить в таблице в столбце "Actual Result"

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Dan Makarov

Привет коллегам. Мы в Bird Eats Bug делаем примерно то же, только через расширение для браузера. И бесплатный план у нас тоже есть :)

Ответить
Развернуть ветку
Александр Савченко
Автор

Привет! Видел вас на продактханте, когда смотрел что есть на рынке.
Респект, крутой продукт!

Ответить
Развернуть ветку
Dan Makarov

Спасибо! Стараемся 😊

Ответить
Развернуть ветку
Maxim Zhilyaev

спасибо больше, это пушка

Ответить
Развернуть ветку
Александр Савченко
Автор

Спасибо, очень рады, что зашло )

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
34 комментария
Раскрывать всегда