Тестування коду
Тестування коду в K2 ERP — це процес перевірки програмної логіки, модулів, документів, звітів, API, інтеграцій, прав доступу та оновлень перед використанням змін у реальній роботі підприємства.
У K2 ERP тестування розглядається не як формальність і не як «додаткова опція», а як обов’язкова частина відповідальної розробки.
ERP-система працює з реальними бізнес-даними: документами, залишками, фінансами, взаєморозрахунками, замовленнями, складами, виробництвом, клієнтами та звітністю. Тому помилка в коді може мати не лише технічні, а й бізнесові наслідки.
Головна ідея
Код у K2 ERP повинен не просто запускатися. Він має працювати правильно.
Тестування потрібне для того, щоб переконатися:
- що зміна не зламала існуючу функціональність;
- що новий модуль працює відповідно до вимог;
- що документи створюються і проводяться правильно;
- що звіти показують коректні дані;
- що API повертає очікуваний результат;
- що інтеграції обробляють помилки;
- що права доступу не порушені;
- що оновлення не пошкоджує дані;
- що бізнес-процес після зміни залишається керованим.
Тестування — це спосіб не вгадувати, а перевіряти.
Чому тестування важливе для ERP
У звичайній програмі помилка може означати некрасивий інтерфейс або неправильне повідомлення. В ERP помилка може означати:
- неправильні залишки на складі;
- некоректну суму документа;
- помилку у взаєморозрахунках;
- дублювання замовлень;
- втрату даних;
- неправильний звіт для керівника;
- зламану інтеграцію з банком, сайтом або службою доставки;
- порушення прав доступу;
- неможливість провести документи;
- збій у виробничому процесі.
Саме тому тестування коду в ERP є критичною частиною розробки.
Що потрібно тестувати
У K2 ERP потрібно тестувати не тільки окремі функції Python-коду, а всю поведінку системи.
До тестування можуть входити:
- модулі;
- класи;
- команди;
- документи;
- довідники;
- звіти;
- друковані форми;
- API;
- інтеграції;
- права доступу;
- міграції бази даних;
- оновлення;
- імпорт і експорт даних;
- фонові задачі;
- обробки;
- бізнес-процеси;
- дії користувача в інтерфейсі.
ERP-тестування завжди ширше, ніж проста перевірка: «чи не впав код».
Види тестування
У K2 ERP можуть застосовуватися різні види тестування.
Основні з них:
- Ручне тестування — перевірка сценаріїв користувачем, програмістом або аналітиком.
- Автоматизоване тестування — запуск тестів, які перевіряють код автоматично.
- Модульне тестування — перевірка окремих функцій, класів або компонентів.
- Інтеграційне тестування — перевірка взаємодії між модулями або зовнішніми системами.
- Регресійне тестування — перевірка, що нова зміна не зламала стару функціональність.
- Тестування прав доступу — перевірка, хто що може бачити, створювати, змінювати або запускати.
- Тестування продуктивності — перевірка швидкості роботи запитів, звітів, API та обробок.
- Тестування оновлень — перевірка переходу системи з однієї версії на іншу.
- Тестування міграцій — перевірка змін структури бази даних.
- Тестування відмов — перевірка поведінки системи при помилках, недоступності сервісів або некоректних даних.
Ручне тестування
Ручне тестування потрібне там, де важливо перевірити реальний бізнес-сценарій.
Наприклад:
- створити замовлення клієнта;
- провести видаткову накладну;
- сформувати рахунок;
- перевірити зміну залишків;
- створити оплату;
- сформувати звіт;
- перевірити друковану форму;
- виконати обмін із зовнішнім сервісом;
- перевірити права різних користувачів.
Ручне тестування особливо корисне на етапі впровадження або перевірки нестандартної бізнес-логіки.
Але ручне тестування не повинно бути єдиним способом контролю якості. Людина може пропустити помилку, забути сценарій або перевірити не всі варіанти.
Автоматизоване тестування
Автоматизоване тестування дозволяє запускати перевірки багато разів без ручної роботи.
Це особливо корисно для:
- критичних алгоритмів;
- розрахунків;
- API;
- інтеграцій;
- перевірки прав доступу;
- регресійних тестів;
- оновлень;
- складної бізнес-логіки.
Автоматизовані тести допомагають швидше знаходити помилки після змін у коді.
Якщо модуль активно розвивається, автоматизовані тести зменшують ризик того, що нове доопрацювання зламає вже працюючу функціональність.
Модульне тестування
Модульне тестування перевіряє невелику частину коду окремо від решти системи.
Це може бути:
- функція розрахунку суми;
- перевірка знижки;
- алгоритм формування номера документа;
- правило округлення;
- обробка статусу;
- перевірка дати;
- фільтрація списку;
- конвертація даних;
- підготовка відповіді API.
Модульні тести корисні тим, що швидко показують, де саме виникла помилка.
Наприклад, якщо змінено правило розрахунку знижки, тест може одразу показати, що для певного типу клієнта результат став неправильним.
Інтеграційне тестування
Інтеграційне тестування перевіряє, як різні частини системи працюють разом.
У K2 ERP це може бути взаємодія:
- документа і регістру;
- модуля продажів і складу;
- CRM і замовлень;
- ERP і сайту;
- ERP і банку;
- ERP і служби доставки;
- API і зовнішнього клієнта;
- звіту і бази даних;
- бізнес-процесу і прав доступу.
Інтеграційні помилки часто складніші за звичайні. Окремо кожна частина може працювати правильно, але разом вони дають неправильний результат.
Регресійне тестування
Регресійне тестування потрібне для перевірки того, що нові зміни не зламали стару функціональність.
Це особливо важливо після:
- оновлення модуля;
- зміни бізнес-логіки;
- рефакторингу;
- оптимізації запитів;
- зміни структури бази даних;
- додавання нової інтеграції;
- зміни прав доступу;
- виправлення помилки.
У ERP одна зміна може вплинути на багато пов’язаних процесів. Наприклад, зміна в документі продажу може вплинути на склад, фінанси, звіти, друковані форми та API.
Тому регресійне тестування є одним із найважливіших видів перевірки.
Тестування бізнес-логіки
Бізнес-логіка повинна тестуватися не лише з технічного, а й з предметного погляду.
Потрібно перевіряти:
- чи правильно система виконує бізнес-правила;
- чи не дозволяє заборонені дії;
- чи правильно реагує на виняткові ситуації;
- чи відповідає логіка реальному процесу підприємства;
- чи коректно працюють статуси документів;
- чи правильно обробляються різні ролі користувачів;
- чи не виникають приховані обхідні шляхи.
Наприклад, якщо замовлення не можна відвантажити без оплати, тест має перевірити не тільки стандартний сценарій, а й спробу обійти це правило через API, зміну статусу або іншу дію.
Тестування документів
Документи в K2 ERP потрібно перевіряти особливо уважно.
Під час тестування документа варто перевірити:
- створення;
- редагування;
- збереження;
- проведення;
- скасування проведення;
- видалення;
- зміну статусу;
- табличні частини;
- обов’язкові поля;
- автоматичні розрахунки;
- друковані форми;
- зв’язки з іншими документами;
- вплив на залишки;
- вплив на фінанси;
- відображення у звітах;
- права доступу.
Документ у ERP — це не просто форма. Це дія, яка може змінювати стан бізнесу.
Тестування довідників
Довідники теж потребують перевірки.
Потрібно тестувати:
- створення запису;
- редагування;
- пошук;
- фільтрацію;
- унікальність;
- обов’язкові поля;
- ієрархію;
- зв’язки з документами;
- імпорт;
- експорт;
- права доступу;
- архівацію або деактивацію.
Погано протестований довідник може створювати проблеми в документах, звітах та інтеграціях.
Тестування звітів
Звіти потрібно перевіряти не тільки на відкриття, а й на правильність даних.
Під час тестування звіту варто перевірити:
- джерело даних;
- період;
- фільтри;
- групування;
- сортування;
- підсумки;
- деталізацію;
- права доступу;
- експорт;
- швидкість формування;
- відповідність очікуваному бізнес-результату.
Особливо важливо перевіряти звіти, на основі яких приймаються управлінські або фінансові рішення.
Тестування API
API потрібно тестувати як окремий продукт.
Для API важливо перевірити:
- правильність запитів;
- формат відповіді;
- авторизацію;
- права доступу;
- обробку помилок;
- обов’язкові поля;
- некоректні дані;
- дублікати;
- швидкість відповіді;
- стабільність контракту;
- версіонування;
- журналювання;
- поведінку при недоступності зовнішнього сервісу.
API часто використовується зовнішніми системами, тому помилки в ньому можуть впливати не лише на K2 ERP, а й на сайт, CRM, мобільний застосунок, маркетплейс або іншу платформу.
Тестування інтеграцій
Інтеграції потрібно тестувати з урахуванням реальних збоїв.
Потрібно перевіряти:
- успішний обмін;
- повторну відправку;
- часткову помилку;
- недоступність зовнішнього сервісу;
- неправильний формат відповіді;
- дублювання даних;
- затримку відповіді;
- зміну статусів;
- журнал обміну;
- ручне повторення операції;
- повідомлення адміністратору;
- відкат або компенсацію дій.
Інтеграція без тестування часто працює лише в ідеальних умовах. У реальному бізнесі ідеальні умови трапляються не завжди.
Тестування прав доступу
Права доступу є критичною частиною тестування.
Потрібно перевіряти:
- що користувач бачить лише дозволені дані;
- що користувач не може виконати заборонену дію;
- що API також дотримується прав доступу;
- що звіти не показують зайву інформацію;
- що кнопки, команди й обробки доступні лише потрібним ролям;
- що адміністраторські функції не відкриті звичайним користувачам.
Особливо важливо тестувати ситуації, коли користувач намагається обійти інтерфейс і звернутися до функціональності напряму.
Тестування бази даних
Зміни в базі даних потрібно тестувати дуже обережно.
Потрібно перевіряти:
- створення нових таблиць;
- зміну полів;
- індекси;
- обмеження;
- міграції;
- сумісність зі старими даними;
- продуктивність запитів;
- коректність зв’язків;
- відсутність втрати даних;
- можливість відкату.
Перед змінами в базі даних потрібно мати резервну копію та зрозумілий план дій.
Тестування оновлень
Оновлення K2 ERP або окремих модулів потрібно тестувати до встановлення на бойову систему.
Потрібно перевірити:
- чи проходить оновлення без помилок;
- чи зберігаються дані;
- чи працюють старі документи;
- чи не зламались звіти;
- чи не змінилася бізнес-логіка випадково;
- чи працюють інтеграції;
- чи коректно застосовані міграції;
- чи можна відкотитися в разі проблеми.
Оновлення без тестування — один із найризикованіших сценаріїв для ERP.
Тестове середовище
Для якісного тестування бажано мати окреме тестове середовище.
Тестове середовище дозволяє:
- перевіряти зміни без ризику для бойових даних;
- моделювати бізнес-сценарії;
- тестувати оновлення;
- перевіряти інтеграції;
- навчати користувачів;
- відтворювати помилки;
- експериментувати з новими модулями.
Не варто перевіряти небезпечні зміни одразу на робочій базі.
Тестові дані
Для тестування потрібні якісні тестові дані.
Вони мають покривати:
- стандартні сценарії;
- нестандартні сценарії;
- порожні значення;
- неправильні значення;
- великі обсяги даних;
- різні ролі користувачів;
- різні статуси документів;
- різні періоди;
- різні валюти;
- різні склади;
- різні контрагенти.
Тестування тільки на одному «ідеальному» прикладі не дає впевненості, що система працює правильно.
Типовий тестовий сценарій
Тестовий сценарій має описувати, що саме потрібно перевірити.
Приклад структури сценарію:
- Назва сценарію.
- Мета перевірки.
- Початкові умови.
- Користувач або роль.
- Послідовність дій.
- Очікуваний результат.
- Фактичний результат.
- Статус перевірки.
- Коментарі або знайдені помилки.
Наприклад:
- Створити замовлення клієнта.
- Додати товар.
- Вказати кількість і ціну.
- Зберегти документ.
- Провести документ.
- Перевірити залишки.
- Перевірити звіт продажів.
- Перевірити друковану форму.
Такий підхід дозволяє не тестувати «на око».
Помилки, які має знаходити тестування
Тестування повинно виявляти:
- помилки в розрахунках;
- некоректні статуси;
- неправильні залишки;
- дублювання документів;
- відсутність перевірок;
- порушення прав доступу;
- повільні запити;
- неправильні звіти;
- помилки API;
- неправильну обробку інтеграцій;
- втрату даних;
- проблеми після оновлення;
- конфлікти між модулями.
Чим раніше знайдено помилку, тим дешевше її виправити.
Тестування і Git
Тестування має бути пов’язане з контролем версій.
У Git бажано фіксувати:
- які зміни були зроблені;
- які тести запускалися;
- які помилки виправлені;
- яка версія потрапила на тестування;
- яка версія потрапила на бойову систему.
Це дозволяє відстежити, після якої зміни з’явилася проблема, і швидше знайти причину.
Тестування перед впровадженням
Перед впровадженням змін на бойову систему потрібно перевірити:
- код;
- міграції;
- документи;
- звіти;
- права доступу;
- інтеграції;
- API;
- продуктивність;
- резервне копіювання;
- можливість відкату;
- інструкції для користувачів.
Особливо обережно потрібно впроваджувати зміни, які впливають на фінанси, склад, виробництво, зарплату або зовнішні обміни.
Роль програміста у тестуванні
Програміст K2 ERP не повинен перекладати всю відповідальність за тестування на користувача.
Розробник має самостійно перевірити:
- що код запускається;
- що основна логіка працює;
- що очевидні помилки виправлені;
- що не зламані пов’язані частини;
- що є зрозумілий опис змін;
- що зміна готова до перевірки аналітиком або користувачем.
Користувач може перевірити бізнес-сценарій, але програміст повинен відповідати за технічну якість.
Роль користувача у тестуванні
Користувач або бізнес-аналітик важливий для перевірки реального процесу.
Саме користувач може сказати:
- чи відповідає функціональність бізнес-вимогам;
- чи зручна форма;
- чи правильний звіт;
- чи не порушена логіка роботи;
- чи враховані винятки;
- чи можна використовувати зміну в реальній роботі.
Тестування ERP має поєднувати технічну перевірку і бізнес-перевірку.
Типові помилки при тестуванні
Поширені помилки:
- тестування тільки одного сценарію;
- тестування тільки успішного випадку;
- відсутність перевірки прав доступу;
- відсутність тестового середовища;
- перевірка одразу на бойовій базі;
- відсутність фіксації результатів;
- ігнорування інтеграцій;
- відсутність регресійного тестування;
- тестування без реальних даних;
- відсутність резервної копії;
- виправлення без повторної перевірки.
Такі помилки створюють ризик, що проблема проявиться вже після запуску.
Хороші практики
Під час тестування коду в K2 ERP варто дотримуватися таких правил:
- Тестувати не тільки код, а й бізнес-сценарій.
- Перевіряти як успішні, так і помилкові ситуації.
- Використовувати тестове середовище.
- Фіксувати результати тестування.
- Перевіряти права доступу.
- Не забувати про регресійні тести.
- Тестувати інтеграції на збоях.
- Перевіряти звіти за контрольними даними.
- Перед оновленням робити резервну копію.
- Повторно тестувати після виправлення помилки.
- Пов’язувати зміни з Git-комітами.
- Документувати нестандартні сценарії.
Практичний висновок
Тестування коду в K2 ERP — це захист бізнесу від помилок, хаосу та непередбачуваних наслідків.
Якісне тестування дозволяє:
- зменшити кількість помилок;
- безпечніше впроваджувати зміни;
- швидше знаходити причини збоїв;
- підтримувати стабільність ERP;
- контролювати бізнес-логіку;
- підвищувати довіру користувачів;
- зменшувати технічний борг;
- спокійніше оновлювати систему.
ERP без тестування — це ризик.
ERP з нормальним тестуванням — це керована система, яку можна розвивати без страху, що кожна нова зміна зламає стару логіку.
Пояснення термінів
- Тестування коду — перевірка програмної логіки на правильність роботи.
- Модульне тестування — перевірка окремої функції, класу або компонента.
- Інтеграційне тестування — перевірка взаємодії між частинами системи.
- Регресійне тестування — перевірка, що нові зміни не зламали існуючу функціональність.
- Тестове середовище — окрема копія системи для безпечної перевірки змін.
- Тестові дані — спеціально підготовлені дані для перевірки сценаріїв.
- API — інтерфейс для взаємодії між програмними системами.
- Git — система контролю версій.
- Коміт — зафіксована зміна в Git.
- Бойова система — робоча система, у якій працюють реальні користувачі.
- Міграція — зміна структури бази даних або перетворення даних.
- Технічний борг — накопичені проблеми в коді, архітектурі або документації.
Дивіться також
- K2 ERP
- Розробка в K2 ERP
- Похідний код
- IDE в K2 ERP
- Архітектура K2 ERP
- Розгортання системи K2 ERP Python для розробників
- Створення модулів K2 ERP
- Класи та команди K2 ERP Python
- API K2 ERP
- Інтеграції K2 ERP
- База даних K2 ERP
- Рекомендації для розробників K2
- Регламент K2
- Права доступу K2 ERP
- Контроль і аудит K2 ERP
- K2 Update