Багтрекер вконтакте что это
Баг-трекер
Трансляция найденных багов в Ваши новости.
Сообщество отключено. Исправленные: vk.com/bugsfx
Баг-трекер запись закреплена
Раздел стал слишком популярным, что привело к снижению качества.
А публикации упираются в лимиты.
Баг-трекер запись закреплена
Продукт: m.vk.com
Показать полностью.
Приоритет: Средний
Тип проблемы: Неработающая функциональность
Теги: Сообщения
Автор: Андрей Купчинский
Фактический результат:
Когда я записываю голосовое, потом прослушиваю, оно обрезано
Баг-трекер запись закреплена
Багнутая иконка в тегах отчета
Продукт: Баг-трекер
Показать полностью.
Приоритет: Низкий
Тип проблемы: Потеря данных
Теги: Другое
Автор: Алексей Котовский
Фактический результат:
Можно наблюдать странный тег без текста
Баг-трекер запись закреплена
Возможность отвечать голосовыми комментариями
Продукт: VK.com
Приоритет: Низкий
Тип проблемы: Пожелание
Теги: Голосовые сообщения
Автор: Ника Мясо
Баг-трекер запись закреплена
Ошибка при нажатии кнопки «воспроизвелось»
Продукт: VK.com
Показать полностью.
Приоритет: Средний
Тип проблемы: Производительность
Теги: Другое
Автор: Лёша Жерлыгин
Фактический результат:
Пишет ошибка (подробнее на скриншоте)
Баг-трекер запись закреплена
при листании страницы Firefox появляется/исчезает фотография пользователя возле написать комментарий
Продукт: VK API
Показать полностью.
Приоритет: Низкий
Тип проблемы: Косметическое несоответствие
Теги: Wall
Автор: Андрей Огурцов
Фактический результат:
появляется картинка
Баг-трекер запись закреплена
Невозможно переслать сообщение с ключом группы
Продукт: VK API
Показать полностью.
Приоритет: Средний
Тип проблемы: Неработающая функциональность
Теги: Messages
Автор: Егор Плотников
4 лучших багтрекера или как QA эффективно отслеживает ошибки
Чем больше задач, проектов, клиентов, тем серьезнее встает этот вопрос: как систематизировать информацию о всех тасках и обнаруженных багах для учета рабочего времени, так называемых человеко-часов и возможности видеть картину в целом для расставления приоритетов.
В настоящее время без багтрекера невозможно представить работу как начинающего, так и опытного QA инженера. Для построения правильного процесса тестирования багтрекер просто необходим. Но как выбрать именно тот, единственный и неповторимый, который будет с тобой каждый день и с которым можно строить планы на будущее? Мы все еще о багтрекере. Так вот, чтобы помочь себе и сократить ваше время на поиски идеального багтрекера в столь изобилующем багтрекерами современном мире, мы подготовили небольшой обзор, основанный на нашем опыте и популярности систем. Мы выделим их ключевые особенности, а также в конце поделимся таблицей сравнения, которая помогла нам систематизировать багтрекеры и выбрать лучший для наших потребностей.
Redmine
Не можем умолчать тот факт, что мы сами пользуемся Redmine. Мало того что он бесплатный, но и нареканий не вызывал, и недостатков особых за 3 года использования нами обнаружено еще не было.
Bontq
YouTrack
Желаем вам выбрать вашего лучшего друга-багтрекера.
Анастасия Филатова, QA Engineer ROI4CIO
Выбираем подходящий баг-трекинг
Я общался с десятками QA-инженеров из разных компаний и каждый из них рассказывал о том, что у них используют разные системы и инструменты для баг-трекинга. Мы тоже пробовали несколько из них и я решил поделиться решением, к которому мы пришли.
Интро
Буду банален. Ошибки появляются и обнаруживаются на различных этапах процесса разработки. Поэтому можно разделить баги на категории, в зависимости от времени их обнаружения:
С чего мы начинали, или Jira
Два года назад у нас была выделенная команда тестировщиков, которые вручную тестировали продукт после интеграции кода всех команд. До этого момента код проверялся разработчиками на девелоперских стендах. Ошибки которые находили тестировщики заносились в бэклог в Jira. Баги хранились в общем бэклоге и переезжали из спринта в спринт с другими задачами. Каждый спринт два-три бага доставались и чинились, но большинство оставалось на дне бэклога:
У меня есть подозрения, что за все время работы нашей сети, никто, кроме тестировщиков не воспроизводил эту ошибку. Такого рода ошибки и составляют большинство багов, которые не исправляются.
При таком подходе, когда заносятся все найденные баги, некоторые из них дублируются и большинство из этих багов не чинится возникают проблемы:
Прощай Jira, да здравствует Kaiten
Весной 2018 года мы отказались от Jira и перешли в Kaiten. Смена инструментов была вызвана причинами, о которых Андрей Арефьев написал в статье «Почему Додо Пицца стала использовать Kaiten вместо связки Trello и Jira». После перехода в Kaiten наш подход к работе с багами не изменился:
Время экспериментов, или нет
Мы решили поэкспериментировать с форматами и создали отдельную доску в Kaiten, на которой хранили баги и меняли статусы. Мы упростили заведение баг-репорта, чтобы тратить меньше времени. При добавлении карточки в Kaiten тестировщики помечали разработчиков. Об этом им на почту отправлялось уведомление. Мы вывели эту доску на монитор, который висел в проходе рядом с нашим рабочим местом, чтобы разработчики видели прогресс и процесс тестирования стал прозрачным. Эта практика тоже не прижилась, потому что основной канал общения – Slack. Наши разработчики не проверяют почту часто. Поэтому это решение быстро перестало работать и мы снова вернулись к Slack.
Верните муравьишек
После неудачного эксперимента с доской в Kaiten, некоторые разработчики всё ещё были против формата с сообщением в Slack. И мы стали думать как трекать баги в слаке и решить проблемы, которые мешали разработчикам. В результате поисков наткнулись на приложение для Slack, Workast, которое помогает организовать работу с тудушками прямо в мессенджере. Мы подумали, что это приложение позволит управлять процессом работы с багами более гибко. У этого приложения были свои плюсы: смена статусов и назначение на разработчиков по одному нажатию кнопки, завершенные задачи скрывались и сообщение не разрасталось до огромных размеров.
Так выглядели решенные задачи в приложении Todo и просьбы вернуть «муравьишек». После окончания пробного периода приложения Workast мы решили от него отказаться. Потому что пользуясь этим приложением, мы пришли к тому же, что было во время, когда мы пользовались Jira. Оставались некоторые баги, которые кочевали в этом списке из регресса в регресс. И с каждой итерацией их становилось больше. Возможно, стоило доработать процесс работы с этим расширением, купить его и пользоваться, но мы этого не сделали.
Наш идеальный способ по работе с багами сейчас
Во-первых, у нас не стало выделенной команды тестировщиков. Все тестировщики разошлись в команды разработчиков, для усиления компетенции тестирования команд. Благодаря этому мы стали находить ошибки раньше, до того как произойдет интеграция кода команд.
Во-вторых, мы отказались от ручного регрессионного тестирования в пользу автоматического.
В-третьих, мы приняли «zero bug policy». В статье «#zerobugpolicy или как мы баги чиним» bevzuk подробно рассказывает как мы выбираем баги, которые чиним.
Сегодня процесс работы с багами выглядит следующим образом:
Итоги
Коротко говоря, мы отказались в принципе от баг-трекинговой системы. С помощью такого подхода работы с багами мы решили несколько болей:
А как в вашей компании устроен процесс работы с багами?
Баг-трекер, геймификация и сильное комьюнити: как 36 тысяч участников VK Testers охотятся за багами
Привет! Меня зовут Мария Захарова, я возглавляю команду VK Testers — программы бета-тестирования ВКонтакте. Сегодня ей исполняется пять лет. В честь нашего праздника (а ещё Дня тестировщика) расскажу, как появилась программа и какая она сейчас. Также вас ждёт бонус: в статье можно узнать, как попасть в ряды VK Testers.
Ровно 74 года назад был задокументирован первый баг-репорт. Он связан с именем талантливой американской учёной Грейс Хоппер.
В 1947 году она принимала участие в разработке Mark II — одного из первых программируемых компьютеров. Однажды в реле застрял мотылёк, что блокировало передачу сигнала. Когда коллеги Грейс обнаружили насекомое, она произнесла легендарное слово bug, что переводится как «жук». Позже мотылька извлекли, вклеили в технический дневник и подписали: First actual case of bug being found — «Первый случай в практике, когда был обнаружен баг». А само слово стало термином, который обозначает компьютерную ошибку.
Благодаря этой истории 9 сентября стал профессиональным праздником тестировщиков. Но для нас дата имеет особое значение: именно в этот день была создана программа бета-тестирования ВКонтакте VK Testers.
Если 74 года назад всё началось с мотылька, то наша история начинается с конкурса по тестированию VK Testing Challenge.
В 2016 году ВКонтакте активно запускала новые продукты и представляла релизы. При этом отдел тестирования состоял из шести человек — очередь на проверку становилась всё больше и в какой-то момент достигла нескольких месяцев. Чтобы быстро масштабировать мощности, мы открыли конкурс и создали собственный баг-трекер. Участники заводили туда отчёты по десктопному мессенджеру ВКонтакте.
Эксперимент оказался успешным: мы получили более 20 000 отчётов об ошибках. Некоторое время мессенджер ВКонтакте проверялся только нашим сообществом бета-тестировщиков.
За пять лет многое изменилось:
Всё это время мы исследовали разнообразные подходы и гипотезы: создавали уникальный симбиоз собственного программного продукта и комьюнити тестировщиков, построенного вокруг. Сейчас в нашем сообществе 36 000 пользователей — именно они помогают продуктам на последнем этапе перед запуском.
Сейчас все мажорные обновления ВКонтакте в обязательном порядке проходят бета-тестирование. А, например, бета-версии клиента для Android и вовсе могут выходить несколько раз в день, чтобы конечный пользователь встретил как можно меньше ошибок.
Участники программы не только постоянно проверяют обновления в рамках недельного релизного цикла, но и оставляют предложения — они нередко обретают форму в следующих версиях.
Конечно, часто пожелания пересекаются с планами команды. Но это лишь подтверждает, что для развития продукта выбрано верное направление.
Как правило, участники предлагают небольшие фичреквесты, чтобы пользоваться платформой стало ещё удобнее. Например, добавить новые функции в клиентах: возможность отображать реплаи и переходы к ним, делиться стилями стикеров, выбирать, публиковать ли историю о смене фото в профиле.
Мы часто обращаемся к комьюнити за помощью в нестандартных ситуациях: к примеру, когда ищем стабильные шаги воспроизведения редких ошибок или крашей, сталкиваемся с проблемами на необычных Android-девайсах. Кроме того, перед крупными релизами мы проводим марафоны по тестированию, чтобы в кратчайшие сроки проверить новые функции и получить пользовательский фидбэк. Так было, когда мы запускали Клипы ВКонтакте или обновляли мессенджер. Также этап беты проходят все сервисы на платформе VK Mini Apps, прежде чем попасть в каталог.
Справка: для участия в марафонах по тестированию мы предварительно собираем заявки, чтобы отобрать лучших тестировщиков. В VK Testrun участвуют 30–50 человек: в течение суток они охотятся за багами в новом продукте, соревнуясь друг с другом. Так команда разработки получает концентрированный фидбэк.
Параллельно разработчики исправляют найденные ошибки и выдают всё новые версии продукта тестировщикам, чтобы собрать ещё больше обратной связи. Получается хакатон, только в тестировании.
Чтобы баг-трекером было удобнее пользоваться, мы разработали мобильную версию и собственную дистрибуцию. Только представьте: установить бета-версию приложения можно прямо из баг-трекера, нажав всего одну кнопку, а рассказать об ошибке — на соседней вкладке.
Таким образом, бета-тестировщикам становится проще взаимодействовать и с Командой ВКонтакте, и с самим баг-трекером. Они могут сообщать об ошибках за считаные минуты и тем самым совершенствовать продукты платформы.
Сила VK Testers — в комьюнити. В программе бета-тестировщики плотно взаимодействуют с командами продуктов ВКонтакте и друг с другом. А ещё — много учатся. Мы уделяем пристальное внимание образовательному контенту: постоянно публикуем статьи с теорией, рассказываем об особенностях продуктов. А пару месяцев назад выпустили целый образовательный видеокурс. Получились отличные материалы для полноценного старта в специальности: от истории методов и подходов до автоматизации тестирования мобильных приложений.
Одна из ценностей ВКонтакте — это люди. Поэтому с самого начала мы решили обойтись без пропасти бюрократии и формальностей между участниками программы и сотрудниками ВКонтакте. Этому немало помогла легендарная «Тестировочная №1» — чат-предвестник комьюнити, первыми участниками которого стали ребята из VK Mobile в 2017 году. Именно здесь зародился один из основных форматов работы: тесное сотрудничество в обстановке, где не страшно ошибиться или сказать глупость.
Прямой доступ к общению с Командой ВКонтакте — один из главных мотиваторов. Это поддерживает лояльность, мотивирует на поиск багов и саморазвитие.
Важное место в системе занимают офлайн-мероприятия. В течение года мы проводим несколько встреч, где все могут познакомиться и пообщаться вживую. Также события и конкурсы, которые помогают раскрыть творческий потенциал, регулярно проходят онлайн.
Всё это вместе с высокой вовлечённостью команды помогает программе VK Testers оставаться практически уникальным явлением в мире тестирования.
Мы гордимся, что в нашем сообществе царит атмосфера дружеского соревнования. В этом помогает геймификация: она внедрена в процесс поиска ошибок, чтобы поддерживать здоровую конкуренцию.
Так, пару недель назад мы представили систему достижений. Можно получать значки, если совершать разные действия: например, заводить отчёты, участвовать в крупных проектах и мероприятиях. Большинство ачивок увеличивают рейтинг тестировщика в программе, но некоторые его уменьшают — и хорошие ребята вряд ли их получат. Такие «награды» мы держим в секрете, чтобы не соблазнять участников нарушать правила.
Также мы уже во второй раз проводим премию VK Testers Awards, где отмечаем успехи тестировщиков за год. Премия проходит в день рождения программы. В этот раз мы подготовили 16 номинаций: лучших ждут награды за большое количество принятых отчётов или за качественный поиск уязвимостей. Победителей мы объявим уже сегодня. Они получат диплом, специальную ачивку, а победители в главных номинациях — ещё и короткий адрес ВКонтакте.
Однако в программе VK Testers участников ждут не только виртуальные, но и реальные вознаграждения. За активность бета-тестировщикам даются баллы. Это внутренняя валюта, которую можно потратить в «лавке тестировщика»: на новенький MacBook или iPhone, премиальные устройства на Android или мерч.
Накопить на топовые устройства можно за 4–6 месяцев активного участия в бета-тестировании.
Элементы геймификации мы используем и при тестировании новых продуктов. Например, при крупном обновлении бэкенда историй важно было протестировать их загрузку в формате видео. Мы предложили тестировщикам не просто проверить раздел, но и поучаствовать в конкурсе на лучшую историю — с сюжетом, как ожидаемый и фактический результат драматично не совпадают в жизни. Чтобы победить, нужно было не только снять легендарное видео, но и создать отчёт о баге — желательно, не менее легендарный.
VK Testers — история не только про бета-тестирование. Это настоящая стартовая площадка для ребят, которые хотят начать карьерный путь в IT. Десятки наших «выпускников» работают ВКонтакте и в других компаниях благодаря своим теоретическим знаниям, а главное — огромному количеству практики, полученной в программе.
За пять лет наши тестировщики оставили более 280 000 отчётов в 1 341 продукте.
В VK Testers каждый найдёт что-то своё. Можно научиться тестировать и попасть в Команду ВКонтакте. А кто-то просто будет рад узнавать об обновлениях на платформе раньше других пользователей. Лучше всего нашу работу отражает один из девизов программы — We test with love: мы совершенствуем продукт, к которому неравнодушны.
«ВКонтакте» не платит пользователям за найденные уязвимости
В конце мая ВКонтакте торжественно объявила о запуске открытой программы вознаграждений за уязвимости. Это, как и некоторые другие события, побудило меня на написание этой статьи. История началась еще в сентября 2014, когда во время написания мною сервиса, основанного на API социальной сети, я обнаружил уязвимость, которая позволяла узнавать как администратора сообщества, сделавшего пост, так и человека предложившего эту запись.
1. Обнаружение уязвимости
Уязвимость заключалась в методе API newsfeed.get. При выполнении самого обычного запроса к нему, в объекте, среди прочих, возвращался массив из 4-5 пользователей (profiles). Они, судя по документации, должны были являться пользователями из ленты новостей. Однако я никак не мог найти в ленте этих людей, и зачастую в массиве встречался только мой собственный аккаунт.
Меня заинтересовало это и я начал тестировать этот метод на ленте новостей с записями от моей собственной группы. Потратив вечер на тесты, я нашел закономерности: в массиве возвращались администраторы, сделавшие запись в группу, и люди предложившие эту запись в группу, причем не для одного поста, а для последних четырех, и отдавались они вперемешку, без определенного порядка.
То есть, сделав к newsfeed.get запрос для получения последнего поста в ленте новостей, в массиве profiles мне возвращало администратора написавшего и пользователя предложившего как эту запись, так и предыдущие три.
Это было уже достаточно серьезной уязвимостью, однако мне хотелось связать конкретные посты с конкретными людьми.
Первым делом я стал выносить каждую анализируемое сообщество в отдельный список новостей, так я смог решить проблему, когда пользователи разных сообществ находились в одном массиве. Вторым моим шагом стало сокращение параметра count до одного, таким образом я получил массив profiles для каждого поста группы. После этих действий стало значительно легче анализировать выдачу.
Я написал скрипт, который первым делом создавал список новостей с определенным сообществом. Затем собирал для каждого поста этого сообщества свой массив с профилями. Здесь я столкнулся с лимитами API, оно отдавало мне посты лишь за последние 12 дней, но с этим тоже можно было работать.
После сбора массивов для максимально возможного количества постов, скрипт начинал их анализировать. Для начала находились те пользовательские id, которые встречаются ровно в четырех массивах. Из четырех постов, связанных с этими массивами я находил самый ранний. Этот пост был предложен в сообщество пользователем, чей id мы нашли. Затем эти пользователи отфильтровывались из массивов и мною составлялся список администраторов.
2. Сообщаем об уязвимости
Являясь сознательным пользователем, после этого я отправился сообщать об уязвимости. Так как открытый баг-трекер я счел не лучшим местом для такого рода уязвимости, я связался сразу напрямую с разработчиками. Первый из разработчиков просто не ответил на мое сообщение, второй ответил спустя 4 дня, поблагодарил и обещал подумать, как это исправить.
Я знал об отсутствии официальной bug bounty программы у ВКонтакте, но также знал, что нередки были случаи поощрения за уязвимости внутренней валютой (голосами), однако решил отложить эти вопросы на момент исправления уязвимости. После этого я стал изредка мониторить уязвимость. Это продолжалось до апреля 2015, когда прочитав очередную статью об уязвимости и вознаграждении, я снова проверил свою уязвимость и она не была исправлена.
Я решил связаться по поводу уязвимости с техподдержкой где, спустя две недели ожидания, мне написали, что код передан разработчикам и меня оповестят, как только появятся новости.
Наступил май, я снова решил проверить уязвимость, и она, наконец, была исправлена. На это потребовалось 8 месяцев. Со мной, несмотря на обещания, никто так и не связался, поэтому я решил написать сам, и заодно узнать критерии, по которым социальная сеть выплачивает вознаграждения. Меня ждала очередная неделя ожидания ответа от техподдержки, и сам ответ, в котором мне предложили подождать ещё.
Со мной связались лишь 29 мая, спустя несколько часов после запуска программы вознаграждения за уязвимости, заявив, что раз «уязвимость уже исправлена, то она не подпадает под новую программу и им мне нечего предложить».
Итоги
UPD: Похоже, после запуска программы поощрения ситуация изменилась не сильно.