Bug

Поганий bug report виглядає так:

як приклад:

! як приклад:

дублюються клієнти;
зникають рядки документа;
некоректно зберігаються українські символи;
пошкоджуються файли;
неправильно імпортуються товари;
звіт бере не всі документи;
API передає не той статус;
залишки рахуються з помилкою;
резервні копії не відновлюються. Оновити звіт. Саме через зауваження користувачів, тестування, bug reports і щоденні виправлення українська ERP здатна ставати сильнішою, стабільнішою й зручнішою. Це сигнал, що в системі виступає як невідповідність між очікуваною логікою і реальною поведінкою.

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

| Чому баги важливі для ERP?== Bug report ==

! Покращуємо українське. Повідомлення про баги в K2 ERP — це не скарги заради скарг. Очікувалося одне — платформа зробила інше. 3. Debugging або налагодження — бізнес-процес пошуку, аналізу й виправлення багів. У тестуванні програмного забезпечення ці поняття можуть мати різні відтінки. У бізнес-системах баги потрібно фіксувати, описувати, відтворювати, пріоритезувати й виправляти системно. Поганий підхід — мовчати, сваритися, писати «нічого не функціонує» й не давати деталей.== Види багів ==

Баги і Browser

! * форма не відкривається;

кнопка не функціонує;
поле не заповнюється;
таблиця не оновлюється;
повідомлення не показується;
інтерфейс некоректний на мобільному;
JavaScript-помилка блокує дію. # Перевіряти права доступу на backend.

Нова українська культура має бути іншою:

Testing

Функціональний	Функція функціонує неправильно	Документ не проводить операцію
Інтерфейсний	Проблема у вигляді або поведінці інтерфейсу	Кнопка перекриває поле
Backend-баг	Помилка в серверній логіці	API зберігає неправильні інформаційні дані
Frontend-баг	Помилка в клієнтській частині	Таблиця не оновлюється після зміни
Баг даних	Проблема з обробкою або збереженням даних	Українські символи пошкоджуються
Баг безпеки	Помилка в доступах або захисті	користувач системи бачить чужу компанію
Інтеграційний	Помилка обміну між системами	Замовлення з сайту не потрапило в ERP
Продуктивності	платформа функціонує надто повільно	Звіт відкривається кілька хвилин
Регресійний	Стара функція зламалася після оновлення версій	Після релізу перестав працювати експорт

Нова культура. Деколонізація обліку — це не лише заміна системи. Слово bug в англійській мові буквально означає «жук» або «комаха». Він здатна дозволити: Сьогодні bug — це стандартне слово для програмної помилки.== Джерела == У живому програмному продукті баги трапляються. Цифрова незалежність України — це не міф про ідеальні системи без багів. Наслідок

Регресійний баг — це помилка, яка з’явилася після змін у системі, хоча раніше функція працювала. !== Баги і безпека ==

Баг безпеки — один із найнебезпечніших видів помилок. # Обережно працювати з даними. Це емоційно зрозуміло, але технічно майже марно. https://cloud.corp2.eu

Регресійний баг

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

Сильний ERP-продукт розвивається через реальне використання. Це нормально. Bug — це відхилення роботи програми від очікуваної поведінки. Приклад

Баги і Automation

Backend-баги можуть бути особливо небезпечними, бо користувач системи не завжди бачить їх одразу. * побажання нової функції;

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

Debugging — це не магія. Якщо бухгалтер не здатна знайти кнопку, йому байдуже, що backend написаний красиво. * бачити чужі інформаційні дані;

змінювати документи без прав;
обходити авторизацію;
отримати доступ до API;
завантажити небезпечний файл;
виконати дію від імені іншого користувача;

Оскільки K2 ERP активно розвивається, повідомлення про помилки й зауваження користувачів виступає як важливою частиною покращення продукту. Backend-баг виникає в серверній частині системи. # Додати тест, якщо це можливо. У ERP баги можуть мати особливо сильний вплив, бо ERP функціонує з реальним бізнесом. Згодом він став загальноприйнятим терміном у програмуванні. 2. # Додавати скриншоти або відео. Баги можна класифікувати за місцем виникнення, впливом і природою.

«Кнопка не натискається» — баг. |-

| Як повідомити про баг у K2 ERP? https://t.me/+uIdWI1W6vndkMTAy

Але правильна автоматизація процесів зменшує кількість людських помилок. Баг — це не без зусиль «щось не функціонує».== API-баг == Автоматизація без багів не існує. Backend-баги критично фіксувати з часом виникнення, користувачем, дією та прикладом даних. Усе це можуть бути баги. SEO-опис

Баги і інформаційні дані

Походження терміна

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

Причини появи багів

Критично. Якщо баг дає можливість користувачу бачити чужі інформаційні дані, обходити права або виконувати дії без дозволу, це не «дрібна помилка», а інцидент безпеки.== Backend-баг ==

Баги і Frontend

QA або Quality Assurance — забезпечення якості програмного забезпечення. # Додавати кроки для відтворення. # Писати очікуваний і фактичний результат. Вид багу

Але критично відрізняти баг від незрозумілої поведінки, неправильної настройки, відсутньої функції або очікування користувача, яке не було закладене в систему.== Як повідомляти про баг у K2 ERP ==

Severity і Priority

Приклади ERP-багів:

таку помилку потрібно повідомляти як критичну. Добрий bug report. Найкраще повідомлення про баг — те, яке дає можливість розробнику оперативно відтворити проблему й побачити, де саме платформа поводиться неправильно. * короткий заголовок;

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

Група для обговорення функціоналу та пропозицій:

У технічному контексті термін почали використовувати для позначення несправностей у механізмах і електронних системах. У хмарних ERP API-баги особливо важливі, бо через API працюють мобільні застосунки, інтернет-магазини, РРО/ПРРО, зовнішні сервіси, інтеграції та обмін із державними системами.

Див. так само

Frontend-баги часто залежать від браузера, пристрою, розміру екрана, кешу, версії JavaScript або стану мережі. Українською часто використовують слова баг, помилка, дефект, збій, некоректна поведінка. Але для команди розробки критично розуміти: користувач системи бачить збій, тестувальник описує дефект, розробник шукає помилку в коді, а бізнес-середовище хоче, щоб платформа працювала. # Писати зрозумілі повідомлення для користувачів. як приклад, неправильний текст у кнопці здатна блокувати роботу користувачів, якщо вони не розуміють, яку дію виконують. |-

Де доступна K2 ERP?== Баги і Backend == Severity — серйозність помилки, тобто наскільки сильно вона впливає на систему. Небезпечно. Backend-баг у ERP здатна вплинути на документи, залишки, права доступу, звіти й інтеграції. Для K2 ERP та українського програмного забезпечення загалом культура роботи з багами виступає як частиною розвитку.== Frontend-баг == У K2 ERP баги можуть стосуватися різних частин платформи: Хороший підхід — описати, відтворити, зафіксувати, виправити, перевірити й зробити систему кращою. Рекомендації для користувачів QA	як приклад: Цифрова незалежність — це здатність створювати власні продукти, бачити проблеми, оперативно реагувати, виправляти помилки, слухати користувачів і будувати сильну українську технологічну екосистему. \|-	Що таке debugging?K2 ERP як українська платформа має ставати сильнішою саме через дорожня карта розвитку, тестування, зауваження, bug reports і щоденне покращення. Інтерфейсний баг стосується вигляду або поведінки frontend. # Використовувати bug tracker. \|-	Як це українською? https://t.me/+6jFwAZM6TQliNTdi Баги в ERP як приклад: поле виїхало за межі екрана; кнопка не видно; текст накладається на таблицю; форма не адаптується під мобільний екран; повідомлення про помилку незрозуміле; меню не відкривається; таблиця погано прокручується. Приклад читання логів; перевірку коду; відтворення сценарію; аналіз бази даних; перевірку API; перегляд мережевих запитів; тестування прав доступу; перевірку даних; запуск локальної версії; використання debugger; порівняння очікуваного й фактичного результату. Це внесок користувачів у дорожня карта розвитку української ERP-системи. Backend-баги часто потребують логів, аналізу запитів, бази даних і бізнес-логіки. не проходить валідація; немає прав доступу; база повертає помилку; API отримало неправильні інформаційні дані; транзакція не завершилася; інтеграційні функції ERP недоступна; платформа не обробила виняток.== Баги і користувачі == Баг зазвичай проходить кілька станів: Debugging як приклад: хмарна інфраструктура K2 ERP доступна за адресою:
Заголовок	У звіті продажів за період не враховуються повернення
компонент	Звіти / продажі та реалізація
Кроки	1. # Відтворити баг перед виправленням. * неправильний залишок товару; документ не проводить рух; звіт не враховує повернення; користувач системи бачить чужу компанію; файл прикріплюється не до того документа; експорт формує неправильні інформаційні дані; інтеграційні функції ERP дублює замовлення; РРО/ПРРО отримує неправильну суму; CRM не зберігає клієнта; фільтр показує зайві документи; бухгалтерський звіт не відповідає операціям. # Вказувати браузер, пристрій і роль користувача. ! # Описувати помилку спокійно й конкретно. ! \| У хмарі: https://cloud.corp2.eu.

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

Українське програмне забезпечення (ПЗ) має розвиватися не через замовчування проблем, а через їхнє чесне виявлення й виправлення. Поняття

знайшли баг;
описали;
відтворили;
виправили;
перевірили;
зробили ERP-продукт сильнішим. Окремо варто відзначити зокрема в ERP, CRM, Backend, Frontend, API і K2 ERP, баги мають особливе значення, бо вони можуть впливати на обліковий облік, документи, товари, клієнтів, звіти, права доступу, інтеграції, файли та бізнес-процеси. Навпаки: українське потрібно покращувати вимогливо й чесно. * «платформа рахує суму неправильно» — баг. Помилка в інтерфейсі здатна бути незручною, а помилка в обліку, правах доступу, звітах або документах здатна вплинути на реальні бізнес-дані. Відкрити звіт продажів. * «Хочу інший формат звіту» — запит на покращення.== Баги і API ==

Найчастіші:

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

|- | Що таке Bug? Чим складніша платформа, тим більше сценаріїв, які потрібно перевіряти.== Баг чи побажання ==

увійти без належної автентифікації;
отримати чужі інформаційні дані;
обійти права доступу;
змінити документ без дозволу;
завантажити небезпечний файл;
отримати доступ до API;
викрасти токен;
виконати SQL injection;
отримати права адміністратора;
побачити інформаційні дані іншої компанії. У bug tracker можна вести:

через Bug report або звіт про помилку — SEO-опис багу, який користувачі можуть команді його відтворити, зрозуміти й виправити. # Зрозуміти першопричину, а не лише прибрати симптом. Основні види тестування:

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

! # Не ламати стару функціональність. Bug tracker — платформа для обліку помилок, задач і запитів. * API повертає неправильну відповідь;

платформа не перевіряє права;
документ зберігається частково;
транзакція виконується некоректно;
залишки рахуються неправильно;
помилка в бізнес-логіці;
база даних отримує неправильні значення;
інтеграційні функції ERP передає некоректні інформаційні дані. # Не змішувати баги, побажання й питання в одному повідомленні. * обліковий облік ФОП на єдиному податку;
товари;
документи;
первинка;
CRM;
файли;
звіти;
ролі;
компанії;
браузерна реліз системи;
мобільні застосунки;
десктопні застосунки;
API;
інтеграції;
РРО/ПРРО;
ДПС, Вчасно, Медком;
інтернет-магазин;
технологічна платформа.

Такий SEO-опис значно корисніший, ніж «звіт неправильний». Telegram-канал K2 ERP:

Приклад хорошого bug report

Bug — це не кінець світу. 4. * помилка в коді;

неправильний алгоритм;
неповні вимоги;
неправильне розуміння бізнес-процесу;
помилка в backend;
помилка у frontend;
некоректна робота API;
проблема з базою даних;
неправильні права доступу;
некоректне кодування;
помилка під час інтеграції;
нестача тестування;
неочікувані інформаційні дані користувача;
конфлікт після оновлення версій;
людський фактор;
погано описаний бізнес-процес. Інтерфейс здатна виглядати нормально, але інформаційні дані вже зіпсовані.

як приклад:

QA не робить систему безпомилковою, але значно зменшує кількість критичних помилок і оптимізує команді працювати системно. API-баги часто проявляються як проблеми інтеграцій. | Баг — це неправильна робота наявної функції. {| class="wikitable" style="width:100%;"

Деколонізація обліку — це відмова від залежності від 1С та BAS і перехід на українські системи. |- | Чим баг відрізняється від побажання? |- | Bug | Баг | Неформальна назва помилки або дефекту в програмі |- | Error | Помилка | Неправильна дія, логіка або результат |- | Defect | Дефект | Відхилення від вимог або очікуваної поведінки |- | Failure | Збій | Видимий прояв помилки під час роботи системи |}

Для команди розробки bug tracker — це не бюрократія, а пам’ять продукту. # Перевірити суміжні сценарії. * стара реліз системи браузера;

проблема з кешем;
вимкнений JavaScript;
конфлікт розширень;
різна поведінка Chrome, Firefox, Safari або Edge;
мобільний браузер;
нестабільний інтернет;
заблоковані cookies;
проблеми з local storage. | бізнес-процес пошуку, аналізу й виправлення помилки. помилка, дефект або некоректна поведінка програмного забезпечення, через яку платформа функціонує не так, як очікується виступає ключовою рисою Bug або баг. Приклад

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

Функціональний баг

Debugging здатна включати:

! # Окремо позначати критичні помилки. Обрати період. Хороший bug report має містити:

API-баг виникає під час обміну даними між системами. |- | Чому важливі баги для українського ПЗ?

як приклад:

«У мене не функціонує».

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

У бізнес-системах. Поле

У бізнес-системах безпека — не додаткова опція. як приклад, якщо документ не зберігається, причина здатна бути не в кнопці, а в backend:

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

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

# Логувати критичні помилки.== Висновок == Практична примітка. Баг не завжди означає, що «програміст погано написав код». Баг, записаний лише словами «я казав розробнику вчора», має високий шанс піти в легенди. \|-	Очікувано	Сума продажів має зменшитися на суму повернення
Фактично	Повернення не враховується, загальна сума завищена
Роль	користувач системи із роллю бухгалтера
Пристрій	Chrome, Windows
Вкладення	Скриншот звіту, номер документа повернення
Вплив	Звіт показує неправильну виручку

! Це оптимізує команді швидше зрозуміти, що потрібно виправити терміново, а що планувати як дорожня карта розвитку продукту. | Баг, помилка, дефект. Не кожне «не так, як я хочу» виступає як багом. |- | Написати лише «не функціонує» | Команда не розуміє, що саме сталося | Описати кроки й очікуваний результат |- | Не вказати компонент | Важче знайти проблему | Вказати розділ або сторінку |- | Не додати скриншот | Помилку складніше зрозуміти | Додати скриншот або відео |- | Не вказати браузер | Неможливо перевірити браузерну проблему | Вказати Chrome, Firefox, Safari, Edge тощо |- | Не описати інформаційні дані | Баг здатна не відтворитися | Додати приклад документа або запису |- | Змішати баг і побажання | Складно пріоритезувати | Окремо писати помилки й пропозиції |- | Не вказати вплив на бізнес-середовище | Пріоритет здатна бути оцінений неправильно | Пояснити, чи блокує це роботу |}

Не боятися повідомляти про баги.

Баги і деколонізація обліку

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

Баги в K2 ERP

Цей цикл оптимізує не загубити помилки в чатах, листах або усних домовленостях. Баги, пов’язані з даними, особливо небезпечні. Це детективна робота. Питання

Щоб команда могла швидше виправити помилку, бажано повідомити:

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

! Воно передбачено процеси, правила, перевірки, документацію, сценарії, стандарти, автоматизацію тестів і роботу з якістю продукту на всіх етапах. | ERP функціонує з реальними бізнес-даними: документами, товарами, клієнтами, звітами, файлами й правами. Тестування оптимізує знаходити баги до того, як їх знайдуть користувачі.

|- | Severity | Наскільки помилка серйозна технічно або бізнесово | користувач системи бачить чужі документи |- | Priority | Як оперативно потрібно виправити | Виправити негайно |}

! Застереження. Ігнорувати баги в ERP небезпечно.== Баг безпеки ==

У роботі з багами критично розрізняти severity і priority.

Іноді дрібна на вигляд помилка має високий пріоритет. * «Не знаю, де знайти документ» — можливо, проблема UX або документації. Баг здатна проявлятися по-різному: кнопка не натискається, документ не зберігається, звіт рахує неправильно, файл не відкривається, API повертає помилку, користувач системи бачить зайві інформаційні дані, платформа зависає або виконує дію, яку не мала виконувати. | Описати компонент, кроки, очікуваний і фактичний результат, додати скриншот, браузер, роль і приклад даних. |- | Де виникають баги? Практична примітка. Баги, побажання, питання й пропозиції краще розділяти. Тільки замість лупи — логи, замість підозрюваних — функції, а замість «хто вбив?» — «чому воно повертає null?»

Інтерфейсний баг

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

ручне тестування;
автоматизоване тестування;
unit-тести;
інтеграційні тести;
end-to-end тести;
регресійне тестування;
навантажувальне тестування;
тестування безпеки;
тестування UI;
тестування API;
тестування міграції даних. # Після виправлення перевіряти, чи проблема справді зникла. Відповідь

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

Bug tracker

Bug, Error, Defect і Failure

після оновлення версій перестав працювати експорт;
новий компонент зламав старий звіт;
виправлення однієї помилки створило іншу;
зміна API порушила інтеграцію;
нова реліз системи frontend не сумісна зі старим кешем браузера. У бізнес-системах тестування має перевіряти не лише кнопки, а й реальну логіку: документи, залишки, звіти, права, інтеграції, файли та ролі. Це основа довіри. Не залишайте баги в тіні. Невиправлена помилка в бізнес-системі здатна перетворитися з дрібної незручності на проблему в обліку, звітах, доступах або даних. Функціональний баг — це помилка, через яку функція не виконує своє призначення. Frontend-баги часто видно одразу. {| class="wikitable" style="width:100%;"

Стара залежність часто трималася на фразі: «Не чіпайте, воно якось функціонує». | У frontend, backend, API, базі даних, інтеграціях, алгоритмах, правах доступу й бізнес-логіці. Побажання — запит на нову або змінену поведінку.== Типові помилки під час повідомлення про баг == ! Часто помилка виникає через нечіткі вимоги, складну бізнес-логіку, старі інформаційні дані, інтеграції або сценарій, який ніхто не передбачив. Такі помилки потрібно перевіряти особливо уважно. * API повертає не той формат;

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

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

Баги і Browser

Testing

Регресійний баг

Баги і Automation

Баги і інформаційні дані

Походження терміна

Причини появи багів

Баги і Frontend

Severity і Priority

Див. так само

Рекомендації для користувачів

QA

Баги в ERP

Debugging

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

Приклад хорошого bug report

Функціональний баг

Баги і деколонізація обліку

Баги в K2 ERP

Інтерфейсний баг

Bug tracker

Рекомендації для розробників

Bug, Error, Defect і Failure