Трекер должен работать быстро, очень быстро, еще быстрее « QA

Трекер должен работать быстро, очень быстро, еще быстрее

3, Июнь 2008 автора Алексей Лупан

Когда-то Udaleator рассказывал мне о том, что в разработке важны буквально все мелочи, которые окружают разработчика. Вплоть до покрытия пола, по котором человек перемещается на кресле от одного стола к другому. Не скажу, что не был впечатлен, но до конца все это не осознавал.

Теперь я проповедую то же самое, особенно в отношении рабочего инструмента “багтрекер”. С точки зрения тестировщика у меня сложилось особое требование к подобному инструменту – быть удобным и скоростным при заведении баг-репортов.

Возможно, вопросы скорости работы багтрекера кажутся надуманными, но меня эта “надуманная” проблема иногда приводила к тому, что все баг-репорты, найденные в течение тестовой сессии, я записывал в Блокнот, и только ближе к вечеру начинал выкладывать все на трекер.

Даже обоснование этой задержке нашел – во время вечерного “занесения” описания багов волей-неволей пересматриваются, и уточняются, и от этого, мол, даже лучше… Это обоснование ошибочно.

Вот сквозь призму скорости заведения баг-репортов и поговорим о трех “ходовых” багтрекерах – Mantis, Bugzilla, Jira.

Мне также доводилось работать с трекерами типа Microsoft SharePoint Service (SPS) и CollabNet Enterprise Edition, но их в этом обзоре не будет.

Понаехали!

Mantis

Доступ к демо-версии: guestqa/guestqa

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

Краткое описание

Mantis — свободно распространяемая система отслеживания ошибок в программных продуктах (bugtracker).

Обеспечивает взаимодействие разработчиков с пользователями (тестировщиками).

Позволяет пользователям заводить сообщения об ошибках и отслеживать дальнейший процесс работы над ними со стороны разработчиков.

Имеет гибкие возможности конфигурирования, что позволяет настраивать её не только для работы над программными продуктами, но и в качестве системы учёта заявок.

Построена по принципу “клиент-сервер”, поэтому не требует для работы установки специального ПО и работает через веб-браузер.

Разработана программистами для программистов. Изрядно допускает копание в своём коде и его переиначивание под свои нужды.

Скорость занесения нового баг-репорта

Весьма высокая.

Средний отклик страницы с рассматриваемого демо-сервера равен трем секундам. Время открытия страницы с полями для занесения баг-репорта с рассматриваемого демо-сервера – 2 секунды.

Имею большой опыт работы с подобным трекером – страница для заполнения нового баг-репорта открывалась за полторы секунды.

Кликнуть по линку [Report Issue].

Если в настройках не указано, какой проект является дефолтным для пользователя, то сперва открывается страница “Выбрать проект”. Если проект уже указан, вопрос не появляется.

Большой плюс – линк на [Report Issue] един во все времена – bug_report_advanced_page.php Его можно занести в закладки, и вызывать его посредством короткого имени вроде “1″.

Подсказка: как вызывать страницы посредством “кейворда” закладки

Для этого в настройках закладки в поле Keyword следует прописать цифру “1″, и в дальнейшем для ее открытия потребуется три нажатия клавиш:

“F6″ для фокуса на адресной строке
“1″ – появляется в адресной строке.
“Enter” на клавиатуре.

Это намного быстрее, нежели ерзанье курсора мыши по экрану и его прицел на нужную вкладку.

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

Продолжим.

Открывается страница с полями для записи всех аттрибутов бага.

Можно сразу записать все, что нужно, в поле Description, и лишь потом указать степень важности бага, его заголовок, версию продукта, платформу и все такое прочее.

В случае, если это issue является не багом, а task или feature request, все это также можно указать ПОСЛЕ того, как записан основной текст.

Обязательных для заполнения полей только три – Category, Summary, Description.

Указать файл со скриншотом.

Минус Mantis – при занесении одного бага можно указать только один скриншот. Второй-третий придется указывать только после того, как баг-репорт будет опубликован в системе. Минус немного уменьшается за счет того, что после публикации бага открывается его “full-preview”, в котором можно добавлять новые скриншоты. Но тоже по одному.

Переходим в режим просмотра issue.

Подсказка: как очень быстро указать в багтрекере файл со скриншотом

Для этого нужно в Total Commander (или в Krusader) настроить сочетание клавиш на команду “Копировать полный путь и имя файла в буфер обмена” – для меня удобным оказалось сочетание “Alt+2″.

Полученный набор символов надо просто вставить в поле, которое обычно заполняется после манипуляций с кнопкой “Обзор”.

В Krusader нужная команда называется “Copy current item to clipboard“. Ее настройка вызывается через меню Settings – Configure Shortcuts.

В Total Commander нужная команда называется “cm_CopyFullNamesToClip“.

Ревью багов

Весьма быстрое и удобное.

Что ценно – у каждого issue есть собственный линк, который можно переслать в письме или по мессенджеру.

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

Из каждого issue можно послать уведомление другому девелоперу или другу народов.

Отчеты

В Mantis нет чего-то, что называется “Сгенерировать отчет о ходе проекта”. Система сделана разработчиками для разработчиков, а не для менеджеров.

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

Поиск багов – фильтрация

Весьма, весьма мощная и продуманная система фильтрации.

Общая оценка

Я хочу работать с этим багтрекером!

+10 из 10!