Дорогой разработчик,

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

Для этого используются системы управления дефектами вроде «Mantis».

• Да, можно называть дефекты багами. Главное не в названии, главное в том, что их надо чинить.

Принципиальная схема работы с Mantis

1. Если ты видишь баг — сделай об этом запись в Mantis. Не емайлом, не в скайпе, и не лично, и не молча, если на его починку нужно больше, чем десять секунд. Просто запиши это в Mantis.
2. Заполнить там надо всего лишь четыре поля:
   1. Category — это выпадающий список категорий в отдельно взятом проекте.
   2. Summary — заголовок репорта о проблеме. Опиши свой «wtf?» кратко и без подробностей.
      • Пример неправильного заголовка: «Не могу сохранить пароль».
      • Пример правильного заголовка: «Не могу сохранить пароль если использую заглавные буквы».
   3. Description — а вот тут пиши подробности.
   4. Steps To Reproduce — пожалуй, самая важная часть репорта. Ведь программист, который получает сообщение о баге, но не понимает, что и как ты сделал и почему появился баг — это очень рассерженный программист…
      1. Пример шагов для воспроизведения:

         1. Залогиниться на сайте (tester101/tester101)

         2. Создать тикет в суппорт.

         3. На третьем экране в поле Label вписать слово с двоеточием - 'doc:doc'.

      2. Конечно, записать это требует чуть больше времени, чем сказать «Слушай, это, там чего-то не работает, вот...» Зато потом в ответ не получишь «Я там чо-та пофиксил, я хз, если оно то, о чем ты говорил ваще-та…«
3. Приложи скриншот найдненного тобою бага. Иногда это важнее слов.
4. В Mantis появляется новая задача со статусом New.

А поскольку мы еще и знаем, на чье имя направить этот репорт, и укажем это в системе, то статус нового репорта будет Assigned. И это очень круто, ведь:

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

Что такое issue?

Все записи в Mantis называются issue.

Принципиально это переводится как «предмет спора, разногласие, проблема». Обычно это переводят как «Задача».

Фишка в том, что каждое отдельно взятое issue может быть или в любой момент стать как «СООБЩЕНИЕМ О БАГЕ», и «ЗАДАЧЕЙ НА РАЗРАБОТКУ».

Если я сделал запись с сообщением о дефекте — это сообщение о баге.

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

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

Общие правила работы с Mantis

1. Созданная задача получает уникальный номер в системе, и статус New.
2. Если при создании задачи был выбран человек, который будет за нее отвечать, статус задачи становится Assigned.
3. Конечный статус задачи closed. До тех пор, пока задача не получила статус closed — она все еще находится в работе.
4. За каждую отдельную задачу отвечает тот, на чье имя она записана. Для этого используется поле Assigned To. Если ты уверен, что твое участие больше не требуется — переведи задачу в статус Resolved и укажи имя того, кому ты ее передаешь.
5. Прекрасен принцип «One Bug — One Issue». Например, существует задача, которая была источником разработки. А мы нашли баг, который касается непосредственно этой задачи.
6. Не надо вписывать баг как комментарий к задаче — надо сделать новое issue. Иначе потом будет очень сложно «управлять багами», и будет сложно понять, сколько багов было найдено, и сложно объяснять, что «это задача, и она сделана, но в комментариях есть баг, и он не починен». Все задачи, которые связаны между собой, можно слегко «линковать» посредством поля Relationships.
7. Не стесняйся адекватно и вовремя менять статус задачи, с которой работаешь.
8. Будь внимателен с типом задачи (Issue type). Каждый тип («Feature Request», «Change Request», «Bug», «Information») обрабатывается по-разному в процессе разработки. Простейший пример: тестировщик написал Change Request, а программист, не разобравшись, принялся воплощать изменения, считая их задачей…
9. Прежде чем описывать баг или задачу, попытайся написать ее так, чтобы она была понятна всем, в том числе и твоей маме, которая опасается компьютера. Представь себе, что эту задачу назначут твоему коллеге. Представь себе, что он будет ее читать в конце рабочего дня, сильной уставшим. В кого полетит первый камень с вопросом «Ты тут вообще о чем пишешь?»
10. Если возможно, указывай не только то, что надо сделать, но и причину по которой это надо сделать. Это поможет понять приоритетность задачи. Иногда это не очевидно, или очевидно, но не всем.
11. Не используй Mantis как personal task list. Он не для того предназначен.
12. Указывай версию софта, в которой была обнаружена проблема, и указывай версию, в которой это проблема была/будет решена.
13. Есть глубокий смысл в том, чтобы акаунты уровня Developer и Tester (по-умолчанию роли тестировщика в Mantis нет) были лишены возможности ставить статус Closed. Принципиально это должен делать менеджер проекта. Менеджер должен получать прошедшую весь девелоперский цикл задачу только в статусе Tested.
14. Администратор должен всячески связать Mantis с существующей в компании subversion-системой, как бы она ни называлась. В крайнем случае, следует добавить новый цифровой Custom Field, который будет являться обязательным для заполнени при переводе issue в статус Resolved.

Подробная схема работы с Mantis

Разруливание багов через Mantis

На картинке весьма подробная, но все-таки принципиальная схема.

Подобные схемы разнятся от конторы к конторе, но это именно «принципиальный подход».

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

Управление проектом через Mantis

Это фантастика. Дело в том, что Mantis сделан для разработчиков, и вовсе не предназначался для раздачи задач и составления графиков успеваемости.

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

Однако некоторые товарищи умудряются прикрутить к Mantis систему учета времени, которое было затрачено бравыми разработчиками на решение существующих проблем.

Второе и последнее обращение к нации

Итак, Mantis это инструмент для разработчиков.

Записи в подобной системе помогают основательно сказать «Эта проблема была решена еще в пятницу, 13-го числа — смотри логи, я там оставил комментарий о том, что изменения в коде зачекинены в ревизии 1478…»

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

Записи в подобной системе помогают не упустить из виду какие-то проблемы и/или задачи, не забыть и не спрятать.

Дефолтный пароль администратора при первой установке Mantis:

Username: administrator

Password: root

Все вышесказанное относится к работе с баг-трекеров В ПРИНЦИПЕ, а не только к Mantis в частности.