Выбираем подходящий баг-трекинг

Содержание:

Время экспериментов, или нет

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

Интро

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

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

Bugzilla багтрекер

Bugzilla — свободная система отслеживания ошибок (багтрекинг) с веб-интерфейсом. С одной стороны, Bugzilla довольно проста, с другой стороны, там есть всё, что нужно для багтрекинга типичного проекта. Данный трекер самый простой из всех перечисленных и обладает наименьшим функционалом, что одновременно и хорошо и плохо. Его не получится использовать для больших и сложных проектов, но для малых и простых — вполне. Таск в данном багтрекере выглядит следующим образом:

багзилла (Bugzilla) багтрекер

Его основными пунктами являются:

тайтл
статус
сивирити
ключевые слова
ссылка на ресурс
окружение
кому назначен
приоритет
приложения

Итак, из всего вышеперечисленного предпочтительнее конечно выбрать Jira, т.к. это наиболее прогрессивный багтрекер с ну очень обширным функционалом. К такому функционалу и добавить-то нечего. Но этот багтрекер платный, хоть и не сильно дорогой.

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

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

Верните муравьишек

После неудачного эксперимента с доской в Kaiten, некоторые разработчики всё ещё были против формата с сообщением в Slack. И мы стали думать как трекать баги в слаке и решить проблемы, которые мешали разработчикам. В результате поисков наткнулись на приложение для Slack, Workast, которое помогает организовать работу с тудушками прямо в мессенджере. Мы подумали, что это приложение позволит управлять процессом работы с багами более гибко. У этого приложения были свои плюсы: смена статусов и назначение на разработчиков по одному нажатию кнопки, завершенные задачи скрывались и сообщение не разрасталось до огромных размеров.

Так выглядели решенные задачи в приложении Todo и просьбы вернуть «муравьишек». После окончания пробного периода приложения Workast мы решили от него отказаться. Потому что пользуясь этим приложением, мы пришли к тому же, что было во время, когда мы пользовались Jira. Оставались некоторые баги, которые кочевали в этом списке из регресса в регресс. И с каждой итерацией их становилось больше. Возможно, стоило доработать процесс работы с этим расширением, купить его и пользоваться, но мы этого не сделали.

Наш идеальный способ по работе с багами сейчас

В конце 2018 - начале 2019 года у нас в компании произошли ряд изменений, которые повлияли на процесс работы с багами.
Во-первых, у нас не стало выделенной команды тестировщиков. Все тестировщики разошлись в команды разработчиков, для усиления компетенции тестирования команд. Благодаря этому мы стали находить ошибки раньше, до того как произойдет интеграция кода команд.
Во-вторых, мы отказались от ручного регрессионного тестирования в пользу автоматического.
В-третьих, мы приняли «zero bug policy». В статье «#zerobugpolicy или как мы баги чиним» bevzuk подробно рассказывает как мы выбираем баги, которые чиним.
Сегодня процесс работы с багами выглядит следующим образом:

Недоделки. Тестировщики сообщают о проблеме аналитикам или продакт менеджерам. Идут ногами, показывают, воспроизводят, объясняют как это повлияет на клиентов и решают нужно ли это починить до релиза или можно починить позже, а может даже и не стоит чинить совсем.
Баги в регрессе, которые нашли автотесты, чинит команда, которая трогала этот участок системы и мы не релизим этот код, пока не решим проблему. Тестировщики фиксируют эти баги в произвольном формате в канале релиза в Slack.
Баги с прода. Такие баги попадают напрямую к владельцам задач. Аналитики прогоняют ошибки по Матрице приоритетов бага и добавляют в бэклог либо фиксируют у себя, накапливая статистику обращений по этой проблеме.

Блокировки ВКонтакте, с помощью подмены изображения.

Есть такая тема.. Например, кто-то сделал репост записи из паблика где изображена простая картинка. Мы делаем репост уже записи со стены этого человека. Но тут на нашей стене нас может ожидать некий баг, и мы обнаружим что мы репостнули вообще другой пост из паблика. И будет вообще видео и ссылка над ним с надписью vto.pe и это именно та ссылка, за которую ВКонтакте может Вас заблокировать/забанить. И после перезагрузки страницы моментально Вы можете заметить, что «Страница временно заблокирована» за размещение этого поста, по сути блокировка происходит именно из-за ссылки, а не из-за видео.

Можете попробовать сделать репост первой записи, с этой страницы и проверить таким образом, что репост вышел совсем иной записи (Но имейте ввиду, что Вашу анкету заблокируют).

Redmine багтрекер

Redmine — открытое серверное веб-приложение для управления проектами и задачами (в том числе для отслеживания ошибок). Redmine представляет собой приложение на основе широко известного веб-фреймворка Ruby on Rails.

редмайн (Redmine) багтрекер

На рисунке выше вы можете увидеть пример таска из Редмайна.

Он имеет следующие черты:

трекер (определяет вид таска)
тема
описание
статус таска
приоритет
категория (к чему относится таск)
версия
аттачмент

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

С чего мы начинали, или Jira

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

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

Приведу простой пример. При построении отчётов в полях ввода даты по умолчанию подставляется сегодняшний день. При изменении даты в попапе можно снова выбрать сегодняшний день и поле ввода даты очистится.
У меня есть подозрения, что за все время работы нашей сети, никто, кроме тестировщиков не воспроизводил эту ошибку. Такого рода ошибки и составляют большинство багов, которые не исправляются.
При таком подходе, когда заносятся все найденные баги, некоторые из них дублируются и большинство из этих багов не чинится возникают проблемы:

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

Прощай Jira, да здравствует Kaiten

Весной 2018 года мы отказались от Jira и перешли в Kaiten. Смена инструментов была вызвана причинами, о которых Андрей Арефьев написал в статье «Почему Додо Пицца стала использовать Kaiten вместо связки Trello и Jira». После перехода в Kaiten наш подход к работе с багами не изменился:

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

Баги которые нашли на проде заносились в бэклог, Product Owner, расставлял приоритеты и выбирал те, которые будем чинить.

Рейтинг баг-трекеров 2016

#	Название	Год
1		2000
2		1998
	Directual	2016	Low-code платформа — фреймворк для быстрой разработки
3		2006

О рейтинге

Рейтинги сервисов для автоматизации таск-трекинга проводятся Тэглайном в четвертый раз и сформированы на основе анкетирования (проводилось с августа 2014 по апрель 2016 года) 510+ digital-агентств и продакшнов с производством и/или клиентским офисом в России: респондентам предлагалось выбрать один или несколько вариантов ответа на вопрос «Какие сервисы и ПО вы используете для автоматизации таск-трекинга (управления задачами)?».
Экспертной группой было принято решение разделить сервисы на 3 рейтинга:
1. Рейтинг таск-менеджеров (специализированных решений для управления задачами).
2. Рейтинг неспециализированных сервисов для таск-трекинга.
3. Рейтинг баг-трекеров.
Часть решений респонденты добавили сами (а не выбрали из уже существующих вариантов), например, Wrike, «ПланФикс», Pivotal Tracker и другие, которые вошли в Топ вместе с остальными сервисами для автоматизации таск-трекинга из предефайнд-списка.
Динамика приводится по сравнению с данными, полученными Тэглайном за период с мая 2013 по август 2014 года.

Инновационный подход к управлению задачами

Быстрое изменение задач

YouTrack предлагает ряд способов вносить изменения в задачи — как из списка задач, так и со страницы просмотра отдельной задачи. Все это выполняется одним щелчком мыши. Но это еще не все!

Навигация с клавиатуры

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

Добавление наблюдателей

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

Возможность отметки задач

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

Управление дубликатами

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

Окно вызова команды

Чтобы ускорить редактирование задач, YouTrack предоставляет мощный инструмент, позволяющий сэкономить время, — окно вызова команды. Изменяйте атрибуты задач и их наборов, используя основанные на естественном языке команды, похожие на поисковые запросы. Например, вы можете:

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

Все необходимые подробности

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

Упоминания @пользователей

Самый простой способ пригласить нового участника в обсуждение задачи — это упомянуть его @имя пользователя. Например, добавьте «@ivan.petrov» в комментарий к задаче, чтобы включить Ивана Петрова в список ее наблюдателей, и он будет уведомлен о вашем комментарии и обо всех последующих изменениях задачи.

Создание связей задач

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

Применение команд

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

Команда изменит приоритет всех выбранных задач на «Критическая», назначит их Егору Сидорову, установит состояние «В обработке» и отметит их тегом «срочно исправить».

Ненавязчивые оповещения

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

Голосование за задачи

Хотите, чтобы пользователи могли голосовать за нужную им функциональность, помогая вам правильно расставлять приоритеты? Дайте им возможность сообщать о своих пожеланиях нажатием на кнопку «Проголосовать» в списке задач или на странице отдельной задачи (а также при помощи команды Отдать голос).

Предпросмотр ссылок на задачи в мессенджерах

Когда вы отправляете ссылки на задачи коллегам в Slack или Telegram, они автоматически отображаются в режиме предпросмотра. Предпросмотр также показывается при вставке ссылок в публикации на Facebook. Эта функциональность помогает экономить время, поскольку вы можете легко определить, хотите ли вы открыть задачу или нет.

Что такое Agile и Scrum?

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

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

люди и взаимодействие важнее процессов и инструментов;

работающий продукт важнее исчерпывающей документации;

сотрудничество с заказчиком важнее согласования условий контракта;

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

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

Scrum — это методология управления проектами, позволяющая планировать изменения, которые будут выполнены, и контролировать их выполнение.

Сущности Scrum:

Product Backlog — список задач, которые нужно выполнить;

Sprint Backlog — задачи, которые будут выполнены в ближайшей итерации;

Sprint — итерация, по ходу которой (после планирования и до окончания), проходят ежедневные встречи команды, где обсуждается процесс выполнения задач;

обновление системы.

Для контроля выполнения задач в Scrum используется доска (рис. 2), по которой можно отслеживать процесс выполнения задач. Доска может иметь много состояний, у каждой команды они называются по-своему, но основные из них три:

задачи, которые еще не выполняются, но планируются на эту итерацию;

задачи, которые сейчас разрабатываются;

задачи, которые уже выполнены и будут выпущены в конце итерации.

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

Общее описание BTS (bug traking systems)

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

Как правило, BTS позволяет хранить информацию об ошибке в следующем виде:

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

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

Необходимо заметить, что системы отслеживания ошибок могут быть полезны не только для программистов. Отчеты о «работе над ошибками» могут использовать менеджеры проекта. Фактически такие отчеты позволяют судить о производительности программистов, при работе по улучшению работы ПО. При обработке отчетов необходимо учитывать приоритет ошибок и сложность их устранения. Менеджер должен понимать, что некоторые ошибки могут быть трудно устранимы, в силу архитектуры системы. Бессмысленно требовать скорейшего устранения ошибок в системных модулях: непродуманные действия по устранению одной ошибки могут породить сотни других ошибок.

Состав информации о дефекте

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

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

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

Жизненный цикл дефекта

Как правило, система отслеживания ошибок использует тот или иной вариант «жизненного цикла» ошибки, стадия которого определяется текущим состоянием, или статусом, в котором находится ошибка.

Типичный жизненный цикл дефекта:

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

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

4. далее тестировщик проводит проверку исправления, в зависимости от чего дефект либо снова переходит в статус назначен (если он описан как исправленный, но не исправлен), либо в статус закрыт.
5. открыт повторно — дефект вновь найден в другой версии.

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

Интро

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

Прощай Jira, да здравствует Kaiten

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

Свежие рейтинги

Хостинг-панели, 29 апреля

Платежные инструменты, 28 апреля

CRM-системы, 27 апреля

Таск-трекеры, 26 апреля

Веб-статистика, 25 апреля

Серверные ОС, 22 апреля

Системы контроля версий, 21 апреля

Базы данных (СУБД), 20 апреля

Мобильная статистика, 19 апреля

Мобильное тестирование, 18 апреля

Краш-репортеры, 15 апреля

Мобильные платформы / ОС, 14 апреля

Среды разработки (IDE), 13 апреля

Фреймворки, 12 апреля

Языки программирования, 11 апреля

Сервисы-репозитории, 8 апреля

Инструменты для дизайна и проектирования, 7 апреля

Сервисы для ведения Wiki, 6 апреля

Сервисы для ведения бухгалтерии, 5 апреля

Мессенджеры для работы, 4 апреля

«Необычная картинка».

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

Итак, размещаем картинку на стене. Нажимаем «Отправить». Картинка есть, перезагружаем страницу и как видим картинка исчезла, а пост остался, и он пустой. Также среди фотографий Вы эту картинку не найдёте. Кстати, через личное сообщение происходит тоже самое, и фотки нету даже в личных сообщениях и в прикреплённых файлах.

Короче говоря, некая магия от ВКонтакте, и очевидно ощущение, что твои сообщения кто-то просматривает..

Jira багтрекер

Jira — платная программа, которая позволяет управлять не только ошибками и поручениями, но также и проектами в целом. Была разработана компанией Atlassian Software Systems. Используется более чем 15 000 компаний по всему миру. Среди ее пользователей значатся Microsoft, BBC, Nokia, Boeing и др. У данной программы очень широкий функционал, но мы остановимся на непосредственном ее функционировании как багтрекер. Визуализацию главного компонента — таска — вы увидите ниже:

джира (jira) багтрекер

Jira заполняется задачами (англ. tickets или issues) . Задача содержит следующие основные компоненты:

название проекта

тайтл

тип

приоритет

версии

компоненты

подкомпоненты

статус

резолюция

приложения (фото, видео, документ)

комментарии

саб-таски (если есть)

Компоненты таска могут быть расширены дополнительными полями или ограничивать свой вид через настройки. Задача может редактироваться или просто изменять статус, например, из «открыт» в «закрыт». Какие переходы между состояниями возможны, определяется через настраиваемый рабочий процесс(бизнес-процесс) (workflow). Через него в принципе можно управлять рабочим процессом на проекте, определять роли и т.д. Любые изменения в задаче протоколируются в журнал.

Jira имеет большое количество возможностей конфигурации: для каждого приложения может быть определен отдельный тип задачи с собственным workflow, набором статусов, одним или несколькими видами представления (англ. screens). Кроме того, с помощью так называемых «схем» можно определить для каждого индивидуального Jira-проекта собственные права доступа, поведение и видимость полей и многое другое. Эта система поддерживает также эджайл технологии. С помощью интерактивной доски можно следить за процессом перемещения тасков, таким образом регулируя общую тенденцию работы по проекту.

Состав информации о дефекте

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

С кем и где общается пользователь?

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

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

Ссылка проверена также и на скрытых анкетах. Чтобы избежать ошибку «Запись не найдена», кликните на дату поста. В таком случае ошибки не будет..

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

Если у Вас возникли сложности с определением ID, то Вам поможет данная ссылка, которая ведёт на раздел для разработчиков (Developers):

Пролистав в самый низ, нам нужна будет форма с названием «Пример запроса», в поле «user_ids» Вы можете вписать завуалированный (буквы / цифры) адрес ID. Затем нажать «Выполнить», после чего справа в коде Вам будет уже известен оригинальный цифровой ID пользователя.

К примеру у нас есть ссылка: https://vk.com/durov Понимаем, что цифровой ID скрыт, вставляем durov в строку формы, нажимаем «Выполнить». Видим справа ID: 1.

Жизненный цикл дефекта [ править | править код ]

Типичный жизненный цикл дефекта:

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

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

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

Багтрекеров много, но самые популярные из них у всех на слуху: JIRA, Redmine, Bugzilla . Пройдемся по каждому из них в отдельности.

Как всё начиналось

Удивительно, но на начало 2018 года большинство девелоперов могут оценить эффективность каналов трафика только по начальным метрикам воронки (постклик на сайте, длительность и стоимость звонка).

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

Так же было и в мобайле. По меркам диджитала довольно давно — лет 5 назад.

Основным KPI для всех неигровых клиентов была стоимость установки приложения (CPI). Не учитывалось, что делают пользователи после инсталла, главное — количество установок и их стоимость.

Сложность была в отслеживании источников трафика. Наиболее популярные системы в те времена — Flurry и Google Analytics. Последняя ставилась вообще автоматом. По одной простой причине — была самой известной.

Эти две системы изначально были аналитикой, но пытались сойти и за трекинг. Например, мы отслеживали установки с разных каналов трафика с помощью Flurry. Правда, приходилось мириться с потерями до 100% и отсутствием интеграции со многими каналами трафика.

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

Благодаря аналитике сейчас CPI — это всего лишь модель закупки трафика, но никак не конечный KPI.

Трекинг любых каналов трафика легко осуществим, но появились новые вызовы — борьба с фродом, глубокие ссылки (deeplink), динамический ретаргетинг, мультиканальная атрибуция и тому подобное.

Итоги

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

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

Я не хочу сказать, что трэкинг багов бесполезен. Баги которые мы берём в работу трэкаются как и любые другие задач. Но баг-трэкинговая система это не обязательный атрибут тестирования. Её не нужно использовать только потому, что используют большинство компаний и так принято в индустрии. Нужно «думать головой» и примерять инструменты к своим процессам и потребностям. Для нас идеально работать без баг-трекинговой системы сейчас. За пол года такой работы, мы ни разу не подумали о том, чтобы вернуться к ней и снова заводить все баги туда.
А как в вашей компании устроен процесс работы с багами?

View the discussion thread.