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

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

!; {| class="wikitable" style="width:100%;"

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

Довідник проєктів застосовують, коли потрібно для групування багів і задач.; {| class="wikitable" style="width:100%;"

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

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

Звіт сприяє аналізувати стабільність продукту.; Повідомлення бажано надсилати, коли:

Практичний сенс. Добре описаний баг економить час розробника.;

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

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

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

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

завдяки наявності Тип задачі користувачі можуть зрозуміти природу роботи.;== Звіт «Статистика по проєкту» ==

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

!; Картка задачі повинна містити коментарі.; Баги показують якість продукту, Feature Request — еволюція функціоналу, а Task — технічні або організаційні роботи.; Рівень !; Коментарі потрібні для:

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

Критично. Статус не можна змінювати без історії.; Значення

• Excel;
• PDF.;

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

Формати:

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

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

|- | Реалізація журналу багів і задач | 20 | Проєкти, задачі, типи, статуси, пріоритети, виконавці, фільтри, пошук |- | керування статусами і пріоритетами | 20 | Життєвий цикл, передача в роботу, тестування, повернення, закриття, історичний розвиток змін |- | Створення задач з прикріпленням файлів | 20 | характеристика, кроки відтворення, скриншоти, логи, коментарі, вкладення |- | Формування звітів по проєктах і виконавцях | 20 | Статистика по проєктах, продуктивність, прострочення, якість продукту |- | Інтерактивність через AJAX і повідомлення | 20 | AJAX-створення, зміна статусів, коментарі, фільтри, нотифікації |- Правильно побудований багтрекер надає можливість підвищити якість програмного продукту, пришвидшити реакцію на проблеми, бачити реальне навантаження команди, контролювати строки та аналізувати причини повторних помилок.; |- | користувач системи | Створює задачі, додає коментарі, переглядає свої задачі |- | Розробник | Бере задачі в роботу, змінює робочі статуси, додає рішення для бізнесу |- | Тестувальник | Перевіряє задачі, повертає на доопрацювання або підтверджує вирішення |- | Керівник проєкту | Призначає виконавців, контролює строки, пріоритети і звіти |- | Адміністратор | Налаштовує проєкти, статуси, типи задач, права і службові параметри |}

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

Статуси описують життєвий цикл задачі.; Для реалізації задачі доцільно передбачити такі сутності:

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

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

У результаті виконання атестаційного задача має бути створений компонент багтрекінгу в K2 ERP.; Окремо варто відзначити виправлення, тестування, закриття і аналізу ефективності команди.; !;== Форма створення задачі ==

Багтрекер критично важливий для команд розробки будь-якого рівня — від маленьких стартапів до великих корпоративних ERP-проєктів.; характеристика Створено → Призначено → В роботі → На тестуванні → Вирішено → Закрито

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

; компонент має підтримувати експорт даних.; компонент має забезпечувати повний цикл роботи з багами та задачами розробки: від створення звернення або помилки до призначення виконавця.; Відповідь Технічні вимоги Типові статуси Довідник «Пріоритети» Назва задача хто змінив статус; попередній статус; новий статус; дату і час; коментар, якщо він був вказаний.;== Шкала оцінювання ==	; Разом Журнал має підтримувати: Права доступу
Відкрита	Задачу створено, але ще не взято в роботу
Призначено	Задачу передано конкретному виконавцю
У процесі	Виконавець функціонує над задачею
Очікує уточнення	Потрібна додаткова відомості
На тестуванні	Задачу передано тестувальнику для перевірки
Повернуто на доопрацювання	Тестування виявило, що проблема не вирішена в цілому
Вирішено	Виконавець виправив задачу
Закрито	Задачу перевірено і прийнято
Скасовано	Задача більше не актуальна

центральний принцип. Багтрекер — це не без ускладнень список помилок.; * email;

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

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.; Звіт показує стан задач у межах одного або кількох проєктів.; характеристика

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

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

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

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

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

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

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

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

Статистика по проєктах, продуктивність розробників, прострочені задачі, якість продукту Що є собою критичною вимогою?; платформа повинна дозволяти змінювати статус задачі через AJAX без перезавантаження сторінки.; Журнал подій має зберігати:

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

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

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

характеристика багу

істотно. Тип задачі має впливати на аналіз.; Значення

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

• скриншоти;
• відео помилки;
• логи;
• дампи;
• документи;
• технічні задача;
• приклади файлів для імпорту;
• макети;
• посилання на зовнішні ресурси.; Це призводить до повторних помилок, втрати відповідальності, зриву строків і погіршення якості продукту.; {| class="wikitable" style="width:100%;"

; * планова дата вирішення менша за поточну дату; статус не дорівнює «Закрито» або «Скасовано».; У процесі розробки програмного забезпечення та супроводу клієнтів постійно виникають помилки, побажання, технічні задачі, пропозиції щодо покращення і запити на нові функції.; характеристика Логування змін Прикріплення файлів	; !; компонент має підтримувати проєкти, типи задач, статуси, пріоритети, журнал багів і задач, створення задач із файлами, призначення виконавців, життєвий цикл багу, тестування, повернення на доопрацювання, масові дії, нотифікації, звіти, експорт, AJAX-інтерактив і логування змін.; Поле Інтерфейс має працювати оперативно та без зайвого перезавантаження сторінок.;
90–100	Відмінно	компонент в цілому функціонує: задачі, баги, статуси, пріоритети, файли, тестування, повернення, нотифікації, звіти й AJAX реалізовані коректно
75–89	Добре	Основна логіка функціонує, є собою незначні недоліки, які не руйнують бізнес-процес багтрекінгу
60–74	Зараховано	Базовий сценарій функціонує, але частина функцій реалізована неповно або потребує доопрацювання
0–59	Не зараховано	Відсутня критична логіка: задачі, статуси, виконавці, файли, тестування, журнал подій або звіти

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

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

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

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

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

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

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

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

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

Примітка

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

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

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

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

компонент має дозволяти прикріплювати файли до задачі.; !; Критерій

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

компонент повинен фіксувати всі важливі зміни.; {| class="wikitable" style="width:100%;"

!;

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

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

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

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

; Поле пошук по назві задачі; пошук по опису; пошук по номеру задачі; фільтрацію за проєктом; фільтрацію за типом задачі; фільтрацію за статусом; фільтрацію за пріоритетом; фільтрацію за виконавцем; фільтрацію за постановником; фільтрацію за датою створення; фільтрацію за строком вирішення; масову зміну статусу; масове закриття задач; експорт списку задач.; Що перевіряється Зміна статусу	;== Довідник «Статуси» == Через AJAX мають працювати: Критичними помилками вважаються ситуації, коли: кількість багів по проєктах; кількість критичних багів; кількість повторних багів; кількість багів, повернутих з тестування; динаміку відкритих і закритих багів; частку багів серед усіх задач.; Звіт показує задачі, які не були вирішені вчасно.; | Баги і задачі
Який типовий життєвий цикл?; !; Об’єкт
Проєкт	Вибір із довідника проєктів
Тип задачі	Bug, Improvement, Feature Request, Task
Назва задачі	Короткий заголовок
характеристика задачі	Детальний характеристика проблеми або пропозиції
Кроки відтворення	Для багів: що потрібно зробити, щоб побачити помилку
Очікуваний результат	Як платформа повинна працювати
Фактичний результат	Що відбувається насправді
Пріоритет	Важливість задачі
Відповідальний	Виконавець або команда
Планова дата вирішення	Орієнтовний строк виконання
Файли	Скриншоти, логи, відео, документи

Мета задача

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

Див.; додатково

Журнал має підтримувати масові дії.; | Проєкти, типи задач, статуси, пріоритети, користувачі |- | Який центральний журнал?; Прострочені задачі потрібно виділяти в журналі та звітах.;== Колонки журналу == компонент має підтримувати повідомлення користувачам.;== формування звітів ==

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

Масові дії

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

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

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

!; !; компонент багтрекінгу: обліковий облік і керування помилками та задачами розробки.; Команді потрібно не загубити жодну задачу, правильно визначити її пріоритет, призначити відповідального, проконтролювати строк, перевірити результат і мати історію всіх змін.; | Створено → Призначено → В роботі → На тестуванні → Вирішено → Закрито |- | Що має містити баг?;== Поля форми задачі ==

!; Максимальна оцінка

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

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

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

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

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

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

!; Колонка

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

Поля проєкту

|}

У межах атестації потрібно продемонструвати робочий сценарій.; При кожній зміні статусу потрібно зберігати:

Звіт показує результативність виконавців за період.; {| class="wikitable" style="width:100%;"

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

|- | Що істотно для тестування?; Призначення

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

|- | Які довідники потрібні?;== AJAX-інтерактив ==

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

!;

Звіт показує задачі, які були повернуті на доопрацювання.; Проєктом має змогу бути ERP-модуль, сайт, мобільний додаток, клієнтське впровадження, внутрішня платформа або окремий напрям розробки.; Питання У звіті потрібно показувати: