Баг-трекинг: учёт ошибок на доске, где ничего не теряется

Типичная картина без учёта ошибок: тестировщик нашёл дефект и написал о нём в общий чат, поддержка переслала жалобу клиента в личку разработчику, менеджер вспомнил про «ту самую ошибку с оплатой» на созвоне. Дефекты рассыпаны по чатам, почте и головам. Никто не знает точного числа открытых ошибок: то ли пять, то ли пятьдесят. Непонятно, что критично, а что подождёт, — всё выглядит одинаково срочным, пока не упадёт продакшн. Одну и ту же ошибку заводят по третьему разу, потому что не видно, что она уже в работе. «Починили?» — «Вроде да» — а проверить некому и негде, статуса нет. Разработчик исправил баг, но забыл сказать тестировщику, и тот гоняет старую версию. Когда руководитель спрашивает «сколько багов висит и что из этого горит», ответ собирают вручную, листая переписку. Чем больше продукт и активнее пользователи, тем чаще ошибка проваливается между чатом и памятью — и всплывает уже жалобой клиента.

Из чего складывается учёт ошибок в Shtab вместо чатов и устных жалоб:

• Доска ошибок — все дефекты карточками на канбан-доске с колонками-статусами «Открытые» → «В процессе» → «На проверке» → «Закрыты»; сразу видно, сколько багов и на каком они этапе.
• Карточка дефекта — в описании шаги воспроизведения (что делали, что ожидали, что получили), а скриншот или запись экрана прикреплены файлом к той же карточке.
• Серьёзность и приоритет — метки серьёзности («критично», «средне», «мелочь») и поле приоритета показывают, что чинить первым, а что подождёт.
• Ответственный и статус — у каждой ошибки есть исполнитель и контролирующий; статус карточки всегда отвечает на вопрос «на каком этапе».
• Связь с задачей на исправление — ошибку можно связать с задачей разработки через поле связей, чтобы видеть, какой правкой она закрывается.
• Подзадачи и чек-лист — крупный дефект разбивается на подзадачи, а проверку после исправления удобно вести чек-листом прямо в карточке.
• Фильтры и группировка — группировка по исполнителям, приоритетам или меткам и сохранённые фильтры собирают, например, все критичные открытые ошибки в один список.
• Обсуждение у ошибки — комментарии ведутся в самой карточке, поэтому история «почему так решили» не расползается по чатам.

Небольшая команда делает веб-сервис: тимлид, двое разработчиков, тестировщик и человек из поддержки. Раньше ошибки жили где придётся: тестировщик писал в чат, поддержка пересылала жалобы клиентов в личку, а критичные баги обсуждали голосом на созвоне и половину забывали. Числа открытых ошибок не знал никто. Завели в Shtab проект «Ошибки» и внутри — доску со статусами «Открытые» → «В процессе» → «На проверке» → «Закрыты». Теперь любой найденный дефект становится карточкой, а не сообщением, которое утонет к вечеру.

Разложили поток по правилам. Тестировщик нашёл баг: в карточке пишет шаги воспроизведения — что открыл, что нажал, что ожидал увидеть и что получил, — и прикладывает скриншот файлом. Ставит метку серьёзности «критично» и приоритет, назначает разработчика. Карточка встаёт в колонку «Открытые». Поддержка заводит клиентские жалобы туда же: не в личку, а карточкой с описанием и меткой, чтобы ни одна не потерялась. Тимлид раз в день открывает доску, группирует карточки по приоритету и сразу видит, что критичного открыто, а что можно отложить.

Дальше — работа и проверка. Разработчик берёт ошибку, переносит карточку в «В процессе», связывает её с задачей на исправление через поле связей — видно, какой правкой закрывается дефект. Крупный баг с несколькими причинами он разбивает на подзадачи. Починил — двигает карточку в «На проверке» и пишет комментарий, что исправлено и в какой сборке. Тестировщик видит статус (не нужно спрашивать в чате «ну что, готово?»), проверяет по шагам из описания, отмечает пункты чек-листа и, если всё чисто, переносит карточку в «Закрыты». Если баг снова воспроизвёлся — возвращает в «Открытые» с комментарием, и вся история остаётся в одной карточке.

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

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

• Открытых ошибок сейчас — сколько дефектов в колонках «Открытые» и «В процессе»; наконец есть точное число вместо «то ли пять, то ли пятьдесят».
• Критичных в работе — сколько ошибок с меткой высокой серьёзности не закрыто; первый сигнал, всё ли под контролем.
• Ждут проверки — карточки в статусе «На проверке»: исправления, которые зависли без тестировщика, видно сразу.
• Заведено и закрыто за период — сколько ошибок пришло за неделю и сколько закрыто; успевает команда разгребать поток или он копится.
• Повторяющиеся дефекты — скопление карточек с одной меткой или в одном разделе: признак, что чинить надо причину, а не симптомы.
• Нагрузка по исполнителям — у кого десять открытых багов, а у кого два; видно после группировки карточек по исполнителям.

• Заводите каждую ошибку карточкой, а не сообщением в чате. Дефект в переписке — это дефект, который к вечеру утонет; карточка на доске остаётся.
• В описании фиксируйте три вещи: что делали, что ожидали, что получили. Без шагов воспроизведения ошибку невозможно проверить и легко закрыть «не воспроизводится».
• Прикладывайте скриншот или запись экрана файлом к карточке. Словами «кнопка не работает» баг не передать; картинка экономит переписку.
• Разделяйте серьёзность и приоритет метками и полем приоритета. «Критично» и «горит прямо сейчас» — не одно и то же; смешаете — всё будет выглядеть срочным.
• Не плодите статусы. Четырёх колонок («Открытые», «В процессе», «На проверке», «Закрыты») хватает; пятнадцать никто не держит в актуальном виде.
• Связывайте ошибку с задачей на исправление через поле связей, чтобы было видно, какой правкой закрыт дефект и не потерялась причинно-следственная нить.
• Перед закрытием проверяйте по шагам из описания и отмечайте чек-лист. «Вроде починили» без проверки — это баг, который вернётся жалобой клиента.

• Ошибки живут в чатах и на словах. Дефект тонет в переписке, число открытых не знает никто. Починка: каждая ошибка — карточка на доске, чат для обсуждения, но не для учёта.
• Нет шагов воспроизведения. «Что-то сломалось» невозможно проверить, разработчик закрывает «не воспроизводится». Починка: в описании что делали, что ожидали, что получили, плюс скриншот.
• Всё одинаково срочно. Без серьёзности и приоритета критичный баг стоит в очереди за косметическим. Починка: метки серьёзности и поле приоритета, работа сверху вниз.
• Дубли одного дефекта. Одну ошибку заводят трижды, потому что не видно, что она уже в работе. Починка: доска и фильтры — сначала ищем, потом заводим.
• Исправление без проверки. «Починили» на словах, статуса нет, тестировщик не в курсе. Починка: статус «На проверке», проверка по шагам, только потом «Закрыты».
• Ждём от Shtab того, чего в нём нет. Рассчитывать на привязку к коммитам, автоскриншоты и интеграции с CI — и разочароваться. Починка: за этим — в инструменты разработчика; Shtab держит учёт и поток ошибок.

Совсем маленькой команде хватит одного проекта «Ошибки» с доской из четырёх статусов, метками серьёзности и ответственными — без связей и подзадач на старте. Команде побольше пригодится группировка по приоритетам и исполнителям, связь ошибок с задачами разработки и сохранённые фильтры под критичные баги. По характеру потока: если дефектов немного и они разнородные — ведите их одной доской и разбирайте по приоритету; если ошибки массовые и повторяются — опирайтесь на метки, чтобы отлавливать скопления и чинить причину. Держите в голове рамку: Shtab наводит порядок в учёте и потоке дефектов, но не заменяет специализированный трекер разработчика с привязкой к веткам кода, автоскриншотами и интеграциями с CI. Если вам нужна работа над самим продуктом целиком — дорожная карта, бэклог и discovery, — это отдельный сценарий для продуктовой команды. А чтобы собрать базовый порядок в задачах и проектах вокруг ошибок, начните с тем управления проектами и контроля задач.