Атестаційні завдання K2 ERP/Багтрекер

Атестаційне завдання K2 ERP — Багтрекер — це практична задача для перевірки навичок розробника або впроваджувача K2 ERP у створенні модуля обліку помилок, технічних задач, побажань, доопрацювань, тестування, відповідальних виконавців, статусів, пріоритетів і звітності по якості розробки.

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

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

Назва завдання

Модуль багтрекінгу: облік і управління помилками та задачами розробки.

Мета завдання

Мета завдання — створити в K2 ERP модуль для обліку багів, задач розробки, покращень, технічних завдань і контролю якості програмного продукту.

Система повинна дозволяти:

• вести проєкти;
• створювати баги та задачі;
• розрізняти типи задач;
• встановлювати пріоритет;
• призначати відповідального виконавця;
• фіксувати постановника задачі;
• прикріплювати скриншоти, логи й файли;
• змінювати статус задачі;
• передавати задачу на тестування;
• повертати задачу на доопрацювання;
• закривати задачу після перевірки;
• зберігати історію змін;
• надсилати повідомлення;
• контролювати прострочені задачі;
• формувати звіти по проєктах, виконавцях, статусах і швидкості вирішення.

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

Реальний бізнес-контекст

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

Такі задачі можуть надходити з різних джерел:

• від тестувальників;
• від клієнтів;
• від менеджерів;
• від розробників;
• із системи підтримки;
• із внутрішнього аудиту;
• після демонстрацій або впроваджень.

Команді потрібно не загубити жодну задачу, правильно визначити її пріоритет, призначити відповідального, проконтролювати строк, перевірити результат і мати історію всіх змін.

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

Основний бізнес-процес

Типовий процес роботи з багом або задачею виглядає так:

1. користувач створює задачу;
2. вказує проєкт, тип, опис і пріоритет;
3. додає скриншоти, логи або інші файли;
4. призначається відповідальний виконавець;
5. виконавець бере задачу в роботу;
6. після виправлення задача передається на тестування;
7. тестувальник перевіряє результат;
8. якщо проблема не вирішена, задача повертається в роботу;
9. якщо все працює коректно, задача переводиться в статус «Вирішено» або «Закрито»;
10. система зберігає історію змін;
11. дані потрапляють у звіти по якості та продуктивності.

Основні об’єкти модуля

Об’єкт	Призначення
Проєкти	Програмні продукти, сайти, ERP-модулі або клієнтські впровадження
Типи задач	Bug, Improvement, Feature Request, Task
Статуси	Етапи життєвого циклу задачі
Пріоритети	Важливість і терміновість задачі
Баги і задачі	Основний журнал проблем, запитів і робіт
Виконавці	Розробники, тестувальники або інші відповідальні особи
Постановники	Користувачі, які створили задачу
Файли	Скриншоти, логи, відео, документи, технічні матеріали
Коментарі	Обговорення задачі та уточнення
Журнал подій	Історія зміни статусів, виконавців, пріоритетів і коментарів
Нотифікації	Повідомлення про створення, зміну або прострочення задачі
Звіти	Статистика по проєктах, виконавцях, статусах і строках

Довідник «Проєкти»

Довідник проєктів використовується для групування багів і задач.

Проєктом може бути ERP-модуль, сайт, мобільний додаток, клієнтське впровадження, внутрішня система або окремий напрям розробки.

Поля проєкту

Поле	Опис
Назва проєкту	Назва продукту, модуля або клієнтського проєкту
Тип проєкту	ERP, мобільний додаток, сайт, інтеграція, інше
Керівник проєкту	Відповідальний за проєкт
Клієнт	Опціонально, якщо проєкт клієнтський
Статус	Активний, завершений, призупинений, архівний
Опис	Короткий опис проєкту

Приклади типів проєктів

• ERP;
• мобільний додаток;
• сайт;
• інтернет-магазин;
• CRM;
• інтеграція;
• внутрішня система;
• клієнтське впровадження.

Довідник «Типи задач»

Тип задачі допомагає зрозуміти природу роботи.

Типи задач

Тип	Значення
Bug	Помилка або некоректна поведінка системи
Improvement	Покращення існуючої функції
Feature Request	Запит на нову функцію
Task	Технічна або організаційна задача
Support	Задача підтримки клієнта
Documentation	Задача по документації

Важливо. Тип задачі має впливати на аналіз. Баги показують якість продукту, Feature Request — розвиток функціоналу, а Task — технічні або організаційні роботи.

Довідник «Статуси»

Статуси описують життєвий цикл задачі.

Типові статуси

Статус	Значення
Відкрита	Задачу створено, але ще не взято в роботу
Призначено	Задачу передано конкретному виконавцю
У процесі	Виконавець працює над задачею
Очікує уточнення	Потрібна додаткова інформація
На тестуванні	Задачу передано тестувальнику для перевірки
Повернуто на доопрацювання	Тестування виявило, що проблема не вирішена повністю
Вирішено	Виконавець виправив задачу
Закрито	Задачу перевірено і прийнято
Скасовано	Задача більше не актуальна

Довідник «Пріоритети»

Пріоритет показує, наскільки важливо швидко вирішити задачу.

Пріоритет	Значення
Низький	Некритична задача, може чекати
Середній	Звичайна робоча задача
Високий	Важлива задача, яка впливає на роботу користувачів
Критичний	Блокує роботу системи, клієнта або ключового бізнес-процесу

Журнал «Баги і задачі»

Журнал багів і задач є головним робочим екраном модуля.

Колонки журналу

Колонка	Опис
Номер задачі	Унікальний номер задачі
Назва задачі	Коротка назва проблеми або роботи
Тип задачі	Bug, Improvement, Feature Request, Task
Проєкт	До якого проєкту належить задача
Пріоритет	Низький, середній, високий, критичний
Статус	Поточний стан задачі
Відповідальний	Виконавець задачі
Постановник	Хто створив задачу
Дата створення	Коли задача була створена
Дата оновлення	Коли задача змінювалася востаннє
Планова дата вирішення	До якої дати задачу потрібно вирішити

Функціональність журналу

Журнал має підтримувати:

• пошук по назві задачі;
• пошук по опису;
• пошук по номеру задачі;
• фільтрацію за проєктом;
• фільтрацію за типом задачі;
• фільтрацію за статусом;
• фільтрацію за пріоритетом;
• фільтрацію за виконавцем;
• фільтрацію за постановником;
• фільтрацію за датою створення;
• фільтрацію за строком вирішення;
• масову зміну статусу;
• масове закриття задач;
• експорт списку задач.

Форма створення задачі

Форма створення задачі повинна дозволяти швидко зафіксувати помилку або технічну задачу.

Поля форми задачі

Поле	Опис
Проєкт	Вибір із довідника проєктів
Тип задачі	Bug, Improvement, Feature Request, Task
Назва задачі	Короткий заголовок
Опис задачі	Детальний опис проблеми або пропозиції
Кроки відтворення	Для багів: що потрібно зробити, щоб побачити помилку
Очікуваний результат	Як система повинна працювати
Фактичний результат	Що відбувається насправді
Пріоритет	Важливість задачі
Відповідальний	Виконавець або команда
Планова дата вирішення	Орієнтовний строк виконання
Файли	Скриншоти, логи, відео, документи

Опис багу

Для задач типу Bug бажано обов’язково вказувати:

• де виникає помилка;
• які дії виконував користувач;
• що очікувалося;
• що сталося фактично;
• чи повторюється помилка;
• посилання на сторінку або документ;
• скриншот або лог помилки.

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

Прикріплення файлів

Модуль має дозволяти прикріплювати файли до задачі.

Типові вкладення

• скриншоти;
• відео помилки;
• логи;
• дампи;
• документи;
• технічні завдання;
• приклади файлів для імпорту;
• макети;
• посилання на зовнішні ресурси.

Коментарі до задачі

Картка задачі повинна містити коментарі.

Коментарі потрібні для:

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

Життєвий цикл багу

Типовий маршрут багу:

Створено → Призначено → В роботі → На тестуванні → Вирішено → Закрито

Розширений маршрут:

Відкрита → Призначено → У процесі → На тестуванні → Повернуто на доопрацювання → У процесі → На тестуванні → Вирішено → Закрито

Зміна статусу

Система повинна дозволяти змінювати статус задачі через AJAX без перезавантаження сторінки.

При кожній зміні статусу потрібно зберігати:

• хто змінив статус;
• попередній статус;
• новий статус;
• дату і час;
• коментар, якщо він був вказаний.

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

Повернення з тестування

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

При поверненні потрібно вказати:

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

Нотифікації

Модуль має підтримувати повідомлення користувачам.

Канали повідомлень

Можливі канали:

• email;
• внутрішні повідомлення K2 ERP;
• Telegram або інший месенджер, якщо інтеграція доступна.

Події для нотифікацій

Повідомлення бажано надсилати, коли:

• створено нову задачу;
• задачу призначено виконавцю;
• змінено статус;
• додано коментар;
• задачу повернуто з тестування;
• задача прострочена;
• наближається планова дата вирішення;
• задачу закрито.

Контроль строків

Система повинна контролювати задачі, які не закриті у встановлений строк.

Задача вважається простроченою, якщо:

• планова дата вирішення менша за поточну дату;
• статус не дорівнює «Закрито» або «Скасовано».

Прострочені задачі потрібно виділяти в журналі та звітах.

Масові дії

Журнал має підтримувати масові дії.

Можливі масові дії:

• призначити виконавця;
• змінити пріоритет;
• змінити статус;
• закрити задачі;
• перенести задачі в інший проєкт;
• експортувати вибрані задачі.

Масові дії мають бути доступні лише користувачам із відповідними правами.

Звіт «Статистика по проєкту»

Звіт показує стан задач у межах одного або кількох проєктів.

У звіті потрібно відображати:

• проєкт;
• кількість відкритих задач;
• кількість задач у роботі;
• кількість задач на тестуванні;
• кількість вирішених задач;
• кількість закритих задач;
• кількість прострочених задач;
• середній час вирішення задачі.

Звіт «Продуктивність розробників»

Звіт показує результативність виконавців за період.

У звіті потрібно відображати:

• виконавця;
• кількість призначених задач;
• кількість вирішених задач;
• кількість закритих задач;
• кількість повернень з тестування;
• середній час вирішення;
• кількість критичних задач;
• кількість прострочених задач.

Звіт «Якість продукту»

Звіт допомагає аналізувати стабільність продукту.

У звіті потрібно показувати:

• кількість багів по проєктах;
• кількість критичних багів;
• кількість повторних багів;
• кількість багів, повернутих з тестування;
• динаміку відкритих і закритих багів;
• частку багів серед усіх задач.

Звіт «Прострочені задачі»

Звіт показує задачі, які не були вирішені вчасно.

У звіті потрібно відображати:

• номер задачі;
• назву;
• проєкт;
• виконавця;
• пріоритет;
• планову дату вирішення;
• кількість днів прострочення;
• поточний статус.

Звіт «Повернення з тестування»

Звіт показує задачі, які були повернуті на доопрацювання.

У звіті потрібно відображати:

• задачу;
• проєкт;
• виконавця;
• тестувальника;
• кількість повернень;
• причину останнього повернення;
• статус.

Друк і експорт

Модуль має підтримувати експорт даних.

Формати:

• Excel;
• PDF.

Експортувати потрібно:

• список задач;
• статистику по проєктах;
• продуктивність виконавців;
• прострочені задачі;
• звіт по якості продукту.

AJAX-інтерактив

Інтерфейс має працювати швидко та без зайвого перезавантаження сторінок.

Через AJAX мають працювати:

• створення задачі;
• вибір проєкту;
• вибір виконавця;
• зміна статусу;
• зміна пріоритету;
• додавання коментаря;
• прикріплення файлу;
• повернення з тестування;
• масове закриття задач;
• фільтрація журналу;
• оновлення звітів.

Логування змін

Модуль повинен фіксувати всі важливі зміни.

Журнал подій має зберігати:

• хто створив задачу;
• хто змінив назву або опис;
• хто змінив статус;
• хто змінив пріоритет;
• хто змінив виконавця;
• хто додав коментар;
• хто прикріпив файл;
• хто передав на тестування;
• хто повернув задачу на доопрацювання;
• хто закрив задачу;
• дату й час зміни;
• старе та нове значення, якщо це можливо.

Права доступу

Модуль має підтримувати розмежування прав.

Роль	Можливості
Користувач	Створює задачі, додає коментарі, переглядає свої задачі
Розробник	Бере задачі в роботу, змінює робочі статуси, додає рішення
Тестувальник	Перевіряє задачі, повертає на доопрацювання або підтверджує вирішення
Керівник проєкту	Призначає виконавців, контролює строки, пріоритети і звіти
Адміністратор	Налаштовує проєкти, статуси, типи задач, права і службові параметри

Технічні вимоги

Параметр	Опис
Бекенд	K2 Cloud ERP на Python або PHP
База даних	PostgreSQL або MySQL
Фронтенд	HTML5, JavaScript
AJAX	Axios або Fetch API
UI-компоненти	DataTables, Select2
Файли	Завантаження скриншотів, логів і документів
Експорт	Excel або PDF для списків і звітів

Рекомендовані сутності бази даних

Для реалізації задачі доцільно передбачити такі сутності:

• проєкти;
• типи проєктів;
• типи задач;
• статуси задач;
• пріоритети;
• задачі;
• коментарі задач;
• файли задач;
• користувачі;
• ролі користувачів;
• виконавці;
• тестувальники;
• журнал подій;
• повернення з тестування;
• нотифікації;
• звіти;
• права доступу.

Практичне завдання

У межах атестації потрібно продемонструвати робочий сценарій.

Мінімальний сценарій:

1. створити проєкт;
2. створити типи задач;
3. створити статуси;
4. створити пріоритети;
5. створити задачу типу Bug;
6. додати опис, кроки відтворення, очікуваний і фактичний результат;
7. прикріпити скриншот або лог;
8. призначити відповідального виконавця;
9. змінити статус на «У процесі»;
10. додати коментар виконавця;
11. передати задачу на тестування;
12. повернути задачу на доопрацювання;
13. повторно передати задачу на тестування;
14. перевести задачу в статус «Вирішено»;
15. закрити задачу після перевірки;
16. перевірити журнал подій;
17. створити задачу з простроченим строком;
18. перевірити підсвітку прострочення;
19. виконати фільтрацію за статусом, пріоритетом і виконавцем;
20. виконати масове закриття тестових задач;
21. сформувати звіт статистики по проєкту;
22. сформувати звіт продуктивності розробників;
23. сформувати звіт прострочених задач;
24. експортувати список задач у Excel або PDF.

Критерії оцінювання

Критерій	Бали	Що перевіряється
Реалізація журналу багів і задач	20	Проєкти, задачі, типи, статуси, пріоритети, виконавці, фільтри, пошук
Управління статусами і пріоритетами	20	Життєвий цикл, передача в роботу, тестування, повернення, закриття, історія змін
Створення задач з прикріпленням файлів	20	Опис, кроки відтворення, скриншоти, логи, коментарі, вкладення
Формування звітів по проєктах і виконавцях	20	Статистика по проєктах, продуктивність, прострочення, якість продукту
Інтерактивність через AJAX і повідомлення	20	AJAX-створення, зміна статусів, коментарі, фільтри, нотифікації
Разом	100	Максимальна оцінка

Шкала оцінювання

Бали	Рівень	Опис
90–100	Відмінно	Модуль повністю працює: задачі, баги, статуси, пріоритети, файли, тестування, повернення, нотифікації, звіти й AJAX реалізовані коректно
75–89	Добре	Основна логіка працює, є незначні недоліки, які не руйнують процес багтрекінгу
60–74	Зараховано	Базовий сценарій працює, але частина функцій реалізована неповно або потребує доопрацювання
0–59	Не зараховано	Відсутня критична логіка: задачі, статуси, виконавці, файли, тестування, журнал подій або звіти

Критичні помилки

Критичними помилками вважаються ситуації, коли:

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

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

Очікуваний результат

У результаті виконання атестаційного завдання має бути створений модуль багтрекінгу в K2 ERP.

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

Примітка

Багтрекер критично важливий для команд розробки будь-якого рівня — від маленьких стартапів до великих корпоративних ERP-проєктів.

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

Коротко

Питання	Відповідь
Що потрібно створити?	Модуль багтрекінгу для обліку помилок і задач розробки
Які довідники потрібні?	Проєкти, типи задач, статуси, пріоритети, користувачі
Який головний журнал?	Баги і задачі
Який типовий життєвий цикл?	Створено → Призначено → В роботі → На тестуванні → Вирішено → Закрито
Що має містити баг?	Опис, кроки відтворення, очікуваний і фактичний результат, файли, статус, виконавця
Що важливо для тестування?	Можливість повернення задачі на доопрацювання з коментарем
Які звіти потрібні?	Статистика по проєктах, продуктивність розробників, прострочені задачі, якість продукту
Що є критичною вимогою?	Повний цикл: задача → робота → тестування → закриття з історією змін

Див. також

• K2 ERP
• K2 ERP
• Атестаційні завдання K2 ERP
• Багтрекер
• Управління задачами
• HelpDesk
• Проєктний менеджмент
• Тестування
• QA
• Розробка програмного забезпечення
• Нотифікації
• AJAX