Bug
Див.; додатково
Backend-баги часто потребують логів, аналізу запитів, бази даних і бізнес-логіки.;Автоматизація без багів не існує.;
Цифрова незалежність України — це не міф про ідеальні системи без багів.; У ERP баг безпеки має змогу мати серйозні наслідки, бо платформа містить документи, клієнтів, товари, фінансовий блок, файли й звіти.; Інтерфейс має змогу виглядати нормально, але інформаційні дані вже зіпсовані.; Priority — пріоритет виправлення, тобто наскільки оперативно потрібно виправити баг.; Користувачі часто першими знаходять баги в реальних сценаріях.; Помилка
Хороший підхід — описати, відтворити, зафіксувати, виправити, перевірити й зробити систему кращою.; * поле виїхало за межі екрана;
- кнопка не видно;
- текст накладається на таблицю;
- форма не адаптується під мобільний екран;
- повідомлення про помилку незрозуміле;
- меню не відкривається;
- таблиця погано прокручується.; * «Хочу, щоб кнопка була зліва» — побажання.; як ілюстрація:
Стара залежність часто трималася на фразі: «Не чіпайте, воно якось функціонує».; Приклад
Іноді це:
- кнопка не реагує;
- форма не відправляється;
- таблиця показує старі інформаційні дані;
- після актуалізація інтерфейс зависає;
- JavaScript-помилка блокує сторінку;
- мобільна реліз функціонує некоректно;
- файл не вибирається для завантаження.; Поле
Testing
- обліковий облік ФОП на єдиному податку;
- товари;
- документи;
- первинка;
- CRM;
- файли;
- звіти;
- ролі;
- компанії;
- браузерна реліз;
- мобільні застосунки;
- десктопні застосунки;
- API;
- інтеграції;
- РРО/ПРРО;
- ДПС, Вчасно, Медком;
- інтернет-магазин;
- технологічна платформа.; 3.; У бізнес-системах баги потрібно фіксувати, описувати, відтворювати, пріоритезувати й виправляти системно.;
Інтерфейсний баг
Джерела
- неправильний залишок товару;
- документ не проводить рух;
- звіт не враховує повернення;
- користувач системи бачить чужу компанію;
- файл прикріплюється не до того документа;
- експорт формує неправильні інформаційні дані;
- інтеграційні функціональні можливості дублює замовлення;
- РРО/ПРРО отримує неправильну суму;
- CRM не зберігає клієнта;
- фільтр показує зайві документи;
- бухгалтерський звіт не відповідає операціям.; 2.; Це точка покращення.; У QA — це ширше поняття, ніж тестування.; Приклад
- знайшли баг;
- описали;
- відтворили;
- виправили;
- перевірили;
- зробили програмний продукт сильнішим.; Інтерфейсний баг має змогу здаватися дрібницею, але для користувача саме інтерфейс є собою системою.; Українське програмне забезпечення має розвиватися не через замовчування проблем, а через їхнє чесне виявлення й виправлення.;
Функціональний баг
Сильний програмний продукт розвивається через реальне використання.; * користувач системи натиснув «Зберегти», але документ не зберігся;
- у звіті показано неправильну суму;
- товар списався не з того складу;
- файл завантажився, але не відкривається;
- користувач системи без прав побачив закритий документ;
- API повернуло помилку;
- сторінка відкрилася порожньою;
- платформа зависла під час формування звіту;
- після актуалізація зникла кнопка;
- у мобільному браузері форма «поїхала» за межі екрана.; | У хмарі: https://cloud.corp2.eu.
|}
!; Backend-баги істотно фіксувати з часом виникнення, користувачем, дією та прикладом даних.; користувач системи має змогу натиснути кнопку не в з цієї причини порядку, завантажити файл із дивною назвою, створити документ на межі правил, відкрити систему в старому браузері, працювати з мобільного інтернету або зробити те, про що розробник навіть не підозрював.; !; Воно передбачено процеси, правила, перевірки, документацію, сценарії, стандарти, автоматизацію тестів і роботу з якістю продукту на всіх етапах.; Додати документ повернення.; як ілюстрація, неправильний текст у кнопці має змогу блокувати роботу користувачів, якщо вони не розуміють, яку дію виконують.; Баг — це не без ускладнень «щось не функціонує».; Це сприяє команді швидше зрозуміти, що потрібно виправити терміново, а що планувати як еволюція продукту.; Це основа довіри.; # Писати зрозумілі повідомлення для користувачів.; Деколонізація обліку — це відмова від залежності від 1С та BAS і перехід на українські системи.; https://t.me/+uIdWI1W6vndkMTAy
Щоб команда могла швидше виправити помилку, бажано повідомити:
!;== Як повідомляти про баг у K2 ERP ==
Усе це можуть бути баги.; # Обережно працювати з даними.; Головне. Bug — це програмна помилка або дефект, через який платформа функціонує неправильно.; «У мене не функціонує».
Для K2 ERP. Зауваження та повідомлення про помилки в K2 ERP допомагають покращувати український програмний продукт, робити обліковий облік точнішим, інтерфейс зручнішим, інтеграції стабільнішими, а систему сильнішою.; | характеристика помилки з кроками відтворення, очікуваним і фактичним результатом.; |- | Чому важливі баги для українського ПЗ?;== Баг чи побажання ==
Debugging — це не магія.; помилка, дефект або некоректна поведінка програмного забезпечення, через яку платформа функціонує не так, як очікується виступає ключовою рисою Bug або баг.; як ілюстрація:
!; Оновити звіт.;
як ілюстрація, якщо документ не зберігається, причина має змогу бути не в кнопці, а в backend:
завдяки наявності Bug report або звіт про помилку — характеристика багу, який користувачі можуть команді його відтворити, зрозуміти й виправити.; Окремо варто відзначити зокрема в ERP, CRM, Backend, Frontend, API і K2 ERP, баги мають особливе значення, бо вони можуть впливати на обліковий облік, документи, товари, клієнтів, звіти, права доступу, інтеграції, файли та бізнес-процеси.; * бачити чужі інформаційні дані;
- змінювати документи без прав;
- обходити авторизацію;
- отримати доступ до API;
- завантажити небезпечний файл;
- виконати дію від імені іншого користувача;
Частина багів має змогу залежати від браузера.;
Регресійний баг
|- | Bug | Баг | Неформальна назва помилки або дефекту в програмі |- | Error | Помилка | Неправильна дія, логіка або результат |- | Defect | Дефект | Відхилення від вимог або очікуваної поведінки |- | Failure | Збій | Видимий прояв помилки під час роботи системи |}
!; як ілюстрація:
- де саме виникла проблема;
- у якому модулі;
- що користувач системи робив;
- які кроки повторюють помилку;
- що очікувалося;
- що сталося фактично;
- який браузер або застосунок використовувався;
- яка роль користувача;
- чи повторюється помилка;
- скриншот або відео;
- номер документа або приклад даних;
- час виникнення;
- наскільки це блокує роботу.;
Що таке bug report?; Часто помилка виникає через нечіткі вимоги, складну бізнес-логіку, старі інформаційні дані, інтеграції або сценарій, який ніхто не передбачив.; Приклад
Але істотно відрізняти баг від незрозумілої поведінки, неправильної настройки, відсутньої функції або очікування користувача, яке не було закладене в систему.; |- |
Що таке debugging?; * після актуалізація перестав працювати експорт;
|
; Баг, записаний лише словами «я казав розробнику вчора», має високий шанс піти в легенди.; | Їхнє якісне виправлення робить українські продукти сильнішими й конкурентнішими.; Найчастіші: Це емоційно зрозуміло, але технічно майже марно.; Це внесок користувачів у еволюція української ERP-системи.; |- |
Чому баги важливі для ERP?; з цієї причини в bug report істотно вказувати браузер, пристрій і операційну систему.; характеристика
Баги безпеки потребують особливої уваги.; як ілюстрація: Регресійний баг — це помилка, яка з’явилася після змін у системі, хоча раніше функція працювала.; У бізнес-системах.; Не залишайте баги в тіні. Невиправлена помилка в бізнес-системі має змогу перетворитися з дрібної незручності на проблему в обліку, звітах, доступах або даних.; # Додавати номер документа або приклад даних.; У повсякденній розмові всі ці слова часто використовують як синоніми.; істотно не те, чи існують помилки, а те, як команда й користувачі з ними працюють.; !; Практична примітка. Баг не завжди означає, що «програміст погано написав код».; Bug — це не кінець світу.; Вид багу Баги, пов’язані з даними, особливо небезпечні.; як ілюстрація: https://t.me/+6jFwAZM6TQliNTdi Слово bug в англійській мові буквально означає «жук» або «комаха».; # Описувати помилку спокійно й конкретно.; API-баги часто проявляються як проблеми інтеграцій.; Добрий bug report. Найкраще повідомлення про баг — те, яке надає можливість розробнику оперативно відтворити проблему й побачити, де саме платформа поводиться неправильно.; |- |
Severity | Наскільки помилка серйозна технічно або бізнесово | користувач системи бачить чужі документи |
|---|---|---|---|---|---|---|
| Priority | Як оперативно потрібно виправити | Виправити негайно |
Баги і інформаційні дані
- знайдено;
- зареєстровано;
- підтверджено;
- призначено відповідальному;
- у роботі;
- виправлено;
- передано на тестування;
- перевірено;
- закрито;
- перевідкрито, якщо помилка повторюється.;
- короткий заголовок;
- характеристика проблеми;
- кроки для відтворення;
- очікуваний результат;
- фактичний результат;
- скриншоти або відео;
- інформаційні дані користувача або роль;
- компонент системи;
- браузер або пристрій;
- час виникнення;
- повідомлення про помилку;
- приклади документів або тестових даних;
- пріоритет;
- вплив на бізнес-середовище.; Іноді дрібна на вигляд помилка має високий пріоритет.; # Зрозуміти першопричину, а не лише прибрати симптом.; Тестувальник має змогу перевірити багато сценаріїв, але реальний бізнес-середовище завжди винахідливіший.; Такі помилки потрібно перевіряти особливо уважно.;
Баги і Frontend
|- | Написати лише «не функціонує» | Команда не розуміє, що саме сталося | Описати кроки й очікуваний результат |- | Не вказати компонент | Важче знайти проблему | Вказати розділ або сторінку |- | Не додати скриншот | Помилку складніше зрозуміти | Додати скриншот або відео |- | Не вказати браузер | Неможливо перевірити браузерну проблему | Вказати Chrome, Firefox, Safari, Edge тощо |- | Не описати інформаційні дані | Баг має змогу не відтворитися | Додати приклад документа або запису |- | Змішати баг і побажання | Складно пріоритезувати | Окремо писати помилки й пропозиції |- | Не вказати вплив на бізнес-середовище | Пріоритет має змогу бути оцінений неправильно | Пояснити, чи блокує це роботу |}
- Не боятися повідомляти про баги.; Що означає
Коротко
Для таких багів дуже корисні скриншоти, відео й характеристика браузера.; Якщо бухгалтер не має змогу знайти кнопку, йому байдуже, що backend написаний красиво.;== Bug tracker == як ілюстрація:
API-баг
Інтерфейсний баг стосується вигляду або поведінки frontend.; * «Не знаю, де знайти документ» — можливо, проблема UX або документації.; Debugging має змогу включати:
Практична примітка. Баги, побажання, питання й пропозиції краще розділяти.;Баг безпеки — один із найнебезпечніших видів помилок.; Таких систем не існує.; | бізнес-процес пошуку, аналізу й виправлення помилки.;== Типові помилки під час повідомлення про баг ==
- інтернет-магазин не передає замовлення;
- ПРРО не отримує інформаційні дані;
- зовнішній сервіс повертає помилку;
- API не приймає токен;
- відповідь має неправильний формат;
- інформаційні дані дублюються;
- статуси не синхронізуються.; {| class="wikitable" style="width:100%;"
| Заголовок | У звіті продажів за період не враховуються повернення | |||
| компонент | Звіти / продажі та реалізація | |||
| Кроки | 1.;== QA ==
Цей цикл сприяє не загубити помилки в чатах, листах або усних домовленостях.; !;== Bug report ==
Нова культура. Деколонізація обліку — це не лише заміна системи.; Наслідок Види багівФункціональний баг — це помилка, через яку функція не виконує своє призначення.; Це перехід до культури відкритого зворотного зв’язку, швидкого виправлення помилок і розвитку українського продукту.; * «платформа рахує суму неправильно» — баг.; # Використовувати bug tracker.; # Не змішувати баги, побажання й питання в одному повідомленні.;== Баги і API == Баги і користувачіяк ілюстрація: Життєвий цикл багуДля K2 ERP та українського програмного забезпечення загалом культура роботи з багами є собою частиною розвитку.; | Помилка або дефект у програмному забезпеченні.; !; Це детективна робота.; програмної помилки.;== Баги і безпека == Debugging
Баг зазвичай проходить кілька станів: Bug — це відхилення роботи програми від очікуваної поведінки.; # Вказувати браузер, пристрій і роль користувача.; Але правильна автоматизація процесів зменшує кількість людських помилок.; як ілюстрація: Правильний підхід. Баг потрібно не приховувати, а описувати й виправляти.; Українською часто використовують слова баг забезпечується через Сьогодні bug — це стандартне слово; додатково реалізовано помилка, дефект, збій, некоректна поведінка.; Для API-багів істотно мати приклад запиту, відповідь, час помилки, код статусу й тіло помилки.; * хмарна інфраструктура K2 ERP
Поганий bug report виглядає так: |
; Severity — серйозність помилки, тобто наскільки сильно вона впливає на систему.;
Баги і деколонізація облікуРегресійні баги показують, чому потрібне регресійне тестування: після змін треба перевіряти не лише нову функцію, а й старі сценарії.; # Окремо позначати критичні помилки.; * Debugging
Цифрова незалежність — це здатність створювати власні продукти, бачити проблеми, оперативно реагувати, виправляти помилки, слухати користувачів і будувати сильну українську технологічну екосистему.;== Причини появи багів == Severity і PriorityУ K2 ERP баги можуть стосуватися різних частин платформи:
|
Очікувано | Сума продажів має зменшитися на суму повернення |
|---|---|---|---|---|
| Фактично | Повернення не враховується, загальна сума завищена | |||
| Роль | користувач системи із роллю бухгалтера | |||
| Пристрій | Chrome, Windows | |||
| Вкладення | Скриншот звіту, номер документа повернення | |||
| Вплив | Звіт показує неправильну виручку |
Небезпечно. Backend-баг у ERP має змогу вплинути на документи, залишки, права доступу, звіти й інтеграції.; * помилка в коді;
- неправильний алгоритм;
- неповні вимоги;
- неправильне розуміння бізнес-процесу;
- помилка в backend;
- помилка у frontend;
- некоректна робота API;
- проблема з базою даних;
- неправильні права доступу;
- некоректне кодування;
- помилка під час інтеграції;
- нестача тестування;
- неочікувані інформаційні дані користувача;
- конфлікт після актуалізація;
- людський фактор;
- погано описаний бізнес-процес.; Відкрити звіт продажів.; Оскільки K2 ERP активно розвивається, повідомлення про помилки й зауваження користувачів є собою важливою частиною покращення продукту.; !;
Критично. Якщо баг надає можливість користувачу бачити чужі інформаційні дані, обходити права або виконувати дії без дозволу, це не «дрібна помилка», а інцидент безпеки.; | Баг — це неправильна робота наявної функції.;
Поганий підхід — мовчати, сваритися, писати «нічого не функціонує» й не давати деталей.;== Баги в K2 ERP ==
Debugging або налагодження — бізнес-процес пошуку, аналізу й виправлення багів.;- «Кнопка не натискається» — баг.;K2 ERP як українська платформа має ставати сильнішою саме через еволюція, тестування, зауваження, bug reports і щоденне покращення.; |-
| Де доступна K2 ERP?; # Перевірити суміжні сценарії.;== Зовнішні посилання == !;== Баги і Automation ==
Не кожне «не так, як я хочу» є собою багом.;
як ілюстрація:
Приклади ERP-багів:
Frontend-баг
- баги;
- задачі;
- побажання;
- пріоритети;
- відповідальних;
- статуси;
- коментарі;
- вкладення;
- історію змін;
- версії;
- релізи.; * дублюються клієнти;
- зникають рядки документа;
- некоректно зберігаються українські символи;
- пошкоджуються файли;
- неправильно імпортуються товари;
- звіт бере не всі документи;
- API передає не той статус;
- залишки рахуються з помилкою;
- резервні копії не відновлюються.; # Додавати скриншоти або відео.; # Після виправлення перевіряти, чи проблема справді зникла.; Обрати період.; Кожне якісне повідомлення про помилку сприяє зробити програмний продукт кращим.; |-
| Як повідомити про баг у K2 ERP?; https://cloud.corp2.eu
Bug, Error, Defect і Failure
У ERP баги можуть мати особливо сильний вплив, бо ERP функціонує з реальним бізнесом.; ERP-баги потрібно аналізувати не лише технічно, а й бізнесово: який бізнес-процес зачеплено, які інформаційні дані постраждали, чи потрібне виправлення записів, чи треба попередити користувачів.; Саме через зауваження користувачів, тестування, bug reports і щоденні виправлення українська ERP має змогу ставати сильнішою, стабільнішою й зручнішою.; Тестування сприяє знаходити баги до того, як їх знайдуть користувачі.; Для команди розробки bug tracker — це не бюрократія, а пам’ять продукту.; Застереження. Ігнорувати баги в ERP небезпечно.; 4.; Bug tracker — платформа для обліку помилок, задач і запитів.; !; У bug tracker можна вести:
У хмарних ERP API-баги особливо важливі, бо через API працюють мобільні застосунки, інтернет-магазини, РРО/ПРРО, зовнішні сервіси, інтеграції та обмін із державними системами.; * ручне тестування;
- автоматизоване тестування;
- unit-тести;
- інтеграційні тести;
- end-to-end тести;
- регресійне тестування;
- навантажувальне тестування;
- тестування безпеки;
- тестування UI;
- тестування API;
- тестування міграції даних.; Згодом він став загальноприйнятим терміном у програмуванні.; Покращуємо українське. Повідомлення про баги в K2 ERP — це не скарги заради скарг.; Очікувалося одне — платформа зробила інше.; таку помилку потрібно повідомляти як критичну.; Але для команди розробки істотно розуміти: користувач системи бачить збій, тестувальник описує дефект, розробник шукає помилку в коді, а бізнес-середовище хоче, щоб платформа працювала.; QA не робить систему безпомилковою, але значно зменшує кількість критичних помилок і сприяє команді працювати системно.;
- увійти без належної автентифікації;
- отримати чужі інформаційні дані;
- обійти права доступу;
- змінити документ без дозволу;
- завантажити небезпечний файл;
- отримати доступ до API;
- викрасти токен;
- виконати SQL injection;
- отримати права адміністратора;
- побачити інформаційні дані іншої компанії.; # Логувати критичні помилки.; Хороший bug report має містити:
|- | Що таке Bug?; Термін
- API повертає неправильну відповідь;
- платформа не перевіряє права;
- документ зберігається частково;
- транзакція виконується некоректно;
- залишки рахуються неправильно;
- помилка в бізнес-логіці;
- база даних отримує неправильні значення;
- інтеграційні функціональні можливості передає некоректні інформаційні дані.; Навпаки: українське потрібно покращувати вимогливо й чесно.; # Писати очікуваний і фактичний результат.; # Після виправлення передавати задачу на повторне тестування.; {| class="wikitable" style="width:100%;"
Але перехід на українське ПЗ не означає, що користувачі мають мовчати про помилки «бо своє».; Це сигнал, що в системі є собою невідповідність між очікуваною логікою і реальною поведінкою.; Питання
У таких випадках потрібно не лише виправити код, а й перевірити, чи не потрібно відновити або скоригувати інформаційні дані.; Побажання — запит на нову або змінену поведінку.; !;{{SEO
Це нормально.; |- | Як це українською?; як ілюстрація:
Frontend-баги часто залежать від браузера, пристрою, розміру екрана, кешу, версії JavaScript або стану мережі.;== Баги в ERP == |- | Функціональний | Функція функціонує неправильно | Документ не проводить операцію |- | Інтерфейсний | Проблема у вигляді або поведінці інтерфейсу | Кнопка перекриває поле |- | Backend-баг | Помилка в серверній логіці | API зберігає неправильні інформаційні дані |- | Frontend-баг | Помилка в клієнтській частині | Таблиця не оновлюється після зміни |- | Баг даних | Проблема з обробкою або збереженням даних | Українські символи пошкоджуються |- | Баг безпеки | Помилка в доступах або захисті | користувач системи бачить чужу компанію |- | Інтеграційний | Помилка обміну між системами | Замовлення з сайту не потрапило в ERP |- | Продуктивності | платформа функціонує надто повільно | Звіт відкривається кілька хвилин |- | Регресійний | Стара функція зламалася після актуалізація | Після релізу перестав працювати експорт |}
Баги і Browser
QA або Quality Assurance — забезпечення якості програмного забезпечення.;
У бізнес-системах безпека — не додаткова опція.; | Описати компонент, кроки, очікуваний і фактичний результат, додати скриншот, браузер, роль і приклад даних.; хмарна інфраструктура K2 ERP доступна за адресою:
Якщо користувач системи знайшов помилку, яка надає можливість:
Баги і Backend
Суть поняття
У бізнес-системах тестування має перевіряти не лише кнопки, а й реальну логіку: документи, залишки, звіти, права, інтеграції, файли та ролі.; Відповідь
Приклад хорошого bug report
Він має змогу дозволити:
Backend-баги можуть бути особливо небезпечними, бо користувач системи не завжди бачить їх одразу.;== Висновок ==
- форма не відкривається;
- кнопка не функціонує;
- поле не заповнюється;
- таблиця не оновлюється;
- повідомлення не показується;
- інтерфейс некоректний на мобільному;
- JavaScript-помилка блокує дію.; # Документувати важливі зміни.; # Додати тест, якщо це можливо.; Група для обговорення функціоналу та пропозицій:
Frontend-баг виникає в клієнтській частині системи, яку виконує браузер або застосунок користувача.; Значення
Рекомендації для розробників
У тестуванні програмного забезпечення ці поняття можуть мати різні відтінки.; !; * документ не зберігається;
- сума рахується неправильно;
- фільтр не фільтрує;
- пошук не знаходить очевидний запис;
- кнопка виконує не ту дію;
- статус не змінюється;
- товар не списується;
- звіт показує некоректні інформаційні дані.; У технічному контексті термін почали використовувати для позначення несправностей у механізмах і електронних системах.; | Баг, помилка, дефект.; Як краще
!; # Не ламати стару функціональність.; Тільки замість лупи — логи, замість підозрюваних — функції, а замість «хто вбив?» — «чому воно повертає null?»
У роботі з багами істотно розрізняти severity і priority.; Нова українська культура має бути іншою:
Frontend-баги часто видно одразу.;== Баги і цифрова незалежність України ==
Основні види тестування: У живому програмному продукті баги трапляються.; |-| - | Чим баг відрізняється від побажання?; задача команди — щоб програмні помилки не замінили ручні помилки, а поступово зникали через тестування, зворотний зв’язок і покращення продукту. |