Отправляет email-рассылки с помощью сервиса Sendsay

Записки бизнес аналитика

Рассылка закрыта

При закрытии подписчики были переданы в рассылку "О карьере и профессиональном развитии IT-специалистов" на которую и рекомендуем вам подписаться.

Вы можете найти рассылки сходной тематики в Каталоге рассылок.

←   Июль 2004   →
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
Автор sla***@p*****.ua

Статистика

2.701 подписчиков
+9 за неделю
←   Все выпуски   →

Записки тестировщика 'JIRA - багтрекер для широкого круга задач.'


Информационный Канал Subscribe.Ru
Записки тестировщика 'JIRA - багтрекер для широкого круга задач.' // выпуск 11 // 2004-07-15


"JIRA – багтрекер для широкого круга задач." | к списку статей
О различных багтракерах, их преимуществах и недостатках писалось много. Сравнения которые проводятся между "открытыми" (бесплатными) проектами и их платными конкурентами, ничего кроме тоски и пережёвывания одной и той же мысли – "Вы платите за поддержку!" – ничего нового не несут. Я обратил внимание, что зачастую багтрекер выбирается совершенно не отталкиваясь от нужд тех, кто им в первую очередь будет пользоваться, а это безусловно тестировщики и разработчики. Ситуация в целом распространённая, зачастую технические и программные решения, сопровождающие жизненный цикл разработки ПО, выбираются по ценовым характеристикам ("у нас есть денег только на это", либо наоборот: "это дороже, берём это"), тут не одни багтрекеры в таком положении. Я не буду проводить глубоких исследований на тему как правильно выбирать багтрекеры, в конечном итоге каждый будет решать для себя, я расскажу, что использую в своей работе и почему для нужд моей команды оно подходит.

Atlassian JIRA (http://www.atlassian.com/software/jira/) – система чуть более широкая, чем только багтрекер, это Issue Tracking system – то есть система трекинга сообщений как таковых. Система имеет веб-интерфейс, монтируется без особых трудностей (наши администраторы проблем в установке и настройке бекап/рестора не нашли), очень гибко настраивается под конкретный проект. Платная (30 полнофунциональный триал), но денег своих стоит. Очень постараюсь не "свалиться" в сравнения с другими подобными системами, но не обещаю.

Что умеет создавать:
Сообщения с определённым (управляемым администратором) набором полей, в том числе, такими распространёнными как: тип (ошибка, предложение, задание – список расширяем) ; responsibility (Assignie) – ответственный, получатель сообщения; приоритет; воспроизводимость; компоненты (очень удобная штука, если проект состоит из нескольких модулей или подсистем); версия в которой создаётся сообщение (affected version); версия в которой сообщение будет снова иметь силу (fixed version) – словом, стандартный набор полей для багтрекера. Стандартный, но при этом расширяемый для каждого проекта. То есть система ведёт несколько проектов с непересекающейся версионностью и своим уникальным набором полей.

Как происходит трекинг:
Создаваясь, сообщение обязательно имеет Assignie – ответственного, адресата (если такового не указать система в зависимости от настроек конкретного проекта либо автоматом "направит" сообщение, то есть адресует его, лидеру проекта (указывается при создании проекта), либо укажет необходимость выбрать адресата, если проект настроен так, чтобы сообщения не могли быть безадресными. "Получатель" может перенаправить его далее или вернуть писавшему ("петля разработчик-тестировщик").

Каждому Issue можно поставить приоритет важности, адресовать на себя, добавить комментарий. При чём как общий комментарий, видимый всеми, так и комментарий направленный одному человеку – очень приятная фишка, когда ведущий разработчик переадресует сообщение своему коллеге, указывая какую-то техническую подробность, которая нужна только ему (все наверное видели эти потрясающие комментарии в багтрекерах состоящие из кусков кода, осень полезная вещь, к примеру UI тестировщику).

Сообщения можно установить статус IN PROGRESS – в начале работы над ним, и соответственно указав, когда работы над ним закончены.
Особо хочется указать на работу с версиями и статусами с точки зрения просмотра списков сообщений. Система поддерживает возможность создания персонифицированных

Аттачи:
Небольшое приятное дополнение к опции "Attach Files", особо нужное если работаешь под "голой" операционкой, на которой нет средств редактирования и сохранения изображений (или как в случае с маком – такие средства есть, но пользоваться ими вин-пользователю неудобно жутко, да кроме того потом нужно ещё суметь достучаться по сети до сетевого ресурса, с которого потом этот файл можно будет приаатачить к сообщению об ошибке) – опция "Attach screenshot". Аттачить скриншоты, то есть буквально то, что на данный момент снято в буфер обмена, можно прямо в JIRA, с помощью небольшого java апплета, который отлично работает и под вин-системами и под маком. Согласитесь, удобно.

Аттачить можно не только картинки, но и доугие форматы файлов, однако если аттачить gif, jpg или bmp JIRA сама при просмотре сообщения сделать для них превьюшки. Это просто и удобно, ведь никто не гарантирует, что разработчик просматривая это сообщение будет иметь под что-то, кроме браузера.

Пользователи:
Аккаунты пользователей управляются как администратором, так и самим пользователем. Пользователи могут быть объединены в группы – то есть совершенно привычная структура. При чём как отдельному пользователю так и группе можно запретить/разрешить одно вполне конкретное действие (к примеру такая экзотика, как запрет на удаление аттачей и создание комментариев для менеджеров из других проектов).

Безопасность:
Умеет создавать и вести "схемы безопасности" для каждого из проектов. То есть можем создать группу пользователей на конкретный проект, раздать на этот же проект права, или использовать стандартную схему безопасности на этот проект.

Оповещение:
Как узнают пользователи о том, что их сообщение было отредактировано, или о том, что им адресовано новое сообщение. По аналогии со "схемами безопасности" каждому проекту может быть создана "схема оповещения", в которой указывается на какое событие как должна реагировать система оповещения, которая рассылает почтовые сообщения. К примеру хочется получать сообщения не только если сообщение направлено непосредственно вам, хочется отслеживать своё сообщение. Или к примеру мне, как ведущему тестировщику, нужно видеть все создаваемые моей командой сообщения об ошибках – при этом видеть не просматривая все проекты, которые в данный момент активны, отыскивая созданные сообщения, а прямо из почтового клиента перейти к сообщению, чтобы внести нужные изменения. Схемы оповещений могут быть расширены к примеру в следующем ключе: обо всех сообщениях, которые приходят на определённый проект, должны быть поставлены в известность ведущий разработчик этого проекта и ведущий тестировщик. Для схем оповещений JIRA это реализуется без "танцев с бубном" и глубокого администрирования почтовой системы организации.

Чем JIRA подходит нам:
У нас много проектов и команда тестирования работает одновременно с несколькими проектами и командами разработки. Кроме этого, мы работаем под несколькими типами операционных систем, в том числе и такой недружелюбной для тестирования как MAC OS. Особые правила обработки сообщений и оповещений для различных проектов, свободно уживаются в JIRA, не конфликтуя и давая возможность гибко ими управлять. Об удобстве работы с аттачами из под различных тестовых окружений, я писал выше. Различаются и требования к схемам оповещения и политики доступа и безопасности – со всем этим JIRA справляется легко, и как-то естественно. Чувствуется, что людям, которые принимали участие в её проектировании приходилось работать в нашем режиме.

Выводы:
Нужно пробовать, особенно если вы сейчас в процессе поиска и выбора багтрекера. Если же нет – просто познакомьтесь с этой системой поближе, возможно откатайте на ней "пилотный" проект. Вам понравится эта гибкость и надёжность.
С уважением, Панкратов Вячеслав. Записки тестировщика.
http://subscribe.ru/
E-mail: ask@subscribe.ru		 Адрес подписки
 Отписаться
В избранное