Система отслеживания ошибок jira

Уровень сложности
Простой

Время на прочтение
3 мин

Количество просмотров 3.1K

Чтобы написать bug report(отчет об ошибке) в Jira необходимо выполнить несколько действий, которые ты узнаешь на примере «боевой» жиры. Уверен, что общую концепцию поймешь.

Далее ты узнаешь:

• Что такое Jira?

• Шаги для составления баг репорта

Что такое Jira?

Jira — это система управления проектами и отслеживания задач, которая используется командами разработки программного обеспечения.

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

Jira помогает командам разработки эффективно управлять проектами и обеспечивать успешную доставку программного обеспечения.

Шаги для составления баг репорта:

1). Перейдите в Jira и нажмите кнопку «Создать».

2). Выберите тип проблемы «Ошибка» из списка вариантов.

3). Заполните поле сводки кратким описанием проблемы(summary), например такой шаблон: «путь до бага» — «какая проблема?», «когда?», «где?». Заголовок можно по разному строить.

4). В поле описания предоставьте подробное объяснение проблемы, и любые отображаемые сообщения об ошибках, например добавить логи и/или веб сокеты. Также можно прикрепить видео, скрины и другие файлы с необходимой информацией. Тут же можно указать окружение, где воспроизвелось или в ином специальном поле.

5). Напишите шаги для воспроизведения в специальное поле. Рекомендую в виде пронумерованного списка.

6). Прикрепите к проблеме любые соответствующие файлы, например снимки экрана и/или файлы журнала(логи, иные файлы), возможно еще какие либо ярлыки, компоненты.

7). Установите уровень приоритета проблемы в зависимости от серьезности ошибки и срочности ее исправления.

8.) По серьезности (Severity) бага в большинстве случаев, на практике, остаются пустым, по моему опыту, потому что тут разрабу виднее и то даже они часто оставляют это поле пустым.

9.) Назначьте проблему на разработчика или на другого члена команды, ответственному за дальнейшую судьбу ошибки (поле Assignee) на определенном этапе её решения.

Данный пункт, также зависит от договоренности внутри команды, потому что бывает данное поле остается пустым или назначается аналитик, PM, или сразу разработчик. В моем опыте было так, что я мог сразу бывает так, что несколько пр в сборку попало разработчика или аналитика(было, что человек был лицом совмещающий PM, PO и должность аналитика), а было назначаешь только менеджера или вообще пусто.

Заполните поле сводки кратким описанием проблемы.

10). Добавить информацию о спринте, также ниже версию приложения, где был найден баг и в какой версии будет исправляться он, если это известно. Чаще всего этот вопрос решает аналитик, поэтому у него можно уточнить.

Указывать номер билда и/или commit hash — НЕ обязательно. Тут не особо принципиально, потому что если в девелопе, то следующие билды тоже будут с багой. По хэшу коммита, а если их несколько в таске? Вряд ли угадаешь в каком косяк. Еще бывает так, что несколько PR в сборку попало. Данное требование может возникнуть в редких случаях, например удаленно надо подебажить разрабу. Но так не всегда. Тут скорее зависит от разработчика, потому что кому-то реально проще подебажить и найти по коммиту место, где поломалось.

11.) Можно установить связь с другой задачей, если такова имеется и присутствует необходимость, например можно установить связь с таской, которую тестировали и в ней нашли баг.

12). Нажмите кнопку «Создать», чтобы отправить отчет об ошибке.

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

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

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

From Wikipedia, the free encyclopedia

Developer(s)	Atlassian[1]
Initial release	2002; 21 years ago[2]
Stable release	9.6 (24 January 2023; 7 months ago[3]) [±]
Written in	Java
Operating system	Cross-platform
Type	Bug tracking system, project management software
License	Proprietary
Website	www.atlassian.com/software/jira

Jira ( JEE-rə)^[4] is a proprietary issue tracking product developed by Atlassian that allows bug tracking and agile project management.

Naming[edit]

The product name comes from the second and third syllables of the Japanese word pronounced as Gojira, which is Japanese for Godzilla.^[5] The name originated from a nickname Atlassian developers used to refer to Bugzilla, which was previously used internally for bug-tracking.^[5]

Description[edit]

JIRA was an open source tool available for anyone to download. Its popularity drove thousands of users to adopt it within organizations across the globe. Unlike IBM Engineering Management Platform, the tool is primarily for use in small teams and individuals, not large projects or enterprises. Subsequently, the product was taken off of open-source servers somehow. Atlassian created a business around this product.
According to Atlassian, Jira is used for issue tracking and project management.^[6] Some of the organizations that have used Jira at some point in time for bug-tracking and project management include Fedora Commons,^[7] Hibernate,^[8] and the Apache Software Foundation, which uses both Jira and Bugzilla.^[9] Jira includes tools allowing migration from competitor Bugzilla.^[10]

Jira is offered in four packages:^[11]

• Jira Work Management is intended as generic project management.
• Jira Software includes the base software, including agile project management features (previously a separate product: Jira Agile).
• Jira Service Management is intended for use by IT operations or business service desks.
• Jira Align is intended for strategic product and portfolio management.

Jira is written in Java and uses the Pico inversion of control container, Apache OFBiz entity engine, and WebWork 1 technology stack. For remote procedure calls (RPCs), Jira has REST, SOAP, and XML-RPC interfaces.^[12] Jira integrates with source control programs such as Clearcase, Concurrent Versions System (CVS), Git, Mercurial, Perforce,^[13] Subversion,^[14] and Team Foundation Server. It ships with various translations including English, French, German, Japanese, and Spanish.^[15]

Jira implements the Networked Help Desk API for sharing customer support tickets with other issue tracking systems.^[16]

License[edit]

Jira is a commercial software product that can be licensed for running on-premises or available as a hosted application.^[17]

Atlassian provides Jira for free to open source projects meeting certain criteria, and to organizations that are non-academic, non-commercial, non-governmental, non-political, non-profit, and secular. For academic and commercial customers, the full source code is available under a developer source license.^[17]

Security[edit]

In April 2010, a cross-site scripting vulnerability in Jira led to the compromise of two Apache Software Foundation servers. The Jira password database was also compromised. The database contained unsalted password hashes, which are vulnerable to rainbow attacks, dictionary lookups and cracking tools. Apache advised users to change their passwords.^[18] Atlassian themselves were also targeted as part of the same attack and admitted that a legacy database with passwords stored in plain text had been compromised.^[19]

Evolution[edit]

When launched in 2002, Jira was purely issue tracking software, targeted at software developers. The app was later adopted by non-IT organizations as a project management tool. The process accelerated after the launch of Atlassian Marketplace in 2012, which allowed third-party developers to offer project management plugins for Jira.^[20] BigPicture, Scriptrunner, Advanced Roadmaps (formerly Portfolio), Structure, Tempo Planner and ActivityTimeline^[21][22] are major project management plugins for Jira.^[23]

See also[edit]

• Comparison of issue-tracking systems
• Comparison of project management software
• List of collaborative software

References[edit]

External links[edit]

• Official website

Jira — это инструмент управления проектами, который помогает оптимизировать работу команды. Принцип работы сервиса похож на диспетчер задач в компьютере: с его помощью отслеживают запущенные процессы (проекты) и контролируют число ресурсов (сотрудников). В Jira проджект-менеджер грамотно распределяет сотрудников для выполнения задач и планирует работу. Например, если в работе уже четыре проекта, в которых задействованы все разработчики, значит, новый проект запускать не стоит, нужно дождаться завершения хотя бы одного.

У Jira есть бесплатная версия для команды до 10 человек, поэтому она популярна в небольших стартапах. Если команда больше, есть тариф Standard стоимостью $7 за одного пользователя. Он дает доступ к 250 ГБ хранилища и техподдержку в рабочие часы. В тарифе Premium стоимость одного пользователя $14, при этом он предоставляет неограниченный доступ к хранилищу и круглосуточную техническую поддержку. Оба тарифа дают возможность подключения до 20 000 пользователей и оплачиваются ежемесячно или ежегодно. Самая дорогая подписка — Enterprise — оплачивается только ежегодно и нужна, если есть особые пожелания к безопасности и масштабированию.

Agile-разработка с Jira

В Jira работают Samsung, Coca Cola, Visa, Dropbox и Audi. NASA использует Jira для создания ПО, которое управляет беспилотными исследовательскими аппаратами в космосе, например марсоходом Curiosity. Еще все эти компании придерживаются методологии Agile.

Agile — это гибкая система разработки, в которой сложные задачи разбиваются на итерации — небольшие этапы. После каждого из них команда постепенно выдает готовые части продукта, их тестируют и оценивают. Одну итерацию называют спринтом (англ. sprint — бег на короткую дистанцию). В конце спринта команда подводит итоги и ставит себе задачи на следующий.

Главные принципы Agile:

• Люди и их взаимодействие важнее процессов и инструментов.
• Работающий продукт важнее исчерпывающей документации.
• Сотрудничество с заказчиком важнее согласования условий контракта.
• Готовность к изменениям важнее следования первоначальному плану.

Есть два подхода к работе над проектом, основанные на Agile.

1. Методика Kanban — это способ визуализации задач с помощью досок, на которых задачи располагаются в соответствии со статусом. Стандартная канбан-доска делится на три колонки:

• to do — список задач;
• in progress — задачи, которые взяли в работу и выполняют;
• done — завершенные задачи.

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

2. Методика Scrum — в ней собраны все принципы гибкой разработки: деление на спринты, взаимодействие в команде и с заказчиком, нацеленность на рабочий продукт. Для визуализации рабочего процесса в Scrum тоже используют доски, на которых отслеживается процесс разработки. Отличие от канбан-досок в том, что самую важную роль играют спринты и задача не может находиться в работе дольше, чем длится спринт. Доски бывают физическими — тогда команда перемещает задачи, переклеивая стикеры. Такую методику скрам-мастера рекомендуют для небольших команд, у которых все разработчики в одном офисе. В Jira виртуальные скрам-доски выглядят так:

Для чего используют Jira

Этот инструмент создавали для отслеживания статуса задач и ошибок, но со временем его функционал расширился. Сегодня в Jira можно управлять процессом разработки от идеи до запуска готового продукта. Кроме IT-команд, ее используют маркетологи, аналитики, тестировщики и другие специалисты.

Для чего может помочь Jira:

• Управление требованиями. Требования — это вводные данные для работы над проектом. Их пишут в отдельном документе вместе с заказчиком, чтобы не возникало разногласий в процессе работы, а разработчики могли на них ориентироваться. Чтобы изменить или составить требования для команды, используют Jira в сочетании с Confluence — инструментом для совместной работы. В нем можно создавать, обсуждать и редактировать документы.
• Управление продуктами. Команды составляют в Jira дорожные карты — пошаговые планы масштабных проектов. Такие карты помогают наладить взаимодействие между отделами. Например, при грамотном управлении маркетологи могут планировать промокампанию параллельно с разработкой, а не ждать готового продукта. В дорожных картах не прописываются подробные задачи и методы выполнения, в них расставляются цели, приоритеты и обозначаются зависимости работы одного отдела от работы другого.
• Управление проектами. Jira настраивается под проекты, поэтому такой инструмент полезен проджект-менеджерам. Можно визуально отследить путь каждой задачи от создания до результата: генерация идей и гипотез, создание прототипа, дизайн, согласование дизайн-концепта, разработка, создание контента, тестирование.

Как пользоваться Jira

Установка

Зайдите на сайт проекта и зарегистрируйтесь с помощью электронной почты, Slack, Microsoft или Google-аккаунта.

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

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

Интерфейс

Внешне Jira похожа на любой другой таск-менеджер.

В верхней строке меню шесть вкладок:

• Ваша работа (Your Work) — тут отображаются проекты конкретного члена команды, в которых он исполнитель.
• Проекты (Projects) — вкладка с доступными досками команды, активными спринтами и отчетами о работе.
• Фильтры (Filters) — таблица сортировки проектов по авторам, проектам, статусам и другим показателям.
• Дашборды (Dashboards) — аналитические сводки по проектам.
• Люди (People) — список профилей членов команды.
• Приложения (Apps) — сторонние сервисы, которые интегрированы в Jira и расширяют ее функционал.

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

• эпик (epic) — большая задача, которую нужно разделить на спринты;
• история (story) — часть эпика, которую команда может решить за спринт;
• задача (task) — часть работы, которую выполняет один или несколько членов команды;
• подзадача (sub-task) — часть задачи;
• баг (bug) — особая задача по исправлению ошибок в продукте.

Боковое меню состоит из элементов управления проектами:

• Доска (Board) — это вкладка, в которой хранятся доски проектов, доступных команде. Между ними переключаются с помощью кнопки «Вниз».

• Дорожная карта (Roadmap) — трекер, с помощью которого выстраивается картина работы над проектом; в нем на линии времени отображаются этапы разработки до финального релиза.

• Бэклог (Backlog) — список рабочих задач, расставленных по приоритетам на основе дорожной карты: важные задачи — в начале списка, а менее приоритетные — в конце. Каждая задача в бэклоге — отдельный спринт.

• Активные спринты (Active sprints) — список спринтов (задач из бэклога), которые находятся у команды в работе.

• Отчеты (Reports) — в этой вкладке более 20 параметров: соотношение нагрузки на команду в спринтах, ее эффективность, длительность спринтов, прогресс проекта и прочее.

В нижней части бокового меню расположены компоненты проекта:

• Задачи — вкладка с фильтрами задач по статусам, исполнителям и прочим параметрам.
• Компоненты — среднее по величине звено между проектом и задачей: проект можно разбить на компоненты, а компоненты — на несколько задач.
• Код — вкладка быстрого доступа к сервисам для хранения исходного кода проекта (GitHub, GitLab, Bitbucket).
• Релизы — они же версии проекта; могут быть трех статусов «Выпущен», «Не издан» и «В архиве». Хранение версий помогает при возникновении проблем с продуктом, когда нужно узнать, как велась работа в предыдущих итерациях.

Создание первого проекта

После регистрации в Jira кнопка «Создайте проект» появится в рабочей области в самом центре экрана:

Шаг 1. Jira предлагает на выбор три шаблона проектов, которые подходят для разных методов работы команд:

• Kanban — шаблон для визуализации процессов, в который входят доски задач и инструмент для установки лимитов. Лимиты помогут не допустить одновременного запуска нескольких проектов, чтобы у команды хватило человеческих ресурсов для работы. Если в компании шесть разработчиков и в каждом проекте задействовано двое из них, то лимит позволит запустить одновременно максимум три проекта.

• Scrum — шаблон для задач, разбитых на спринты. Тут есть дорожная карта проекта, можно внести задачи в бэклог и отслеживать прогресс внутри каждого спринта.

В первых двух шаблонах рабочий процесс разбит на колонки «К выполнению», «В работе» и «Готово», и в них доступны одинаковые типы задач: эпик, история, баг, задание, подзадача.

• Отслеживание багов — шаблон для оперативного исправления ошибок в проекте. У него расширенная структура: есть дополнительная колонка «В процессе проверки» и типы задач: улучшение, новая функция.

Шаг 2. При выборе шаблонов Kanban и Scrum Jira предлагает выбрать тип управления проектом:

• Управляется командой — упрощенный тип, доступен всем участникам команды, а изменение настроек не влияет на другие проекты.
• Управляется компанией — расширенный тип, настройками доступа управляют администраторы, проекты связаны друг с другом и есть возможность переноса задач из одного проекта в другой.

Шаг 3. Проекту присваиваются название и ключ:

• Название — это развернутое имя, по которому команда будет распознавать проект.
• Ключ — это короткий идентификатор, в его состав автоматически входят первые буквы слов из названия. Например, если назвать проект Skillfactory Test, то Jira сгенерирует ключ ST. Также к нему можно добавить номер задачи, например ST001.

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

Создание задачи

Добавить задачу в проект можно двумя способами: кликнуть на кнопку «Создать» в верхнем меню или на «+ Создать задачу» в колонке «К выполнению». Во всплывающей форме заполняются атрибуты задачи:

• Резюме (Summary) лаконично описывает суть задачи, в этом поле в одном предложении нужно ответить на вопрос: «Что нужно сделать?»
• Описание (Description) раскрывает задачу более подробно.
• Исполнитель (Assignee) назначается сразу или уже после создания задачи. После того как кто-то из команды назначен исполнителем, задача попадет к нему во вкладку «Ваша работа».
• Метки (Labels) добавляются для сортировки задач по признакам — например, по отделам: «Дизайн», «Маркетинг», «Разработка» и так далее.
• Автор задачи (Reporter) — это член команды, который ее создал, то есть автор и исполнитель могут быть разными. Как правило, автор — ответственный за выполнение задачи.
• Вложение (Attachment) прикрепляется, если описание дополняют документами, иллюстрациями или другими материалами.
• Связанные задачи (Linked Issues) прикрепляются, если от выполнения этой задачи зависят другие.

Повышение производительности Jira

Компания Atlassian поддерживает комьюнити пользователей Jira и создает обучающие материалы, с помощью которых легче внедрить этот инструмент в работу. Например, на официальном сайте есть инструкция «Шесть базовых шагов для начала работы с Jira».

Вот что рекомендуют специалисты из Atlassian, чтобы повысить эффективность работы в Jira.

Дробить большие задачи на мелкие. В тайм-менеджменте есть прием — разделить слона (большую и трудную задачу) на бифштексы (мелкие и простые задачи), потому что так слона удобнее есть. Этот принцип применим не только к масштабным проектам, но и к простым заданиям, которые выдаются сотрудникам. Если в задаче несколько шагов или действий, стоит разделить ее на подзадачи, каждую из них расписать внятно и подробно, а не пытаться уместить алгоритм выполнения в одном описании, потому что в нем сотрудник может запутаться.

Каждая задача должна состоять из одного понятного действия. Например, «Составить дизайн-макет продукта» — это не задача, а этап работы, который состоит из цепочки действий: провести интервью с заказчиком, создать бриф, собрать референсы, обсудить дизайн с командой разработки, согласовать референсы с заказчиком, создать «рыбу» макета и так далее. Описанные шаги — это даже не половина работы над дизайн-макетом, а только малая часть, и каждый из шагов — отдельная задача.

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

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

Записывать действия, связанные с изменением проекта. В этом помогут логи — файлы формата .log. Они фиксируют действия внутри проекта в хронологическом порядке. Логи хранятся в Git — системе контроля версий. Сохранение проекта после каждого изменения поможет команде в исправлении ошибок или анализе работы продукта.

Готовиться к спринтам. Подготовка — это составление списка задач, расстановка приоритетов, оценка целей, сроков выполнения работы и сложности. На планирование создатели Jira советуют отводить не менее двух часов в неделю, а при оценке сложности использовать разные способы и обозначения. Например, можно использовать размеры одежды для обозначения величины задач, где XS — это небольшая, простая в решении задача, а XXL — объемная и сложная, которая не решается за один спринт.

Аналоги Jira

Trello

Это тоже инструмент для управления процессами на основе канбан-досок, который разработали Fog Creek, но в 2017 году его выкупила компания Atlassian, и теперь и Trello, и Jira принадлежат ей. Trello считается интуитивно понятным инструментом, который подходит любым, даже небольшим командам.

Работа, как и в Jira, организована по методу Kanban, задачи располагаются на досках и делятся на колонки: запланированные, в работе и завершенные. Для каждой задачи заводится новая карточка с названием, описанием, метками, исполнителем и другими атрибутами. Но в отличие от задач в Jira, карточки в Trello могут содержать подзадачи, списки или чек-листы.

Basecamp

Инструмент для управления процессами, организующий задачи в группы, которые и называются Basecamp, то есть «базовый лагерь». Таких групп шесть: новостная лента (Message Board), лист задач (To-dos), общий чат (Campfire), календарь (Schedule), автоматический чек-лист (Automatic Check-ins), документы и файлы (Docs & Files).

Преимущество Basecamp — это Campfire, чат для общения в команде, своего рода лагерный костер, где все собираются и обсуждают задачи, — а также автоматические чек-листы, благодаря которым можно не задавать коллегам вопросы о готовности задач, а отслеживать их самостоятельно.

Asana

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

В Asana предусмотрено три уровня коммуникации: общение происходит в комментариях к задаче, в проекте или внутри команды, — это отличает ее от других таск-менеджеров. Для обмена файлами предусмотрена интеграция с Dropbox, Google Диском, Adobe Creative Cloud и другими сервисами.

Wrike

Позиционирует себя как простая альтернатива другим планировщикам. У Wrike есть готовые шаблоны, выбор которых зависит от целей проекта, — например «Управление маркетинговой кампанией», «Запуск продукта», «Планирование нового проекта» и Канбан-доска.

Wrike, как и Jira, позволяет создавать дашборды с отчетами, отслеживать загруженность команды, чтобы предотвратить переработки и выгорание. Также в планировщике есть система контроля версий. Документы в форматах Word и Excel редактируются прямо во Wrike, скачивать их не нужно.

Самые большие ошибки, подобно толстым канатам, часто состоят из множества мелких. Возьмите канат и разделите его на нити, из которых он состоит, и вы сможете легко порвать их одну за другой. Вы подумаете: «Вот и все, что было!». Но скрутите эти нити вместе, и вы получите нечто потрясающее.

Введение

Идеальных программ не существует. Все люди грешны и все программисты делают ошибки в своих проектах. Даже идеально протестированная программа может дать сбой. Почему? Дело в том, что наши программы живут в окружении других программ, написанных другими программистами. Причем сейчас не идет речь о совместимости с ОС и аппаратными ресурсами. Вам сильно повезло, если вы знаете, с какими программами (интерфейсами) предстоит взаимодействовать вашему творению. Но ошибки могут быть и здесь.

Например, я сталкивался с ситуацией, когда моя программа, которую я много раз тестировал и прогонял по всевозможным юнит тестам, при переезде на другой сервер начинала работать совершенно неправильно. В чем может быть проблема? Во-первых, на сервере стояла более новая ОС, но для моей программы это было не страшно. Выяснилось, что ошибка происходит на несколько звеньев раньше в процессе вычислений. И скрипт, написанный другим программистом под более старую версию ОС, выдавал некорректные данные для моей программы. Это пример показывает, что ошибки в программе могут вызываться «внешним миром», в котором она живет. Однако мне повезло, ведь я прекрасно знал, что может влиять на работу программы. Ошибку я нашел достаточно быстро, т.к. мне хватило лишь проверки входных данных, чтобы узнать место в системе, где появился сбой.

Но бывает иначе. Ошибка, похожа на мину замедленного действия, которая ждет своего часа и находится в самых неожиданных местах. Достаточно вспомнить пример с выходом Service pack 3 для Windows XP. У небольшой группы пользователей это обновление ОС вызывало постоянную перезагрузку компьютера. Выяснилось, что все пострадавшие были владельцами компьютеров Hewlett-Packard с процессором AMD. Бывший менеджер по политике безопасности Microsoft Джеспер Йоханссон в своем блоге высказал возможные причины ошибки. Он предположил, что HP использовала при первоначальной инсталляции один и тот же образ как для компьютеров на базе Intel, так и на базе AMD. В результате получилось, что в обоих случаях за управление питанием компьютера отвечает файл intelppm.sys, однако Microsoft создавала этот файл для работы на процессорах Intel,  для процессоров AMD служит файл amdk8.sys. Это показывает, какими изощренными могут быть сбои, когда программный продукт предназначен для огромного числа пользователей. И ошибка не всегда может заключаться в программе.

Учитывая, что многие фирмы, производящие ПО, стараются уменьшить цикл производства в ущерб тестированию, программистам приходится постоянно взаимодействовать с Support службой. Работники саппорта принимают от пользователей заявления об ошибках, регистрируют их и дальше с ними разбираются разработчики. Если же компания осознает, что необходимо проводить тщательное тестирование продукта, перед его запуском, то программистам приходится опять-таки принимать отчеты об ошибках, но теперь уже от тестировщиков ПО.

Задача регистрации и обработки данных об ошибках, возникших при работе ПО, кажется простой лишь на первый взгляд. Дело в том, что еще до запуска сам программист может находить пачками ошибки в работе своей программы. От версии к версии количество известных ошибок может уменьшаться или увеличиваться. «Старые ошибки убрали, добавили новые», так звучит один  их старых анекдотов о программистах. Для контроля ошибок был создан замечательный продукт  — система отслеживания ошибок.

Что это такое?

Система отслеживания ошибок (англ. bug tracking system) — прикладная программа, разработанная с целью помочь разработчикам программного обеспечения (программистам, тестировщикам и др.) учитывать и контролировать ошибки (баги), найденные в программах, а также следить за процессом устранения этих ошибок. Так описаны в Wikipedia bug tracking system (далее BTS).

BTS помогает программисту следить за ошибками. Когда вы замечаете ошибку, необходимо  собрать о ней максимальное количество доступной информации. Необходимо быть предельно точным в наблюдениях. Особенно это касается отчетов об ошибках, приходящих от пользователей.

Можно привести пример Энди Ханта, автора книги «Программист-прагматик»: он разрабатывал графический редактор, и в ходе разработки появилась специфическая ошибка, которую обнаружил тестировщик. Программа «падала» когда тестировщик проводил кистью прямую линию. Программист утверждал, что программа работает замечательно и у него ошибка не проявляется. Несколько дней между тестером и программистом продолжался спор. Наконец, все собрались в одной комнате, тестировщик провел линию от ВЕРХНЕГО ПРАВОГО угла до НИЖНЕГО ЛЕВОГО. Программа зависла. Программист охнул и признался, что он проводил черту только из НИЖНЕГО ЛЕВОГО к ВЕРХНЕМУ ПРАВОМУ углу. Этот пример иллюстрирует, насколько важны подробные отчеты и сбор полной информации об ошибках.

Как правило, BTS позволяет хранить информацию об ошибке в следующем виде:

• кто сообщил о проблеме;
• дата и время, когда была обнаружена проблема;
• серьёзность проблемы;
• описание неправильного поведения программы;
• кто занимается устранением проблемы;
• состояние ошибки.

Это минимальный набор требований к БД BTS, на самом же деле многие системы багтрэкинга позволяют вести намного более подробный учет ошибок. В чем то, они напоминают системы управления проектами. А многие из них интегрированы с такими системами.

Необходимо заметить, что системы отслеживания ошибок могут быть полезны не только для программистов. Отчеты о «работе над ошибками» могут использовать менеджеры проекта. Фактически такие отчеты позволяют судить о производительности программистов, при работе по улучшению работы ПО. При обработке отчетов необходимо учитывать приоритет ошибок и сложность их устранения. Менеджер должен понимать, что некоторые ошибки могут быть  трудно устранимы, в силу архитектуры системы. Бессмысленно требовать скорейшего устранения ошибок в системных модулях: непродуманные действия по устранению одной ошибки могут породить сотни других ошибок.

Обзор

 В данном обзоре я рассмотрю несколько наиболее распространенных систем отслеживания ошибок:

• BUGS
• Bugzilla
• JIRA
• Trac
• Track Studio

BUGS — the Bug Genie

www.thebuggenie.com

Это свободная система отслеживания ошибок, распространяемая по Mozilla Public License 1.1. Для управления предоставляется веб-интерфейс. Система кроссплатформенная, написана на PHP. Проект достаточно успешно развивается, последняя версия BUGS вышла в марте 2008.

BUGS предоставляет базовый набор инструментов для регистрации ошибок, расстановки приоритетов, формировании задач для разработчиков. Эта система позволяет оповещать всех разработчиков, которые могут быть связаны с ошибкой. Система отслеживает ошибки в зависимости от версии и конфигурации ПО. Все ошибки сохраняются в единую БД, представляющую собой базу знаний об ошибках в проекте. Далее по этой БД можно формировать подробные отчеты. BUGS поддерживает возможность устанавливать blocker bugs — ошибки, которые могут блокировать выпуск релиза.

В последних версиях разработчики BUGS улучшили формат отчетов. Что особенно приятно: BUGS обладает user-friendly интерфейсом.  Для работы с этой BTS вам не потребуется копаться в горах мануалов.

Недостаток BUGS  — отсутствие распределенной многопользовательской работы. Невозможно работать удаленно с несколькими серверами или несколькими БД. В силу этого можно рекомендовать, BUGS для небольших команд разработчиков.  Благо BUGS это open source продукт и требует для своей работы стандартный набор: Apache, PHP, MySQL.

Bugzilla

www.bugzilla.org

Bugzilla – это одна из наиболее популярных систем багтрэкинга. В 1998 году Netscape представила первый релиз этой системы. Bugzilla является свободным ПО и распространяется по Mozilla Public License. Собственно, разработку этой системы сейчас ведет Mozilla Foundation.

Bugzilla пользуются более 800 (!) компаний по всему миру. Среди них встречаются такие гиганты как NASA, Id Software, Red Hat, Novell и другие. Почему же эта система пользуется такой популярностью?

В Bugzilla нет той огромной функциональности, присущей Enterprise BTS. Однако эта система включает достаточно большой набор функций, которые необходимы для контроля ошибок в небольшом и среднем проекте.

Разработчик Bugzilla Max Kanat-Alexander в своем блоге указал, что одна из системных проблем Bugzilla – это выбор Perl в качестве языка программирования. Макс указывает, что принцип Perl TMTOWTDI(There More Than One Way To Do It) не всегда помогает в разработке, т.к. позволяет быстро реализовывать некоторые вещи, представляющие не всегда лучший выход из проблемы. Также Макс говорит о проблеме «читабельности» кода на Perl, которая усложняет поддержку перловых программ. Кроме того, программы, написанные на Perl, далеко не лучшим образом работают с памятью. Подробнее со всеми замечаниями можно ознакомиться здесь: http://avatraxiom.livejournal.com/58084.html.

Возвращаясь к обзору Bugzilla, отмечу, что, несмотря на все проблемы, Bugzilla работает достаточно устойчиво и предоставляет разработчикам неплохой базовый функционал:

• отслеживать ошибки и изменения кода
• общаться с членами команды
• размещать и описывать патчи
• производить контроль качества продуктов

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

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

Bugzilla можно интегрировать с другими программами, для управления проектами:

• CVS
• Perforce SCM
• Subversion
• Tinderbox/Tinderbox2

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

Систему Bugzilla можно рекомендовать достаточно широкому кругу пользователей, которых устроит стандартный набор функций. Этот проект активно развивается (последняя версия вышла в мае 2008), так что скоро можно будет ожидать добавления новых функций, которые сделают систему удобнее для использования. Bugzilla проверена временем, а это важный аргумент в пользу этой системы.

JIRA

www.atlassian.com/software/jira/

Систему отслеживания ошибок JIRA называют «bug tracking системой номер один». Попробуем разобраться, почему эта система от компании Atlassian заслужила такого звания.

Ответ будет простым: JIRA обладает на сегодняшний день наиболее широкой функциональностью среди систем отслеживания ошибок. В целом JIRA повторяет архитектуру Bugzilla. Процесс баг трэкинга следующий:

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

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

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

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

JIRA идеально подходит для крупных проектов, с большим штатом тестировщиков. Используя JIRA можно работать под различными ОС, создавать и вести «схемы безопасности» для каждого из проектов. То есть можем создать группу пользователей на конкретный проект, раздать на этот же проект права, или использовать стандартную схему безопасности на этот проект. JIRA можно успешно интегрировать с subversion.

Эта BTS обладает одним существенным недостатком: она платная. Стоимость установки JIRA на один сервер начинается от $1200. Однако, это не такая высокая цена для компании, которая способна оплатить штат тестировщиков. JIRA можно смело рекомендовать разработчикам больших распределенных проектов.

Trac

trac.edgewall.org

Trac – это открытое ПО, являющиеся одновременно инструментом для управления проектом и системой отслеживания ошибок. Проект Trac разрабатывается компанией Edgewall Software и распространяется по Modified BSD license.

Интерфейс Trac фактически представляет wiki. Система использует в работе SVN репозиторий, так что использовать его имеет смысл только вместе с svn.  Что же умеет Trac?

• разделение проекта на этапы (milestones)
• контроль выполнения (roadmap)
• все изменения по проекту заносятся на временную шкалу (timeline)
• поддержка RSS

Отчеты об ошибках можно заносить в тикеты. Среди прочего Trac позволяет: учет ошибок, замечаний, пожеланий с возможностью фильтрации и занесение соответственно в milestone, roadmap. В Trac реализован модуль просмотра репозитория, это существенно облегчает работу с SVN.

Trac был написан на Python и является кроссплатформенной системой. Эту систему можно рекомендовать широкому кругу разработчиков, которые хотят внедрить комплексную систему управления проектами, включающую отслеживание ошибок.

Track Studio

www.trackstudio.ru

Track Studio я включил в этот обзор, т.к. этот проект разработан российской компанией «ГРАН». Всегда интересно сравнивать зарубежные и российские разработки. Тем более, когда наш продукт ни в чем не уступает западным аналогам. Track Studio написан на Java и работает на UNIX и Windows NT. Как и Trac это не классическая система отслеживания ошибок, а комплексная система позволяющая управлять проектами и требованиями к ПО.  

В отличие от JIRA, оптимизированной для работы с внешними клиентами, Track Studio позволяет эффективно организовать работу внутри компании (например, обработку обращений клиентов). Track Studio позволяет эффективно управлять тысячами проектов: проекты можно организовывать в иерархию, можно делать поиск проектов по параметрам, к проектам можно прикладывать файлы (например, с техническим заданием), для проектов можно создавать пользовательские поля (дата релиза, клиент, номер договора) и многое другое. Одно из преимуществ состоит в том, что Track Studio хорошо поддерживает БД Oracle. В ORACLE нельзя создать текстовые поля длиннее 4000 байт, однако описания проблем и различные служебные данные в JIRA и Track Studio могут достигать десятков килобайт. Track Studio разбивает длинные текстовые поля на куски по 1800 символов, которые хранит отдельными записями в специальной таблице. Этот способ является быстрым, простым в реализации и очень удобным в использовании.

Какие недостатки у Track Studio? В Track Studio сложно осуществлять интеграцию с другими средами разработки. Кроме того у программы достаточно сложный интерфейс.

Цены на Track Studio начинаются от $500, что является существенным преимуществом по сравнению с JIRA. Эту систему имеет смысл использовать при разработке крупных проектов, когда возникает потребность задействовать все фичи, входящие в состав Track Studio.

Сравнительный анализ

Выводы

Если вы еще не используете систему отслеживания ошибок – вам стоит о ней серьезно задуматься, т.к. в первую очередь это увеличивает производительность программистов, систематизирует и автоматизирует борьбу с ошибками. Если вы программист-фрилансер попробуйте использовать бесплатную программу BUGS. Средним проектам наверняка пригодится Bugzilla, по крайней мере она удовлетворяет большинству требований к BTS. Крупным командам разработчиков, которые взаимодействуют с отделами тестирования и поддержки конечных пользователей, понадобится JIRA. Ну а если кроме багтрекинга вы хотите вести учет продвижения разработки проекта и руководить задачами программистов, то есть смысл выбрать систему подобную Trac или Track Studio.

Но в любом случае, начинайте использовать систему отслеживания ошибок! Если вы программист, вы оцените, сколько времени вы будете экономить в борьбе с ошибками, используя BTS. Если же вы менеджер ИТ проекта BTS поможет вам наиболее полно контролировать процесс разработки ПО.

---

Оригинал статьи