Как правильно сообщать о багах, чтобы их быстро исправляли

17 февраля 2017

В разгар сосредоточенной деятельности программистов отвлекают вопросы в скайпе. Иногда достаточно ответить, но бывает, выясняется, что на проекте возникла ошибка, требующая исправления, и мы начинаем уточнять детали, создаем задание в багтрекере, согласовываем сроки решения. А возвращаясь к прерванному делу, обнаруживаем, что прошло сорок минут. А потом менеджер спросит: «Вася, почему ты задачу оценил в 7 часов, а выполняешь второй день?»

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

		Если изложить суть непонятно или сумбурно, на выяснение деталей уйдёт дополнительное время, которое оплачиваете вы. При этом от текущих дел отрываются один, а то и несколько сотрудников.
		Может создаться иллюзия срочности. Например, разработчик попытается воспроизвести указанный дефект, не дождавшись ответов на уточняющие вопросы, и сразу попытается его исправить, что хорошо, если проблема критическая, плохо, если минорная (а есть более важные задания), и очень плохо, если вы вообще не планировали исправление.
		Возможна и обратная ситуация: обсуждаемая в скайпе неполадка может там и остаться. Многие сотрудники справедливо полагают, что решение вопроса начинается с заведения задачи в багтрекере. Скайп — лишь инструмент коммуникации, где можно оперативно обсудить текущий проект. В багтрекере же фиксируются задания, комментарии и принятые решения. Разбор спорных ситуаций производится тоже по багтрекеру. Иными словами, если вы собираетесь написать в скайпе что-то вроде «было бы неплохо сделать так...», а потом, спустя неделю, возмущаться, почему до сих пор «так» не реализовано, то, пожалуйста, не надо.
		Если вы не заведёте задачу в багтрекере, её заведём мы. Тогда следует проследить, что с ваших слов записано верно.

Что надо сделать?

Время идёт, проект не готов, а бюджет не резиновый. Есть два варианта.

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

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

Заголовок

Итак, возникла неполадка, о которой нужно заявить. Первое, что указываем при заведении задачи, — это заголовок, при первом взгляде на который должно быть понятно, что случилось. Заголовок должен отвечать на три вопроса.

«Что?» — что, собственно, произошло?

«Где?» — в каком месте интерфейса вы видите проблему?

«Когда?» — при каких обстоятельствах проявляется проблема?

Приведем примеры, когда заголовок не отвечает ни на один из вышеуказанных вопросов.

«Снова ничего не работает» — непонятно, что конкретно не работает.
«Неясная кнопка» — без комментариев.
«Логин и пароль» — пожалуйста, не надо таких заголовков.

Примеры, когда заголовок отвечает только на часть вопросов.

«Слетает вёрстка на сайте» — понятно, что на сайте есть ошибки с вёрсткой, но неясно, в чём суть.
«Разная вёрстка текста» — напрашиваются дополнительные вопросы, потому что всё ещё непонятно, о чём речь.
«Сбой в графике Dashboard» — что-то произошло на экране Dashboard, но непонятно, что считать за сбой. Возникнут дополнительные вопросы.
«Не отображаются некоторые сообщения в личном кабинете» — заголовок уже можно считать неплохим. Здесь не хватает информации, какие сообщения и при каких обстоятельствах не отображаются, но выяснение требует времени, а сообщить об ошибке нужно быстрее.
«С первого раза не осуществляется переход с вкладки «Мои камеры» на вкладку «Гостевой доступ» — а вот здесь не помешало бы уточнить, при каких обстоятельствах такое происходит: у разработчика проблема может и не воспроизвестись.
«Ошибка при отправке Issue» — неплохо.
«В административной части пропала возможность настройки кинотеатров» — случай, когда ответа на вопрос «Когда?» не требуется.

Примеры хороших заголовков, отвечающих на вопросы «Что? Где? Когда?».

«Не все сообщения, доставленные как push, отображаются в ЛК» — сразу ясно, с чего начинать отладку.
«IE 8 постоянно ругается на форме подачи объявления, начиная от первого шага» — здесь только непонятно, что подразумевается под «ругается», но, открыв форму подачи объявления в IE 8, мы всё увидим.
«В панели фильтров цена не «инициализируется», когда поставлен фильтр по цене» — можно открывать участок кода, отвечающий за фильтр по цене, и смотреть что там не так.
«При просмотре записи по-прежнему доступны кнопки управления поворотным механизмом» — в видеозаписях же нет смысла в поворотах камеры, значит забыли убрать кнопки поворота, скоро исправим.
«Обходится ограничение на количество объявлений частного лица вводом прямой ссылки в адресную строку» — всё ясно, добавим перенаправление.

Описание

В большинстве случаев, при хорошо составленном заголовке описание проблемы может даже не потребоваться. С другой стороны, качественно заполненное поле «Description» может нивелировать недостатки заголовка, и даже указать на решение. Были случаи, когда ошибка, имеющая детальное описание, исправлялась в течение десяти минут, а без такового — несколько часов. В первом случае разработчик сразу понял, какую строчку кода ему править. Во втором — полдня отлаживал код, прежде чем выяснил причины сбоя.

Что нужно указать в описании задачи.

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

Приоритет

Создавая задачу, вы можете определить степень серьёзности, исполняя роль руководителя проекта (ведь вы, по факту, им и являетесь). Градации серьёзности следующие.

Блокирующая (Blocker) — приступать стоит немедленно, без устранения дефекта всё остальное не имеет смысла.
Критическая (Critical) — ошибку исправят оперативно, назначив лучших специалистов.
Значительная (Major) — значение серьёзности по умолчанию. Заданий с таким приоритетом в проекте большинство.
Незначительная (Minor) — вопрос не требует срочного вмешательства, к нему приступят после решения большей части прочих задач.
Тривиальная (Trivial) — задания подобного рода будут выполняться в последнюю очередь.

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

Артём Карюкин

технический директор