Баг-трекинг - это хранение каждого известного дефекта в одном месте, в форме, которая переживёт отпуск того, кто его нашёл. В этом вся идея. Программа, которую имеют в виду, когда говорят «баг-трекер», - всего лишь картотека, которая делает это возможным.

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

Что трекер обязан уметь

Четыре вещи. Всё остальное - удобство.

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

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

Что идёт в запись

Меньше, чем просит большинство шаблонов, и больше, чем несёт большинство отчётов.

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

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

Три способа развалиться

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

Кладбище. Ничего никогда не закрывается, поэтому счётчик только растёт, поэтому список никто не читает, поэтому настоящие дефекты приходят и остаются незамеченными. Восемьсот задач, которые в этом году никто не открывал, - не запись о чём-либо; это место, куда всё уходит.

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

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

Откуда берутся записи, важнее того, какой инструмент их хранит

Команды подолгу выбирают между трекерами и почти не думают о шаге до этого - о том, как дефект вообще попадает от увидевшего его человека в трекер.

Именно на этом пути отчёты и умирают. Кто-то замечает проблему, и между тем, чтобы заметить, и тем, чтобы написать полезную запись, лежит разрыв: какой это был браузер, что было в консоли, какой был URL, куда я нажал первым. Большинство людей в большинстве случаев напишут две фразы и пойдут дальше, потому что альтернатива - пятнадцать минут расследования ради чужой ошибки.

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

Session Replay

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

Установить расширение

Как выбрать

Честный совет в том, что выбор значит меньше, чем привычка. Jira, Linear, GitHub Issues, Bugzilla, Trello со столбцом «Баги»: все четыре вещи выше достижимы в любом из них, и ни один из них не сделает их за вас.

Кандидату стоит задать два вопроса, и это не те вопросы, что стоят на страницах сравнений:

Слабый вопрос
У какого больше интеграций и лучше панели отчётности?
Вопрос получше
Сможет ли человек не из команды разработки завести туда запись без посторонней помощи, и найдёт ли кто-нибудь двухлетнюю запись по тем словам, которые помнит?

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

Трекинг, тестирование и всё остальное

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

Трекер не улучшает программу. Он не даёт потратить один и тот же день дважды.