@@ Рядок 1: / Рядок 1: @@
-= Модуль багтрекінгу: облік і управління помилками та задачами розробки =
+{{DISPLAYTITLE:Атестаційні завдання K2 ERP/Багтрекер}}
+'''Атестаційне завдання K2 ERP — Багтрекер''' — це практична задача для перевірки навичок розробника або впроваджувача [[K2 ERP]] у створенні модуля обліку помилок, технічних задач, побажань, доопрацювань, тестування, відповідальних виконавців, статусів, пріоритетів і звітності по якості розробки.
+Модуль має забезпечувати повний цикл роботи з багами та задачами розробки: від створення звернення або помилки до призначення виконавця, виправлення, тестування, закриття та аналізу ефективності команди.
+<div style="border:3px solid #1565c0; background:#e3f2fd; padding:14px; margin:16px 0;">
+'''Коротко.''' Потрібно реалізувати багтрекер, який дозволяє фіксувати баги, задачі, покращення і нові функції, призначати відповідальних, змінювати статуси, додавати файли та логи, повертати задачі з тестування, надсилати повідомлення і формувати звіти по проєктах та виконавцях.
+</div>
+__TOC__
+== Назва завдання ==
+'''Модуль багтрекінгу: облік і управління помилками та задачами розробки'''.
+== Мета завдання ==
+Мета завдання — створити в K2 ERP модуль для обліку багів, задач розробки, покращень, технічних завдань і контролю якості програмного продукту.
+Система повинна дозволяти:
+* вести проєкти;
+* створювати баги та задачі;
+* розрізняти типи задач;
+* встановлювати пріоритет;
+* призначати відповідального виконавця;
+* фіксувати постановника задачі;
+* прикріплювати скриншоти, логи й файли;
+* змінювати статус задачі;
+* передавати задачу на тестування;
+* повертати задачу на доопрацювання;
+* закривати задачу після перевірки;
+* зберігати історію змін;
+* надсилати повідомлення;
+* контролювати прострочені задачі;
+* формувати звіти по проєктах, виконавцях, статусах і швидкості вирішення.
+<div style="border:3px solid #2e7d32; background:#e8f5e9; padding:14px; margin:16px 0;">
+'''Головний принцип.''' Багтрекер — це не просто список помилок. Це система контролю якості, де кожна проблема має опис, проєкт, тип, пріоритет, відповідального, статус, історію змін і зрозумілий результат перевірки.
+</div>
 == Реальний бізнес-контекст ==
-У процесі розробки програмного забезпечення та супроводу клієнтів:
+У процесі розробки програмного забезпечення та супроводу клієнтів постійно виникають помилки, побажання, технічні задачі, пропозиції щодо покращення і запити на нові функції.
-* постійно виникають помилки — баги;
+Такі задачі можуть надходити з різних джерел:
-* з’являються пропозиції щодо покращення;
-* потрібно обробляти задачі з різних джерел:
-** тестування;
-** клієнтів;
-** менеджерів.
-Необхідно:
+* від тестувальників;
+* від клієнтів;
+* від менеджерів;
+* від розробників;
+* із системи підтримки;
+* із внутрішнього аудиту;
+* після демонстрацій або впроваджень.
-* фіксувати всі баги і задачі;
+Команді потрібно не загубити жодну задачу, правильно визначити її пріоритет, призначити відповідального, проконтролювати строк, перевірити результат і мати історію всіх змін.
-* призначати відповідальних;
-* відстежувати життєвий цикл кожного багу;
-* аналізувати причини проблем і їх усунення.
-== Основні завдання ==
+Без багтрекера задачі розпорошуються по месенджерах, листах і усних домовленостях. Це призводить до повторних помилок, втрати відповідальності, зриву строків і погіршення якості продукту.
+== Основний бізнес-процес ==
+Типовий процес роботи з багом або задачею виглядає так:
+# користувач створює задачу;
+# вказує проєкт, тип, опис і пріоритет;
+# додає скриншоти, логи або інші файли;
+# призначається відповідальний виконавець;
+# виконавець бере задачу в роботу;
+# після виправлення задача передається на тестування;
+# тестувальник перевіряє результат;
+# якщо проблема не вирішена, задача повертається в роботу;
+# якщо все працює коректно, задача переводиться в статус '''«Вирішено»''' або '''«Закрито»''';
+# система зберігає історію змін;
+# дані потрапляють у звіти по якості та продуктивності.
+== Основні об’єкти модуля ==
+{| class="wikitable" style="width:100%;"
+! Об’єкт
+! Призначення
+|-
+| Проєкти
+| Програмні продукти, сайти, ERP-модулі або клієнтські впровадження
+|-
+| Типи задач
+| Bug, Improvement, Feature Request, Task
+|-
+| Статуси
+| Етапи життєвого циклу задачі
+|-
+| Пріоритети
+| Важливість і терміновість задачі
+|-
+| Баги і задачі
+| Основний журнал проблем, запитів і робіт
+|-
+| Виконавці
+| Розробники, тестувальники або інші відповідальні особи
+|-
+| Постановники
+| Користувачі, які створили задачу
+|-
+| Файли
+| Скриншоти, логи, відео, документи, технічні матеріали
+|-
+| Коментарі
+| Обговорення задачі та уточнення
+|-
+| Журнал подій
+| Історія зміни статусів, виконавців, пріоритетів і коментарів
+|-
+| Нотифікації
+| Повідомлення про створення, зміну або прострочення задачі
+|-
+| Звіти
+| Статистика по проєктах, виконавцях, статусах і строках
+|}
-=== 1. Структура довідників ===
+== Довідник «Проєкти» ==
-==== Довідник «Проекти» ====
+Довідник проєктів використовується для групування багів і задач.
-Поля довідника:
+Проєктом може бути ERP-модуль, сайт, мобільний додаток, клієнтське впровадження, внутрішня система або окремий напрям розробки.
-* назва проекту;
+== Поля проєкту ==
-* тип проекту:
-** ERP;
-** мобільний додаток;
-** сайт;
-** інше;
-* керівник проекту.
-==== Довідник «Типи задач» ====
+{| class="wikitable" style="width:100%;"
+! Поле
+! Опис
+|-
+| Назва проєкту
+| Назва продукту, модуля або клієнтського проєкту
+|-
+| Тип проєкту
+| ERP, мобільний додаток, сайт, інтеграція, інше
+|-
+| Керівник проєкту
+| Відповідальний за проєкт
+|-
+| Клієнт
+| Опціонально, якщо проєкт клієнтський
+|-
+| Статус
+| Активний, завершений, призупинений, архівний
+|-
+| Опис
+| Короткий опис проєкту
+|}
-Типи задач:
+== Приклади типів проєктів ==
-* помилка — Bug;
+* ERP;
-* поліпшення — Improvement;
+* мобільний додаток;
-* нова функція — Feature Request;
+* сайт;
-* технічне завдання — Task.
+* інтернет-магазин;
+* CRM;
+* інтеграція;
+* внутрішня система;
+* клієнтське впровадження.
-==== Довідник «Статуси» ====
+== Довідник «Типи задач» ==
-Статуси:
+Тип задачі допомагає зрозуміти природу роботи.
-* відкрита;
+== Типи задач ==
-* у процесі;
-* на тестуванні;
-* вирішено;
-* закрито;
-* скасовано.
-==== Довідник «Пріоритети» ====
+{| class="wikitable" style="width:100%;"
+! Тип
+! Значення
+|-
+| Bug
+| Помилка або некоректна поведінка системи
+|-
+| Improvement
+| Покращення існуючої функції
+|-
+| Feature Request
+| Запит на нову функцію
+|-
+| Task
+| Технічна або організаційна задача
+|-
+| Support
+| Задача підтримки клієнта
+|-
+| Documentation
+| Задача по документації
+|}
-Пріоритети:
+<div style="border:2px solid #f57c00; background:#fff3e0; padding:14px; margin:16px 0;">
+'''Важливо.''' Тип задачі має впливати на аналіз. Баги показують якість продукту, Feature Request — розвиток функціоналу, а Task — технічні або організаційні роботи.
+</div>
-* низький;
+== Довідник «Статуси» ==
-* середній;
-* високий;
-* критичний.
-=== 2. Журнал «Баги і задачі» ===
+Статуси описують життєвий цикл задачі.
-==== Колонки журналу ====
+== Типові статуси ==
-* номер задачі;
+{| class="wikitable" style="width:100%;"
-* назва задачі;
+! Статус
-* тип задачі;
+! Значення
-* проект;
+|-
-* пріоритет;
+| Відкрита
-* статус;
+| Задачу створено, але ще не взято в роботу
-* відповідальний;
+|-
-* дата створення;
+| Призначено
-* дата оновлення.
+| Задачу передано конкретному виконавцю
+|-
+| У процесі
+| Виконавець працює над задачею
+|-
+| Очікує уточнення
+| Потрібна додаткова інформація
+|-
+| На тестуванні
+| Задачу передано тестувальнику для перевірки
+|-
+| Повернуто на доопрацювання
+| Тестування виявило, що проблема не вирішена повністю
+|-
+| Вирішено
+| Виконавець виправив задачу
+|-
+| Закрито
+| Задачу перевірено і прийнято
+|-
+| Скасовано
+| Задача більше не актуальна
+|}
+== Довідник «Пріоритети» ==
+Пріоритет показує, наскільки важливо швидко вирішити задачу.
+{| class="wikitable" style="width:100%;"
+! Пріоритет
+! Значення
+|-
+| Низький
+| Некритична задача, може чекати
+|-
+| Середній
+| Звичайна робоча задача
+|-
+| Високий
+| Важлива задача, яка впливає на роботу користувачів
+|-
+| Критичний
+| Блокує роботу системи, клієнта або ключового бізнес-процесу
+|}
+== Журнал «Баги і задачі» ==
+Журнал багів і задач є головним робочим екраном модуля.
+== Колонки журналу ==
+{| class="wikitable" style="width:100%;"
+! Колонка
+! Опис
+|-
+| Номер задачі
+| Унікальний номер задачі
+|-
+| Назва задачі
+| Коротка назва проблеми або роботи
+|-
+| Тип задачі
+| Bug, Improvement, Feature Request, Task
+|-
+| Проєкт
+| До якого проєкту належить задача
+|-
+| Пріоритет
+| Низький, середній, високий, критичний
+|-
+| Статус
+| Поточний стан задачі
+|-
+| Відповідальний
+| Виконавець задачі
+|-
+| Постановник
+| Хто створив задачу
+|-
+| Дата створення
+| Коли задача була створена
+|-
+| Дата оновлення
+| Коли задача змінювалася востаннє
+|-
+| Планова дата вирішення
+| До якої дати задачу потрібно вирішити
+|}
+== Функціональність журналу ==
+Журнал має підтримувати:
+* пошук по назві задачі;
+* пошук по опису;
+* пошук по номеру задачі;
+* фільтрацію за проєктом;
+* фільтрацію за типом задачі;
+* фільтрацію за статусом;
+* фільтрацію за пріоритетом;
+* фільтрацію за виконавцем;
+* фільтрацію за постановником;
+* фільтрацію за датою створення;
+* фільтрацію за строком вирішення;
+* масову зміну статусу;
+* масове закриття задач;
+* експорт списку задач.
+== Форма створення задачі ==
+Форма створення задачі повинна дозволяти швидко зафіксувати помилку або технічну задачу.
+== Поля форми задачі ==
+{| class="wikitable" style="width:100%;"
+! Поле
+! Опис
+|-
+| Проєкт
+| Вибір із довідника проєктів
+|-
+| Тип задачі
+| Bug, Improvement, Feature Request, Task
+|-
+| Назва задачі
+| Короткий заголовок
+|-
+| Опис задачі
+| Детальний опис проблеми або пропозиції
+|-
+| Кроки відтворення
+| Для багів: що потрібно зробити, щоб побачити помилку
+|-
+| Очікуваний результат
+| Як система повинна працювати
+|-
+| Фактичний результат
+| Що відбувається насправді
+|-
+| Пріоритет
+| Важливість задачі
+|-
+| Відповідальний
+| Виконавець або команда
+|-
+| Планова дата вирішення
+| Орієнтовний строк виконання
+|-
+| Файли
+| Скриншоти, логи, відео, документи
+|}
+== Опис багу ==
+Для задач типу '''Bug''' бажано обов’язково вказувати:
+* де виникає помилка;
+* які дії виконував користувач;
+* що очікувалося;
+* що сталося фактично;
+* чи повторюється помилка;
+* посилання на сторінку або документ;
+* скриншот або лог помилки.
+<div style="border:3px solid #1565c0; background:#e3f2fd; padding:14px; margin:16px 0;">
+'''Практичний сенс.''' Добре описаний баг економить час розробника. Якщо є кроки відтворення, очікуваний і фактичний результат, проблему легше знайти, виправити і перевірити.
+</div>
+== Прикріплення файлів ==
+Модуль має дозволяти прикріплювати файли до задачі.
-==== Функціонал ====
+== Типові вкладення ==
-* пошук по назві, опису, проекту;
+* скриншоти;
-* фільтрація за:
+* відео помилки;
-** статусами;
+* логи;
-** пріоритетами;
+* дампи;
-** виконавцями;
+* документи;
-* масове закриття задач.
+* технічні завдання;
+* приклади файлів для імпорту;
+* макети;
+* посилання на зовнішні ресурси.
-=== 3. Створення задачі ===
+== Коментарі до задачі ==
-==== Форма створення задачі ====
+Картка задачі повинна містити коментарі.
-Поля форми:
+Коментарі потрібні для:
-* проект;
+* уточнення деталей;
-* тип задачі;
+* відповіді розробника;
-* назва задачі;
+* зауважень тестувальника;
-* опис задачі — детальний опис проблеми чи пропозиції;
+* опису виконаних дій;
-* пріоритет;
+* фіксації причин затримки;
-* відповідальний співробітник;
+* пояснення рішення.
-* дата планового вирішення;
-* прикріплення файлів:
-** скріншоти;
-** логи.
-=== 4. Життєвий цикл багу ===
+== Життєвий цикл багу ==
 Типовий маршрут багу:
@@ Рядок 112: / Рядок 412: @@
 </blockquote>
-Функціонал:
+Розширений маршрут:
+<blockquote>
+Відкрита → Призначено → У процесі → На тестуванні → Повернуто на доопрацювання → У процесі → На тестуванні → Вирішено → Закрито
+</blockquote>
+== Зміна статусу ==
+Система повинна дозволяти змінювати статус задачі через AJAX без перезавантаження сторінки.
+При кожній зміні статусу потрібно зберігати:
+* хто змінив статус;
+* попередній статус;
+* новий статус;
+* дату і час;
+* коментар, якщо він був вказаний.
+<div style="border:3px solid #b71c1c; background:#ffebee; padding:14px; margin:16px 0;">
+'''Критично.''' Статус не можна змінювати без історії. Якщо немає журналу подій, неможливо зрозуміти, хто взяв задачу в роботу, хто передав її на тестування і хто закрив.
+</div>
+== Повернення з тестування ==
-* можливість повернення задачі на попередній етап у разі невдалого тестування;
+Якщо тестувальник бачить, що проблема не вирішена, задача повинна повертатися на доопрацювання.
-* переведення між статусами через AJAX без перезавантаження сторінки.
-=== 5. Повідомлення і нотифікації ===
+При поверненні потрібно вказати:
-Види повідомлень:
+* причину повернення;
+* що саме не працює;
+* нові кроки відтворення, якщо вони змінилися;
+* скриншот або лог, якщо потрібно.
+== Нотифікації ==
+Модуль має підтримувати повідомлення користувачам.
+== Канали повідомлень ==
+Можливі канали:
 * email;
-* внутрішні повідомлення.
+* внутрішні повідомлення K2 ERP;
+* Telegram або інший месенджер, якщо інтеграція доступна.
-Події для нотифікацій:
+== Події для нотифікацій ==
-* коли задача створена;
+Повідомлення бажано надсилати, коли:
-* коли змінено статус задачі;
-* коли задача затримується і не закрита у встановлений строк.
-=== 6. Звіти ===
+* створено нову задачу;
+* задачу призначено виконавцю;
+* змінено статус;
+* додано коментар;
+* задачу повернуто з тестування;
+* задача прострочена;
+* наближається планова дата вирішення;
+* задачу закрито.
-==== Звіт «Статистика по проекту» ====
+== Контроль строків ==
+Система повинна контролювати задачі, які не закриті у встановлений строк.
+Задача вважається простроченою, якщо:
+* планова дата вирішення менша за поточну дату;
+* статус не дорівнює '''«Закрито»''' або '''«Скасовано»'''.
+Прострочені задачі потрібно виділяти в журналі та звітах.
+== Масові дії ==
+Журнал має підтримувати масові дії.
+Можливі масові дії:
+* призначити виконавця;
+* змінити пріоритет;
+* змінити статус;
+* закрити задачі;
+* перенести задачі в інший проєкт;
+* експортувати вибрані задачі.
+Масові дії мають бути доступні лише користувачам із відповідними правами.
+== Звітність ==
+== Звіт «Статистика по проєкту» ==
+Звіт показує стан задач у межах одного або кількох проєктів.
+У звіті потрібно відображати:
+* проєкт;
 * кількість відкритих задач;
+* кількість задач у роботі;
+* кількість задач на тестуванні;
+* кількість вирішених задач;
 * кількість закритих задач;
+* кількість прострочених задач;
 * середній час вирішення задачі.
-==== Звіт «Продуктивність розробників» ====
+== Звіт «Продуктивність розробників» ==
+Звіт показує результативність виконавців за період.
+У звіті потрібно відображати:
+* виконавця;
+* кількість призначених задач;
+* кількість вирішених задач;
+* кількість закритих задач;
+* кількість повернень з тестування;
+* середній час вирішення;
+* кількість критичних задач;
+* кількість прострочених задач.
+== Звіт «Якість продукту» ==
+Звіт допомагає аналізувати стабільність продукту.
+У звіті потрібно показувати:
+* кількість багів по проєктах;
+* кількість критичних багів;
+* кількість повторних багів;
+* кількість багів, повернутих з тестування;
+* динаміку відкритих і закритих багів;
+* частку багів серед усіх задач.
+== Звіт «Прострочені задачі» ==
+Звіт показує задачі, які не були вирішені вчасно.
+У звіті потрібно відображати:
+* номер задачі;
+* назву;
+* проєкт;
+* виконавця;
+* пріоритет;
+* планову дату вирішення;
+* кількість днів прострочення;
+* поточний статус.
+== Звіт «Повернення з тестування» ==
+Звіт показує задачі, які були повернуті на доопрацювання.
+У звіті потрібно відображати:
+* задачу;
+* проєкт;
+* виконавця;
+* тестувальника;
+* кількість повернень;
+* причину останнього повернення;
+* статус.
+== Друк і експорт ==
+Модуль має підтримувати експорт даних.
+Формати:
+* Excel;
+* PDF.
+Експортувати потрібно:
+* список задач;
+* статистику по проєктах;
+* продуктивність виконавців;
+* прострочені задачі;
+* звіт по якості продукту.
+== AJAX-інтерактив ==
+Інтерфейс має працювати швидко та без зайвого перезавантаження сторінок.
+Через AJAX мають працювати:
+* створення задачі;
+* вибір проєкту;
+* вибір виконавця;
+* зміна статусу;
+* зміна пріоритету;
+* додавання коментаря;
+* прикріплення файлу;
+* повернення з тестування;
+* масове закриття задач;
+* фільтрація журналу;
+* оновлення звітів.
+== Логування змін ==
+Модуль повинен фіксувати всі важливі зміни.
+Журнал подій має зберігати:
+* хто створив задачу;
+* хто змінив назву або опис;
+* хто змінив статус;
+* хто змінив пріоритет;
+* хто змінив виконавця;
+* хто додав коментар;
+* хто прикріпив файл;
+* хто передав на тестування;
+* хто повернув задачу на доопрацювання;
+* хто закрив задачу;
+* дату й час зміни;
+* старе та нове значення, якщо це можливо.
+== Права доступу ==
-* скільки багів і задач вирішив кожен розробник за період.
+Модуль має підтримувати розмежування прав.
+{| class="wikitable" style="width:100%;"
+! Роль
+! Можливості
+|-
+| Користувач
+| Створює задачі, додає коментарі, переглядає свої задачі
+|-
+| Розробник
+| Бере задачі в роботу, змінює робочі статуси, додає рішення
+|-
+| Тестувальник
+| Перевіряє задачі, повертає на доопрацювання або підтверджує вирішення
+|-
+| Керівник проєкту
+| Призначає виконавців, контролює строки, пріоритети і звіти
+|-
+| Адміністратор
+| Налаштовує проєкти, статуси, типи задач, права і службові параметри
+|}
 == Технічні вимоги ==
-{| class="wikitable"
+{| class="wikitable" style="width:100%;"
 ! Параметр
 ! Опис
@@ Рядок 151: / Рядок 657: @@
 | K2 Cloud ERP на Python або PHP
 |-
-| БД
+| База даних
 | PostgreSQL або MySQL
 |-
 | Фронтенд
-| HTML5, JavaScript, AJAX, Axios або Fetch API
+| HTML5, JavaScript
+|-
+| AJAX
+| Axios або Fetch API
 |-
 | UI-компоненти
 | DataTables, Select2
 |-
-| Друк
+| Файли
-| Експорт списку задач у Excel або PDF
+| Завантаження скриншотів, логів і документів
+|-
+| Експорт
+| Excel або PDF для списків і звітів
 |}
-== Критерії оцінки ==
+== Рекомендовані сутності бази даних ==
+Для реалізації задачі доцільно передбачити такі сутності:
-{| class="wikitable"
+* проєкти;
+* типи проєктів;
+* типи задач;
+* статуси задач;
+* пріоритети;
+* задачі;
+* коментарі задач;
+* файли задач;
+* користувачі;
+* ролі користувачів;
+* виконавці;
+* тестувальники;
+* журнал подій;
+* повернення з тестування;
+* нотифікації;
+* звіти;
+* права доступу.
+== Практичне завдання ==
+У межах атестації потрібно продемонструвати робочий сценарій.
+Мінімальний сценарій:
+# створити проєкт;
+# створити типи задач;
+# створити статуси;
+# створити пріоритети;
+# створити задачу типу '''Bug''';
+# додати опис, кроки відтворення, очікуваний і фактичний результат;
+# прикріпити скриншот або лог;
+# призначити відповідального виконавця;
+# змінити статус на '''«У процесі»''';
+# додати коментар виконавця;
+# передати задачу на тестування;
+# повернути задачу на доопрацювання;
+# повторно передати задачу на тестування;
+# перевести задачу в статус '''«Вирішено»''';
+# закрити задачу після перевірки;
+# перевірити журнал подій;
+# створити задачу з простроченим строком;
+# перевірити підсвітку прострочення;
+# виконати фільтрацію за статусом, пріоритетом і виконавцем;
+# виконати масове закриття тестових задач;
+# сформувати звіт статистики по проєкту;
+# сформувати звіт продуктивності розробників;
+# сформувати звіт прострочених задач;
+# експортувати список задач у Excel або PDF.
+== Критерії оцінювання ==
+{| class="wikitable" style="width:100%;"
 ! Критерій
 ! Бали
+! Що перевіряється
 |-
 | Реалізація журналу багів і задач
 | 20
+| Проєкти, задачі, типи, статуси, пріоритети, виконавці, фільтри, пошук
 |-
 | Управління статусами і пріоритетами
 | 20
+| Життєвий цикл, передача в роботу, тестування, повернення, закриття, історія змін
 |-
 | Створення задач з прикріпленням файлів
 | 20
+| Опис, кроки відтворення, скриншоти, логи, коментарі, вкладення
 |-
-| Формування звітів по проектам і виконавцям
+| Формування звітів по проєктах і виконавцях
 | 20
+| Статистика по проєктах, продуктивність, прострочення, якість продукту
 |-
 | Інтерактивність через AJAX і повідомлення
 | 20
+| AJAX-створення, зміна статусів, коментарі, фільтри, нотифікації
+|-
+! Разом
+! 100
+! Максимальна оцінка
 |}
+== Шкала оцінювання ==
+{| class="wikitable" style="width:100%;"
+! Бали
+! Рівень
+! Опис
+|-
+| 90–100
+| Відмінно
+| Модуль повністю працює: задачі, баги, статуси, пріоритети, файли, тестування, повернення, нотифікації, звіти й AJAX реалізовані коректно
+|-
+| 75–89
+| Добре
+| Основна логіка працює, є незначні недоліки, які не руйнують процес багтрекінгу
+|-
+| 60–74
+| Зараховано
+| Базовий сценарій працює, але частина функцій реалізована неповно або потребує доопрацювання
+|-
+| 0–59
+| Не зараховано
+| Відсутня критична логіка: задачі, статуси, виконавці, файли, тестування, журнал подій або звіти
+|}
+== Критичні помилки ==
+Критичними помилками вважаються ситуації, коли:
+* неможливо створити проєкт;
+* неможливо створити задачу;
+* задача не має типу;
+* задача не має статусу;
+* задача не має пріоритету;
+* задача не має виконавця після призначення;
+* неможливо прикріпити файл, якщо ця функція заявлена;
+* статус змінюється без запису в журналі подій;
+* неможливо повернути задачу з тестування на доопрацювання;
+* прострочені задачі не визначаються;
+* фільтрація за статусом, пріоритетом або виконавцем не працює;
+* масове закриття задач не перевіряє права користувача;
+* звіти не відповідають фактичним задачам;
+* нотифікації не надсилаються при призначенні задачі, якщо вони заявлені;
+* зміни задачі не логуються.
+<div style="border:3px solid #b71c1c; background:#ffebee; padding:14px; margin:16px 0;">
+'''Умова складання.''' Завдання не може бути зараховане, якщо система не дозволяє пройти базовий цикл багтрекера: проєкт → задача → виконавець → робота → тестування → повернення або вирішення → закриття → звіт.
+</div>
+== Очікуваний результат ==
+У результаті виконання атестаційного завдання має бути створений модуль багтрекінгу в K2 ERP.
+Модуль має підтримувати проєкти, типи задач, статуси, пріоритети, журнал багів і задач, створення задач із файлами, призначення виконавців, життєвий цикл багу, тестування, повернення на доопрацювання, масові дії, нотифікації, звіти, експорт, AJAX-інтерактив і логування змін.
 == Примітка ==
-Багтрекер критично важливий для команд розробки будь-якого рівня — від маленьких стартапів до великих корпоративних ERP-проектів.
+Багтрекер критично важливий для команд розробки будь-якого рівня — від маленьких стартапів до великих корпоративних ERP-проєктів.
+Правильно побудований багтрекер дозволяє підвищити якість програмного продукту, пришвидшити реакцію на проблеми, бачити реальне навантаження команди, контролювати строки та аналізувати причини повторних помилок.
+== Коротко ==
+{| class="wikitable" style="width:100%;"
+! Питання
+! Відповідь
+|-
+| Що потрібно створити?
+| Модуль багтрекінгу для обліку помилок і задач розробки
+|-
+| Які довідники потрібні?
+| Проєкти, типи задач, статуси, пріоритети, користувачі
+|-
+| Який головний журнал?
+| Баги і задачі
+|-
+| Який типовий життєвий цикл?
+| Створено → Призначено → В роботі → На тестуванні → Вирішено → Закрито
+|-
+| Що має містити баг?
+| Опис, кроки відтворення, очікуваний і фактичний результат, файли, статус, виконавця
+|-
+| Що важливо для тестування?
+| Можливість повернення задачі на доопрацювання з коментарем
+|-
+| Які звіти потрібні?
+| Статистика по проєктах, продуктивність розробників, прострочені задачі, якість продукту
+|-
+| Що є критичною вимогою?
+| Повний цикл: задача → робота → тестування → закриття з історією змін
+|}
+== Див. також ==
-Правильна побудова багтрекера дозволяє:
+* [[K2 Cloud ERP|K2 ERP]]
+* [[K2 ERP]]
+* [[Атестаційні завдання K2 ERP]]
+* [[Багтрекер]]
+* [[Управління задачами]]
+* [[HelpDesk]]
+* [[Проєктний менеджмент]]
+* [[Тестування]]
+* [[QA]]
+* [[Розробка програмного забезпечення]]
+* [[Нотифікації]]
+* [[AJAX]]
-* суттєво підвищити якість програмного продукту;
+[[Категорія:K2 ERP]]
-* збільшити швидкість реакції на проблеми.
+[[Категорія:Атестаційні завдання K2]]
+[[Категорія:Багтрекер]]
+[[Категорія:Розробка програмного забезпечення]]
+[[Категорія:QA]]
+[[Категорія:Управління задачами]]
+[[Категорія:Корпоративна Wiki]]

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