Study & DevО программировании и не только

Mantis. Охотник на BUG-и. Часть 2

Я продолжаю и завершаю рассказ об Mantis – популярном средстве управления проектом разработки программного обеспечения. Сфера компетенции mantis – это ведение единой базы данных, в которой хранится вся история разработки проекта, список всех выданных заданий (как багов так и фич). Каждому заданию соответствует карточка учета, благодаря которой всегда можно узнать, как и кем было выдано задание, кто отвечал за его реализацию, кто проверил качество выполнения работы и завизировал ее. К каждому заданию присоединен список связанных артефактов: файлов с примерами тестовых данных, скриншоты, записи о том какие файлы в CVS/SVN были изменены в ходе реализации задания.

В прошлый раз я закончил рассказ на том, что показал то, как инсталлировать mantis, как создать набор учетных записей (для разработчиков, тестеров, менеджеров проекта). Затем мы создали проект, состоящий из некоторого количества модулей; запланировали версии проекта и назначили для проекта исполнителей. После всех этих подготовительных шагов начинается, собственно, работа: мы созданием задания и назначаем для них исполнителей. Новая задача регистрируется с помощью меню “Report Issue”. В первом диалоговом экране нужно выбрать в падающем списке, то для какого проекта создается задание. В следующем диалоговом окне (см. рис. 1)



мы указываем характеристики задания. Первым шагом мы выбираем категорию, к которой относится создаваемое задание (этот список был определен при создании проекта в прошлой статье). Затем мы выбираем “Reproducibility”. Этот параметр имеет смысл только для сообщений об багах т.е. как часто воспроизводится обнаруженная ошибка (always, sometimes, random, have not tried, unable to reproduce). Следующие две характеристики задания рассматриваются вместе и определяют приоритет задания. Условно говоря, разработчик, приходя утром на работу, просматривает список заданий и перед выполнением сортирует их в соответствии с приоритетом. Во-первых, на приоритет влияет параметр “Severity” (степень опасности). “Severity” может принять как значение feature (добавление к проекту новой функции), так и значения, кодирующие степень опасности ошибки, начиная от minor до block, т.е. ошибки настолько серьезной, что использование приложения не возможно. Второй параметр, определяющей приоритет выполнения задания, так и называется “Priority” и принимает значения “none”, “low”, “high”, “urgent”, “immediate”. Затем нужно с помощью падающего списка “Product Version” указать версию проекта, для которой была найдена ошибка или для которой нужно реализовать feature. Некоторым недостатком является то, что мы не можем выбрать несколько значений версий сразу. Это бывает нужным в том, случае если ошибка была найдена сразу в нескольких версий проекта. С другой стороны, заведение отдельных issue для одного и того же бага, но в различных версиях проекта, имеет свой смысл. Поскольку заниматься исправлением и последующей проверкой работы могут различные люди, изменения в cvs также будут отличны. Следующие параметры issue – это “Summary” или краткое однострочное описание задания. Для более подробных характеристик задания используется поле “Additional Information”. Завершается создания нового issue тем, что мы можем приложить к issue произвольный файл, например, фрагмент журнала работы приложения с текстом ошибок или копию экрана, демонстрирующую найденный баг. В самом верху формы регистрации ошибки находится ссылка “Advanced Report”, показывающая для создаваемого issue ряд дополнительных полей. Так, если вы сообщаете о найденной ошибке, то обязательно указать сведения об окружении, для которого была найдена ошибка, т.е. операционную систему, ее версию, список установленного программного обеспечения - подобные сведения носят название “профиля”. В прошлой статье серии я уже упоминал о профилях, когда мы создавали учетные записи пользователей. Тогда я говорил, что каждому человеку из команды тестеров можно поставить в соответствии профиль его программного обеспечения. Таким образом, при регистрации бага, тестер может выбрать из падающего списка на странице “Advanced report” свой профиль. Если же ни один из зарегистрированных профилей не подходит, то на форме “Advanced report” есть поля “Platform”, “OS”, “OS Version”. Еще из новых полей, которых не было на форме “Simple report”, интерес вызывает графа “Steps To Reproduce ”. В это текстовое поле тестер должен ввести четкую пронумерованную последовательность тех шагов, которые нужно повторить разработчику, чтобы воспроизвести на своем компьютере ошибку. Особое внимание нужно обратить на поле “Product Build”. Типовой цикл разработки проекта выглядит следующим образом: менеджеры проекта создают задания на реализацию новых функций приложения (feature), программисты, реализуя эти задания, естественно, допускают ошибки. Закрывая “фичу”, тестеры проверяют качество ее реализации и если были найдены ошибки, то заводят в mantis баги. Для того, баг “не потерялся во времени” нужно четко указать версию продукта, для которой баг был найден. Традиционно, нумерация версий состоит из двух частей: первая из них - “внешняя” это то, что видит массовый пользователь, например, office 2003 или 2007. Вторая часть версии продукта известна только разработчикам проекта или “опытным” пользователям, например, word в котором я пишу эти строки, имеет версию “11.0” и сборку “6359”. Это значит, что в ходе разработки office было выполнено 6359 сборок проекта. Т.е. то, что делали разработчики индивидуально, было собрано в единую полнофункциональную версию, которую в последствии и проверяли тестеры. И когда тестеры регистрируют ошибку, то обязательно указывают номер билда (сборки) для которой ошибка проявляется. Впоследствии, когда программист исправил ошибку, то он закрывает в mantis баг, указывая при этом то какие файлы были изменены в cvs. Затем после окончания рабочего дня, на специальном build intergration server-е запускается сборка проекта, которая включает в себя все внесенные за текущий день изменения проекта. Каждая сборка имеет свой номер билда и именно на этом номере билда проверяются и закрываются за баги переведенные в состояние “готово, нужно проверить”. Последнее поле, которое заполняется при регистрации в mantis бага – это “Assign To”. Т.е мы выбираем в падающем списке того сотрудника, кто будет ответственен за исправление ошибок (пользователь должен обладать правами developer, manager или administrator). Жизненный цикл задания в базе mantis построен вокруг состояний, в которых issue может находиться и действиях разработчиков, переводящих задание из одного состояния в другое. Так сразу после создания задания оно находится в состоянии “New”. Следующим состоянием является “Acknowledged” (признан). Именно в это состояние переводится задание, после того как команда разработчиков согласилась с тем, что созданное issue является верным. Состояние “confirmed” говорит о том, что обнаруженная командной тестеров ошибка была воспроизведена разработчиками. Затем ошибка переходит в состояние “assigned” т.е. был назначен ответственный сотрудник, который сейчас и работает над исправлением бага или реализацией feature. Статус “resolved” говорит о том, что задание было реализовано и должно быть подтверждено и завизировано командой тестеров. Если же тестеры обнаруживают ошибку в реализации задания, то они переводят задачу в состояние “feedback”. Последним состоянием для задания является “closed” т.е. задача была реализована и проверена. В случае если состояния, предлагаемые mantis по-умолчанию, кажутся вам лишними, то в этом нет ничего страшного. Так в моей практике жизненный цикл задания не включал в себя состояния “acknowledged” и “ confirmed”. Гораздо хуже если вам потребуются новые состояния задач. Можно попытаться имитировать недостающую функциональность с помощью тегов или пользовательских полей. В крайнем случае, нужно просмотреть форумы mantis (http://www.mantisbt.org/): вдруг кто-то уже реализовал что-то похожее на нужную вам функциональность.

После того как новая “issue” была создана, вы можете с помощью меню “View Issues” перейти на страницу с карточкой задания. Карточка не только содержит все поля, которые вы заполняли при создании задания, но есть ряд новых полезных параметров (см. рис. 2).



В самом верху карточки задачи вы видите ее приоритет, статус, дату создания и последнего обновления задания. Там же вы можете просмотреть и загрузить себе на компьютер любой из файлов, приложенных к заданию (там же можно добавлять или удалять файлы). Полезной характеристикой задания является список ключевых слов или тегов, присоединенных к задаче (в последствии вы можете выполнять поиск задач по ключевым словам). После таблицы с перечислением характеристик задания находится набор кнопок позволяющих управлять заданием: назначить на пользователя, изменить статус задания с “opened” на “closed” или “resolved”. Нажав кнопку “Monitor issue” текущий пользователь становится наблюдателем задания, т.е. при любых изменениях карточки задания, mantis будет выполнять рассылку электронных писем не только пользователям, которые были назначены как ответственные за задание, но и тем, кто подписался на “Monitor issue”. Так на рис. 3



показано то, как выглядит письмо, сообщающее о том, что вам назначили задание. После того как вы стали “наблюдателем” задания, вы можете в любой момент времени отказаться от наблюдения с помощью кнопки “End monitoring”. Кнопка “Create Clone” служит для создания новой issue как копии выделенной. Для того, чтобы переместить созданную issue из одного проекта в другой используйте кнопку “Move issue”. Последняя функция – удаление issue (в практике лучше никогда не удалять задания, а помечать их, например, тегом “invalid”). Одна из самых полезных функций, которые есть в mantis – это возможность связывать созданные карточки заданий между собой с помощью отношений “parent of” и “child of” (т.е. задания образуют иерархию “главный и подчиненный”). Для того, чтобы указать то, что два задания просто связаны между собой используется отношение “related to”. Т.к. часто бывает так, что создаваемые запросы на исправление багов могут дублироваться, то полезным является использование отношений “duplicate of” и “has duplicate”. К каждому из заданий присоединяется список заметок (notes), эти заметки служат для того, чтобы комментировать, задавать вопросы, обсуждать задание. В самом низу карточки задания находится таблица истории правок. В этой таблице отражаются абсолютно все действия, выполняемые с заданием: изменение статуса, добавление примечаний, загрузка и удаление attachment-файлов. Создавая новое задание, менеджер проекта может подписать ряд сотрудников за наблюдение за ходом решения задачи, это бывает полезным в том, случае если результат работы одного сотрудника может оказать косвенное влияние на работу другого. Чуть выше я упомянул об механизм наблюдения или monitoring-а за заданием, но тот подход требовал, чтобы заинтересованный сотрудник сам открыл карточку задания и нажал кнопку “Monitor issue”, что не всегда удобно. Гораздо лучше подход, когда менеджер проекта, создав issue, нажимает кнопку “Send a reminder”, а затем в появившемся диалоговом окне выбирает тех сотрудников, которым будет разослано письмо с некоторым текстом сообщения. Что более важно, так это кроме получения письма, сотрудники автоматически становятся наблюдателями над заданием, и будут получать письма всякий раз, когда состояние issue изменяется. Для настройки того, какие события в жизненном цикле задания проводят к рассылке писем, администратор mantis может воспользоваться меню “Manage” -> “Manage configuration” -> “E-mail Notifications”. Еще одним средством наблюдения за состоянием проекта является использование RSS. Так любой пользователь, зайдя в mantis видит в заголовке страницы иконку “RSS”, нажав на которую вы можете импортировать в свой любимый “чтец новостей” еще и новостную ленту mantis.

Созданная база заданий может быть очень-очень большой и это ставит перед нами потребность получить удобный инструмент поиска заданий по различным критериям. В самом простом случае, после того как сотрудник заходит в mantis то видит перед собой персональную страницу, где выводятся сведения о issue, которые были им созданы, назначены или находятся в списке наблюдения (см. рис. 4).



Такой же экран с перечнем актуальных заданий можно увидеть, выбрав пункт меню “My view”. Возвращаясь к задаче поиска issue с помощью фильтров, обратите внимание на меню “View issues”. На появившейся странице вы в самом низу видите табличку с перечнем всех issue, которые зарегистрированы в базе mantis. Для каждой строки таблицы поставлен в соответствии checkbox. Отметив несколько issue, вы можете для всех них выполнить любое из следующих действий: “Move”, “Copy”, “Assign”, “Close”, “Delete”, “Resolve”, также вы можете изменить для задания приоритет, статус, категорию и уровень доступа. Естественно, что искать issue, последовательно пролистывая страницы таблицы, крайне не удобно – а значит нужно воспользоваться одним из множества фильтров расположенных в самом верху страницы “View issues”. Самый простой способ поиска – ввести какое-либо слово в графу “Search”; затем mantis найдет для нас все issue, в названии или комментарии к которым содержится искомое слово. Следующий режим поиска позволяет наложить фильтр почти на все характеристики, которые только есть в карточке задания (см. рис. 5).



И “последним” средством поиска является расположенное сразу под строкой меню текстовое поле “Issue #”. Если внести в это поле номер issue (каждое задание после создания автоматически получает уникальный номер), то вы перейдете на страницу с карточкой задания под указанным номером. Для того, чтобы можно было с высоты “орлиного полета” окинуть взглядом состояние проекта, соотношение количества открытых и закрытых заданий рекомендую использовать меню “Summary”.

На этом я заканчиваю рассказ об mantis. Конечно, объем двух статей, изобильно сдобренных картинками, не может претендовать на роль справочника. Главное другое – я надеюсь, что каждый прочитавший эту серию статей, будет видеть не рассказ об mantis самой по себе. А, прежде всего, рассказ о возможности внести порядок в процесс разработки программного обеспечения, создать единую базу, в которой будут регистрироваться все возникающие в ходе работы задания и история их разрешения.

« Mantis. Охотник на BUG-и. Часть 1

Управление сборкой проектов вместе с teamcity. Часть 1 »