Разруливаем баги в Mantis

Автор: | 24.06.2009

Обращение к нации

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

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

Для этого используются системы управления дефектами вроде “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 систему учета времени, которое было затрачено бравыми разработчиками на решение существующих проблем.

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

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

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

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

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

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

Username: administrator

Password: root

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

Разруливаем баги в Mantis: 18 комментариев

  1. Dmitro Podzyvalovsky

    Отличная инструкция (просто и емко). Мне, правда, чаще приходится пользоваться JIRA, чем мантисом, но именно тем товарищам, с которыми я использую Mantis чаще приходится объяснять что это за штука и зачем она нужна.

  2. Сергей

    Если на исправление дефекта нужно менее 10 секунд, но нужно не забыть это исправление протестировать в своё время, то как поступать, куда это записывается?

  3. Алексей Лупан

    Надежнее всего – в мантис. Назначить задачу на свое имя. Указать релиз или еще и билд, в котором надо будет к этому вопросу вернуться. И в нужное время действительно к нему вернуться.
    Если есть время указать какие-то подробности вроде “как воспроизвести” – это только плюс, ведь задачу можно будет кому-то передать, и рассчитывать на ее адекватное воспроизведение.
    Скорость исправления дефекта и его значимость не пропорциональны 🙂

  4. makeenkoov

    Принципиально это переводится как «предмет спора, разногласие, проблема». Обычно это переводят как «Задача».
    я бы перевёл это как отчёт, ведь по сути своей в Mantis’е хранятся отчёты о багах или дополнениях с описанием и условиями….
    Не надо вписывать баг как комментарий к задаче – надо сделать новое issue. Иначе потом будет очень сложно «управлять багами», и будет сложно понять, сколько багов было найдено, и сложно объяснять, что «это задача, и она сделана, но в комментариях есть баг, и он не починен». Все задачи, которые связаны между собой, можно слегко «линковать» посредством поля Relationships.
    именно поэтому и нужно заносить даже
    если на его починку нужно больше, чем десять секунд.
    ибо при проверки таких мелких решённых багов можно наткнуться на куда более глобальную проблему, по моему даже самый маленький баг(будем говорить отчёт) занесённый в трекер является при проверке тест-кейсом
    кстати в свежих мантисах есть кроме «Relationships» ещё и тэги, тоже ооочень удобная доработка
    Прежде чем описывать баг или задачу, попытайся написать ее так, чтобы она была понятна всем, в том числе и твоей маме, которая опасается компьютера. Представь себе, что эту задачу назначут твоему коллеге. Представь себе, что он будет ее читать в конце рабочего дня, сильной уставшим. В кого полетит первый камень с вопросом «Ты тут вообще о чем пишешь?»
    описывать нужно и потому, что баг может проверять после решения новичок или сотрудник который болел при работе с тем или иным функционалом и следовательно не узнал это функционал
    Есть глубокий смысл в том, чтобы акаунты уровня Developer и Tester (по-умолчанию роли тестировщика в Mantis нет) были лишены возможности ставить статус Closed. Принципиально это должен делать менеджер проекта. Менеджер должен получать прошедшую весь девелоперский цикл задачу только в статусе Tested.
    тут не соглашусь… зачем же менеджеру закрывать проверенные после решения отчёты?!

  5. Алексей Лупан

    «Задача».»
    я бы перевёл это как отчёт

    “Добавить новый отчет” – звучит?
    зачем же менеджеру закрывать проверенные после решения отчёты?!
    Затем, что состояние релиза оценивается по состоянию все еще открытых задача. “Отчетов”. Когда они все закрыты, релиз объявляется “вышедшим”. Иначе подразумевается, что по нему еще надо сделать какие-то работы.

  6. makeenkov

    “Создать отчёт” так звучит, по дефолту в Мантисе “Создать вопрос”….
    у нас есть роадмэп по которому можно судить о состоянии проекта… когда все отчёты по проекту в статусе закрыт, т.е. тестировщик все отчёты проверили и закрыли, значит проект готов к сдачи!

  7. Уведомление: Тонкая настройка ‘Workflow Transitions в Mantis « QA – грамотно

  8. Виктор

    Не могу понять почему при создании инцидента (issue) никак не получается выбрать тип наподобие “Feature Request”, “Change Request”, “Bug”, “Information”, как у вас написано. Что я не так делаю?

  9. Виктор

    Администратор… Но я завел тестового с правами “инициатор”. Похоже я наверное что-то не понимаю в системе статусов и прав?

  10. Виктор

    Администратор… Но я завел тестового с правами “инициатор”. Похоже я наверное что-то не понимаю в системе статусов и прав?

  11. Алексей Лупан

    Инициатор – лох бесправный по-умолчанию.
    http://mantis/manage_config_work_threshold_page.php – тут уточняется, кто на что имеет право.

  12. Виктор

    Да дело не в этом. Я попробовал уже других… Дело в том что при создании issue я (администратор, редактор, и т.д.) не могу задать тип. Хотелось бы отделить баги от фича-реквестов… Или это нельзя сделать в Mantis?

  13. Виктор

    Ммм… версия 1.2.3

  14. Алексей Лупан

    Вы хотите, чтобы происходило как в Jira – там сперва уточняется, какое дело вы хотите создать, а потом открывается соответствующий шаблон?
    Mantis по-умолчанию является баг–трекером, который может стать issue-трекером (вот в чем его сила).
    Вам следует добавить дополнительное поле, которое будет определять, что за issue мы создаем. Оно будет отображаться на страницах, а также в общем фильтре на странице View Issues.
    1)
    Если это поле нужно во всех проектах, которые будут появляться в системе, то сперва убедитесь в правом верхнем углу, что вы находитесь в “All projects”. Иначе изменение будет относиться только к проекту, в котором вы находитесь в данный момент.
    2)
    Перейдите на http://mantis/manage_custom_field_page.php – страница “Manage Custom Fields”.
    3)
    Создадите новое поле:

    • Name: Task type (назовите как угодно)
    • Type: Enumeration
    • Possible Values: Task|Bug|New feature (ваше решение)
    • Default Value: Task (будет появляться по-умолчанию в выпадающем списке – ставите то, что хотите из поля “Possible Values”)
    • Add to Filter: + (то есть, ставим галочку)
    • Display When Reporting Issues: +
    • Required On Report: +

    Сохраните изменения.
    4)
    Теперь при открытии нового issue будете выбирать из выпадающего списка нужное значение.
    А потом сортировать в фильтре – что задачи, а что – баги.

  15. Виктор

    Вот теперь понял!!! ОГРОМНОЕ СПАСИБО!!! 🙂

  16. Alex

    Обзор хороший но слишком поверхностный.
    Интересует более углубленное использование Мантиса в работе.
    Например поддерживается ли управление инциндентами и проектами по API работающее через email, так как это организованно в ServiceDesk?

Добавить комментарий

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.