Багтрекер Ця стаття має кілька недоліків Будь ласка допоможіть удосконалити її або обговоріть ці проблеми на сторінці об

Багтрекер або Система відстеження помилок (англ. bug tracking system) — прикладна програма, створена з метою допомогти розробникам програмного забезпечення (тестувальникам, програмістам, керівникам проєктів) враховувати і контролювати помилки, знайдені у програмах, побажання користувачів, а також стежити за процесом усунення цих помилок і виконання або невиконання побажань. Це може розглядатись як різновид системи відстеження проблем^[en].

Багтрекер, як правило, є необхідним компонентом гарної інфраструктури розробки програмного забезпечення, і послідовне використання системи відстеження помилок або проблем вважається однією з «відмінних особливостей хорошої команди програмістів».

Передумови ред.

Кожному, хто розробляв програмні продукти, добре знайоме співвідношення «20/80» — останні 20 % роботи тривають 80 % часу.

Як це не парадоксально, але нічого дивного в цій пропорції немає, адже саме на завершальній стадії починається тестування проєкту, коли виявляються помилки, і що більший проєкт, то більше буде знайдено помилок.

Водночас досить часто виявляється, що більшість цих помилок були відомі та могли бути виправлені з меншими витратами на попередніх стадіях роботи, але не були вчасно описані, а потім загубилися серед інших важливих завдань.

Отже, система відстеження помилок у найпростішому варіанті — це процес, що включає в себе виявлення помилки, її опис, виправлення і перевірку цього виправлення, тобто процес «стеження» за багом протягом всього як його життєвого циклу, так і життєвого циклу розробки в цілому.

Компоненти ред.

Сукупність інформації про дефект ред.

Головний компонент багтрекера — база даних, що записує повідомлення про виявлені дефекти. Ці повідомлення зазвичай включають наступну інформацію:

номер (ідентифікатор) дефекту;
короткий опис дефекту;
хто повідомив про дефект;
дата і час виявлення дефекту;
версія продукту, в якій виявлено дефект;
серйозність (критичність) дефекту та пріоритет вирішення;
опис кроків для відтворення дефекту (неправильної поведінки програми);
очікуваний результат і фактичний результат;
відповідальний за усунення дефекту;
обговорення можливих рішень та їх наслідків;
поточний стан (статус) виправлення дефекту;
версія продукту, в якій дефект виправлено.

Крім того, розвинені системи надають можливість прикріплювати файли, які допомагають описати проблему (наприклад, дамп пам'яті^[en] або скріншот).

життєвий цикл бага в системі Bugzilla

Життєвий цикл дефекту ред.

Типові багтрекери підтримують концепцію життєвого циклу бага, що відстежується через статус, присвоєний багу:

новий — дефект зареєстрований тестувальником
призначений — призначений відповідальний за виправлення дефекту
вирішений — дефект переходить назад у сферу відповідальності тестувальника. Як правило, супроводжується резолюцією, наприклад:
- виправлено (виправлення включені у версію таку-то)
- дубль (повторює дефект, що вже знаходиться в роботі)
- не виправлено (працює відповідно до специфікації, має занадто низький пріоритет, виправлення відкладено до наступної версії тощо)
- неможливо відтворити («в мене все працює»; запит додаткової інформації про умови, в яких дефект проявляється)
далі тестувальник проводить перевірку виправлення, залежно від чого дефект або знову переходить у статус призначений (якщо він описаний як виправлений, але не виправлений), або у статус закритий
відкритий повторно — дефект знайдено знову в іншій версії

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

Використання ред.

Головна перевага багтрекера полягає в забезпеченні чіткого централізованого огляду запитів на розробку (включаючи як помилки, так і виправлення, різниця часто нечітка) та їх стану. Список пріоритетів незавершених пунктів (що часто називається backlog) забезпечує вагомий внесок при визначенні перспективного плану продукту, чи просто «наступного релізу».

У корпоративному середовищі багтрекер може використовуватися для генерації звітів^[en], що показують продуктивність програмістів при виправленні помилок. Однак, іноді такий підхід може спричинити неточний результат через те, що різні помилки мають різну ступінь серйозності та складності. Водночас серйозність проблеми прямо не стосується складності її усунення. Погляди менеджерів та архітекторів можуть відрізнятись.

Багато багтрекерів, зокрема ті, що використовуються більшістю проєктів відкритого програмного забезпечення, дозволяють вводити звіт про помилку безпосередньо користувачам. Інші системи використовуються лише всередині компаній чи організацій, що займаються розробкою програмного забезпечення. Здебільшого багтрекери використовуються спільно з іншими системами керування проєктами.

Різновиди ред.

Локальний багтрекер (англ. Local bugtracker, LBT) — зазвичай комп'ютерна програма, використовувана командою професійних підтримувачів додатку (часто служба технічної підтримки) для відстеження проблем і спілкування з розробниками програмного забезпечення. Використання LBT дозволяє спеціалістам зі служби підтримки відстежувати баги «своєю власною мовою», а не «мовою розробників». Крім того, використання LBT дозволяє команді підтримки відстежувати інформацію про користувачів, що висловили скарги, неважливі для процесу розробки (тоді у разі використання LBT існує два багтрекери).

Розподілені багтрекери ред.

Деякі багтрекери розроблено для роботи з програмами розподіленого контролю версій. Такі розподілені багтрекери дозволяють легко читати, додавати до бази даних чи оновлювати звіти про помилки, поки розробник поза мережі. До розподілених багтрекерів належать Bugs Everywhere, DisTract і Fossil.

Останнім часом комерційні багтрекери також почали об'єднуватися з розподіленим контролем версій. FogBugz^[en], наприклад, дозволяє цю функціональність через інструменти контролю вихідного коду, Kiln.

Хоча вікі та багтрекери вважаються різними типами програмного забезпечення, ikiwiki^[en] може також використовуватись як розподілений багтрекер. У ній можливо керувати як документами, так і кодом, в інтегрованому розподіленому стилі. Однак, функціональність її запитів широка чи дружня до користувача, як у деяких інших, нерозподілених багтрекерів, таких як Bugzilla. Подібні твердження стосуються й org-mode, хоча це й не програма для вікі як така.

Порівняння багтрекерів ред.

Feature	BUGS	Bugzilla	JIRA	Trac	Track Studio
Багатоплатформність	Так	Так	Так	Так	Так
Мова програмування	PHP	Perl	Java	Python	Java
Ліцензія	MPL	MPL	Ні	BSD	Ні
Розподілена робота	Ні	Так	Так	Так	Так
Побудова звітів	Так	Так	Так	Так	Так
Підтримка RSS оповіщень	Ні	Так	Так	Так	Так
Підтримка e-mail сповіщень	Так	Так	Так	Так	Так
Інтеграція з MS Excel	Ні	Ні	Так	Так	Так
Управління проєктами	Ні	Ні	Ні	Так	Так
Ведення підзадач	Ні	Ні	Ні	Так	Так
Інтеграція з SVN	Ні	Так	Так	Так	Так
Підтримка прикріплення файлів	Так	Так	Так	Так	Так
Схеми безпеки	Ні	Ні	Так	Так	Так
База знань помилок	Так	Так	Так	Так	Так
Зручний інтерфейс	Так	Ні	Так	Так	Ні
Підтримка російської мови	Так	Так	Так	Так	Так
Ціна	free	free	$1200	free	$550

Див. також ред.

Issue tracking system^[en]
Порівняння систем відстеження помилок^[ru] — включно з системами керування проєктами
Порівняння систем відстеження проблем^[en] — включно з системами відстеження помилок
Баг
Книга відгуків і пропозицій

Примітки ред.

Сполські, Джоел (8 листопада 2000). Painless Bug Tracking. Архів оригіналу за 9 липня 2013. Процитовано 29 жовтня 2010.
Bug report. Docforge. Архів оригіналу за 9 липня 2013. Процитовано 9 березня 2010.
Канер; Фолк; Нгуен (2001). 5. Тестирование программного обеспечения (рос.). с. 105. ISBN 9667393879. «Бейзер, наприклад, пропонує шкалу від 1 (незначна помилка, наприклад, граматична) до 10 (фатальна, така, що викликає збої у інших системах, війни, убивства і таке інше)»
Bogomil Shopov (8 вересня 2014). . Архів оригіналу за 13 листопада 2014. Процитовано 17 листопада 2014.
Корбет, Джонатан (14 травня 2008). Distributed bug tracking. LWN.net. Архів оригіналу за 9 липня 2013. Процитовано 7 січня 2009.
FogBugz Features. FogBugz^[en]. Архів оригіналу за 9 липня 2013. Процитовано 29 жовтня 2010.
Гесс, Джоуї (6 квітня 2007). Integrated issue tracking with Ikiwiki. LinuxWorld. IDG^[en]. Архів оригіналу за 9 липня 2013. Процитовано 7 січня 2009.

Посилання ред.

Bug Tracking Software, каталог посилань Open Directory Project
How to Report Bugs Effectively
List of distributed bug tracking software
(англійською). Архів оригіналу за 16 січня 2019. Процитовано 14 березня 2019.
. Архів оригіналу за 23 грудня 2018. Процитовано 14 березня 2019.

Це незавершена стаття про програмне забезпечення.
Ви можете допомогти проєкту, виправивши або дописавши її.

[1] Сполські, Джоел (8 листопада 2000). Painless Bug Tracking. Архів оригіналу за 9 липня 2013. Процитовано 29 жовтня 2010.

[2] Bug report. Docforge. Архів оригіналу за 9 липня 2013. Процитовано 9 березня 2010.

[3] Канер; Фолк; Нгуен (2001). 5. Тестирование программного обеспечения (рос.). с. 105. ISBN 9667393879. «Бейзер, наприклад, пропонує шкалу від 1 (незначна помилка, наприклад, граматична) до 10 (фатальна, така, що викликає збої у інших системах, війни, убивства і таке інше)»

[4] Bogomil Shopov (8 вересня 2014). . Архів оригіналу за 13 листопада 2014. Процитовано 17 листопада 2014.

[lwn-distributed-5] Корбет, Джонатан (14 травня 2008). Distributed bug tracking. LWN.net. Архів оригіналу за 9 липня 2013. Процитовано 7 січня 2009.

[6] FogBugz Features. FogBugz^[en]. Архів оригіналу за 9 липня 2013. Процитовано 29 жовтня 2010.

[ikiwiki-7] Гесс, Джоуї (6 квітня 2007). Integrated issue tracking with Ikiwiki. LinuxWorld. IDG^[en]. Архів оригіналу за 9 липня 2013. Процитовано 7 січня 2009.