Buglance - Обновления за последние два года: где мы были, и где мы сейчас

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

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

Но, обо всем по-порядку.

В прошлый раз мы закончили на наших планах выйти на глобальных рынок.

Сбылось ли? Рады сообщить - еще как! Мы нашли и продолжаем находить ошибки в программах команд из разных точек мира. В основном эти команды из Америки и Европы, а также, менее ожидаемых мест, как Мальта.

Второй целью было увеличить количество тестировщиков на нашей платформе. За эти 19 месяцев, их количество выросло в четыре раза - с 11 до 40 тысяч.

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

Мы начали работать с двумя из самых известных игроков в стартап экосистеме - Techstars и 500 Startups. В итоге, мы получили $120 тысяч от Techstars, и $100 тысяч от 500 Startups.

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

Например, один из таких толчков произошел в динамике наших команд. Из-за характера работы Buglance, было довольно естественно, что часть команды была разбросана по всему миру. И программа Techstars предоставила возможность, наконец, собрать все команду физически в одном месте. Это очень позитивно сказалось на команде и ее духе.

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

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

Почему мы решили поменять стратегию? И какова эта модель?

С самого начала, нас привлекала модель ‘pay as you go’. В прошлом посту мы описали почему и как мы, протестировав наш MVP, где все ошибки обходились за $1, поменяли нашу ценовую политику. Стоимость стала гибкой, в зависимости от сложности багов (безопасность, интерфейс, и т.д.), варьируя от $1 до $10.

Эта модель, в теории и на практике, привлекала маленькие-средние команды. И на самом деле, количество клиентов росло. Однако, в скором времени мы заметили, что команды подписавшись, использовали наш продукт единожды, и возвращались только через несколько месяцев. И возник вопрос, почему?

Мы выяснили, что большинство маленьких команд не нуждается, и на практике не тестирует продукт настолько часто. А что насчет больших команд, или команд внутри довольно крупной компании?

Эти команды, в основном, используют широко распространенную методологию разработки Agile. Команды, работающие по agile методике обычно размещают обновления и версии своих приложений каждый, так называемый спринт, который длится от 2 до 4 недель. Тестирование для таких случаев довольно важно. А если учесть размер таких команд и компаний - критично.

Довольно неплохо подходит к описанию идеального клиента Buglance, верно?

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

Еще одна хорошая новость - мы начали работу над новым продуктом!

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

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

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

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

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

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

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

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

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

Еще одной приятной новостью для нас и нашего сообщества является то, что мы запустили Buglance блог. Мы ранее начали работать над созданием контента, который мы надеемся не только поможет нашим тестерам, но и более широкому кругу людей. Наша главная задача с созданием этого блога - поделиться нашим опытом, и создать практический, как говориться ‘no bullshit’ материал, который кратко и, главное, технически верно описывает разные темы связанные с тестированием.

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

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

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

И так, один из самых важных (и сложных) уроков этого периода: меньше - лучше.

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

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

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

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

Вдобавок, мы добавляем другие типы тестов, которые ранее не присутствовали на платформе, например тестирование безопасности (security testing).