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

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

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

компонент багтрекінгу: обліковий облік і керування помилками та задачами розробки. 100 Прострочені задачі потрібно виділяти в журналі та звітах. SEO-опис

Примітка

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

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

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

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

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

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

Назва задача

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

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

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

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

! Тип

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

! * створено нову задачу;

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

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

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

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

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

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

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

* виконавця; кількість призначених задач; кількість вирішених задач; кількість закритих задач; кількість повернень з тестування; середній час вирішення; кількість критичних задач; кількість прострочених задач. # користувач системи створює задачу; вказує проєкт, тип, SEO-опис і пріоритет; додає скриншоти, логи або інші файли; призначається відповідальний виконавець; виконавець бере задачу в роботу; після виправлення задача передається на тестування; тестувальник перевіряє результат; якщо проблема не вирішена, задача повертається в роботу; якщо все функціонує коректно, задача переводиться в статус «Вирішено» або «Закрито»; платформа зберігає історію змін; інформаційні дані потрапляють у звіти по якості та продуктивності.== Контроль строків == компонент має забезпечувати повний цикл роботи з багами та задачами розробки: від створення звернення або помилки до призначення виконавця. \| SEO-опис, кроки відтворення, очікуваний і фактичний результат, файли, статус, виконавця
Реалізація журналу багів і задач	20	Проєкти, задачі, типи, статуси, пріоритети, виконавці, фільтри, пошук
керування статусами і пріоритетами	20	Життєвий цикл, передача в роботу, тестування, повернення, закриття, історія продукту змін
Створення задач з прикріпленням файлів	20	SEO-опис, кроки відтворення, скриншоти, логи, коментарі, вкладення
Формування звітів по проєктах і виконавцях	20	Статистика по проєктах, продуктивність, прострочення, якість продукту
Інтерактивність через AJAX і повідомлення	20	AJAX-створення, зміна статусів, коментарі, фільтри, нотифікації
Що критично для тестування? список задач; статистику по проєктах; продуктивність виконавців; прострочені задачі; звіт по якості продукту. компонент має підтримувати експорт даних. ! * ERP; мобільний додаток; сайт; інтернет-магазин; CRM; інтеграційні функції ERP; внутрішня платформа; клієнтське впровадження. \| компонент багтрекінгу для обліку помилок і задач розробки
Які довідники потрібні? Це платформа контролю якості, де кожна проблема має SEO-опис, проєкт, тип, пріоритет, відповідального, статус, історію змін і зрозумілий результат перевірки. ! ! Поле
Bug	Помилка або некоректна поведінка системи
Improvement	Покращення існуючої функції
Feature Request	Запит на нову функцію
Task	Технічна або організаційна задача
Support	Задача підтримки клієнта
Documentation	Задача по документації

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

Можливі канали: ! * уточнення деталей;

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

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

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

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

|}

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

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

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

Форма створення задачі повинна дозволяти оперативно зафіксувати помилку або технічну задачу. | Створено → Призначено → В роботі → На тестуванні → Вирішено → Закрито |- | Що має містити баг? Значення

задачу;
проєкт;
виконавця;
тестувальника;
кількість повернень;
причину останнього повернення;
статус. Звіт показує результативність виконавців за період. * проєкти;
типи проєктів;
типи задач;
статуси задач;
пріоритети;
задачі;
коментарі задач;
файли задач;
користувачі;
ролі користувачів;
виконавці;
тестувальники;
журнал подій;
повернення з тестування;
нотифікації;
звіти;
права доступу. Умова складання. задача не здатна бути зараховане, якщо платформа не дає можливість пройти базовий цикл багтрекера: проєкт → задача → виконавець → робота → тестування → повернення або вирішення → закриття → звіт. ! {| class="wikitable" style="width:100%;"

через Тип задачі користувачі можуть зрозуміти природу роботи.

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

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

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

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

! Призначення Типовий маршрут багу:

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

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

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

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

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

* від тестувальників; від клієнтів; від менеджерів; від розробників; із системи підтримки; із внутрішнього аудиту; після демонстрацій або впроваджень.	провідний принцип. Багтрекер — це не без зусиль список помилок. ! У звіті потрібно відображати: Можливі масові дії: Масові дії Реальний бізнес-контекст Журнал має підтримувати:
Назва проєкту	Назва продукту, модуля або клієнтського проєкту
Тип проєкту	ERP, мобільний додаток, сайт, інтеграційні функції ERP, інше
Керівник проєкту	Відповідальний за проєкт
клієнт ERP	Опціонально, якщо проєкт клієнтський
Статус	Активний, завершений, призупинений, архівний
SEO-опис	Короткий SEO-опис проєкту

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

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

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

!

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

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

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

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

Масові дії мають бути доступні лише користувачам із відповідними правами. | Повний цикл: задача → робота → тестування → закриття з історією змін

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

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

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

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

хто змінив назву або SEO-опис;
хто змінив статус;
хто змінив пріоритет;
хто змінив виконавця;
хто додав коментар;
хто прикріпив файл;
хто передав на тестування;
хто повернув задачу на доопрацювання;
хто закрив задачу;
дату й час зміни;
старе та нове значення, якщо це можливо. {| class="wikitable" style="width:100%;"

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

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

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

хто змінив статус;
попередній статус;
новий статус;
дату і час;
коментар, якщо він був вказаний. Це призводить до повторних помилок, втрати відповідальності, зриву строків і погіршення якості продукту. SEO-опис

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

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

SEO-опис багу

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

class="wikitable" style="width:100%;" номер задачі; назву; проєкт; виконавця; пріоритет; планову дату вирішення; кількість днів прострочення; поточний статус. ! Бали Нотифікації Картка задачі повинна містити коментарі. У межах атестації потрібно продемонструвати робочий сценарій. Такі задачі можуть надходити з різних джерел: компонент має підтримувати проєкти, типи задач, статуси, пріоритети, журнал багів і задач, створення задач із файлами, призначення виконавців, життєвий цикл багу, тестування, повернення на доопрацювання, масові дії, нотифікації, звіти, експорт, AJAX-інтерактив і логування змін. SEO-опис планова дата вирішення менша за поточну дату; статус не дорівнює «Закрито» або «Скасовано». Рівень
Що потрібно створити? Якщо виступає як кроки відтворення, очікуваний і фактичний результат, проблему легше знайти, виправити і перевірити. Колонка	-	Номер задачі	Унікальний номер задачі
Назва задачі	Коротка назва проблеми або роботи
Тип задачі	Bug, Improvement, Feature Request, Task
Проєкт	До якого проєкту належить задача
Пріоритет	Низький, середній, високий, критичний
Статус	Поточний стан задачі
Відповідальний	Виконавець задачі
Постановник	Хто створив задачу
Дата створення	Коли задача була розроблена
Дата оновлення версій	Коли задача змінювалася востаннє
Планова дата вирішення	До якої дати задачу потрібно вирішити

платформа повинна дозволяти:

Мета задача

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

email;
внутрішні повідомлення K2 ERP;
Telegram або інший месенджер, якщо інтеграційні функції ERP доступна. Коротко. Потрібно реалізувати багтрекер, який дає можливість фіксувати баги, задачі, покращення і нові функції, призначати відповідальних, змінювати статуси, додавати файли та логи, повертати задачі з тестування, надсилати повідомлення і формувати звіти по проєктах та виконавцях. {| class="wikitable" style="width:100%;"

! Окремо варто відзначити виправлення, тестування, закриття і аналізу ефективності команди.== Зміна статусу == Інтерфейс має працювати оперативно та без зайвого перезавантаження сторінок. | Можливість повернення задачі на доопрацювання з коментарем |- | Які звіти потрібні? * проєкт;

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

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

PDF. | Статистика по проєктах, продуктивність розробників, прострочені задачі, якість продукту

|- | Що виступає як критичною вимогою? функції ERP

Коротко

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

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

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

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

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

створити проєкт;
створити типи задач;
створити статуси;
створити пріоритети;
створити задачу типу Bug;
додати SEO-опис, кроки відтворення, очікуваний і фактичний результат;
прикріпити скриншот або лог;
призначити відповідального виконавця;
змінити статус на «У процесі»;
додати коментар виконавця;
передати задачу на тестування;
повернути задачу на доопрацювання;
повторно передати задачу на тестування;
перевести задачу в статус «Вирішено»;
закрити задачу після перевірки;
перевірити журнал подій;
створити задачу з простроченим строком;
перевірити підсвітку прострочення;
виконати фільтрацію за статусом, пріоритетом і виконавцем;
виконати масове закриття тестових задач;
сформувати звіт статистики по проєкту;
сформувати звіт продуктивності розробників;
сформувати звіт прострочених задач;
експортувати список задач у Excel або PDF. Якщо тестувальник бачить, що проблема не вирішена, задача повинна повертатися на доопрацювання. Питання

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

Поля проєкту

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

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

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

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

Команді потрібно не загубити жодну задачу, правильно визначити її пріоритет, призначити відповідального, проконтролювати строк, перевірити результат і мати історію всіх змін. Багтрекер — це практична задача; так само реалізовано технічних задач, побажань, доопрацювань, тестування, відповідальних виконавців, статусів, пріоритетів і звітності по якості розробки виступає ключовою рисою перевірки навичок розробника або впроваджувача K2 ERP у створенні модуля обліку помилок забезпечується через Атестаційне задача K2 ERP. Значення |- | Відкрита | Задачу створено, але ще не взято в роботу |- | Призначено | Задачу передано конкретному виконавцю |- | У процесі | Виконавець функціонує над задачею |- | Очікує уточнення | Потрібна додаткова інформаційні матеріали |- | На тестуванні | Задачу передано тестувальнику для перевірки |- | Повернуто на доопрацювання | Тестування виявило, що проблема не вирішена на 100% |- | Вирішено | Виконавець виправив задачу |- | Закрито | Задачу перевірено і прийнято |- | Скасовано | Задача більше не актуальна |}

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

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

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

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

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

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

!== Див. так само ==
Практичний сенс. Добре описаний баг економить час розробника. Формати:
Без багтрекера задачі розпорошуються по месенджерах, листах і усних домовленостях. Якщо немає журналу подій, неможливо зрозуміти, хто взяв задачу в роботу, хто передав її на тестування і хто закрив.

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

! SEO-опис

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

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

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

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

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

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

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