Тестування коду

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

моделювати бізнес-сценарії;
тестувати оновлення версій;
перевіряти інтеграції;
навчати користувачів;
відтворювати помилки;
експериментувати з новими модулями. * зменшити кількість помилок;
безпечніше впроваджувати зміни;
швидше знаходити причини збоїв;
підтримувати стабільність ERP;
контролювати бізнес-логіку;
підвищувати довіру користувачів;
зменшувати технічний борг;
спокійніше оновлювати систему. * Технічний борг — накопичені проблеми в коді, архітектурі або документації. # Перед оновленням робити резервну копію.== Тестування і Git ==

Потрібно перевіряти: Тестування потрібне для того, щоб переконатися:

помилки в розрахунках;
некоректні статуси;
неправильні залишки;
дублювання документів;
відсутність перевірок;
порушення прав доступу;
повільні запити;
неправильні звіти;
помилки API;
неправильну обробку інтеграцій;
втрату даних;
проблеми після оновлення версій;
конфлікти між модулями. Документ у ERP — це не без зусиль форма.== Тестові інформаційні дані ==

Тестування має бути пов’язане з контролем версій. API потрібно тестувати як окремий ERP-продукт. Перед змінами в базі даних потрібно мати резервну копію та зрозумілий план дій. перевірки того забезпечується через Регресійне тестування потрібне; так само реалізовано що нові зміни не зламали стару функціональність. Це особливо критично після:

Чому тестування важливе для ERP

оновлення версій без тестування — один із найризикованіших сценаріїв для ERP.== Тестування перед впровадженням ==

Тестування тільки на одному «ідеальному» прикладі не дає впевненості, що платформа функціонує правильно.== Типові помилки при тестуванні ==

Створити замовлення клієнта. # Вказати кількість і ціну. API часто застосовують, коли потрібно зовнішніми системами, тому помилки в ньому можуть впливати не лише на K2 ERP, а й на сайт, CRM, мобільний застосунок, маркетплейс або іншу платформу.== Модульне тестування ==

Роль користувача у тестуванні

функція розрахунку суми;
перевірка знижки;
алгоритм формування номера документа;
правило округлення;
обробка статусу;
перевірка дати;
фільтрація списку;
конвертація даних;
підготовка відповіді API. У реальному бізнесі ідеальні умови трапляються не завжди.== Види тестування ==

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

що новий компонент функціонує відповідно до вимог;
що документи створюються і проводяться правильно;
що звіти показують коректні інформаційні дані;
що API повертає очікуваний результат;
що інтеграції обробляють помилки;
що права доступу не порушені;
що оновлення версій не пошкоджує інформаційні дані;
що бізнес-процес після зміни залишається керованим. * правильність запитів;
формат відповіді;
авторизацію;
права доступу;
обробку помилок;
обов’язкові поля;
некоректні інформаційні дані;
дублікати;
швидкість відповіді;
стабільність контракту;
версіонування;
журналювання;
поведінку при недоступності зовнішнього сервісу. # Фіксувати результати тестування. # Тестування прав доступу — перевірка, хто що здатна бачити, створювати, змінювати або запускати.== Тестування документів ==

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

Погано протестований довідник здатна створювати проблеми в документах, звітах та інтеграціях. # Автоматизоване тестування — запуск тестів, які перевіряють код автоматизовано. # Повторно тестувати після виправлення помилки. * Бойова платформа — робоча платформа, у якій працюють реальні користувачі. * джерело даних;

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

Потрібно перевіряти:

Тестування коду — перевірка програмної логіки на правильність роботи. Потрібно перевіряти:

У Git бажано фіксувати:

Це здатна бути:

Хороші практики

У K2 ERP можуть застосовуватися різні види тестування. Він має працювати правильно. Окремо кожна частина здатна працювати правильно, але разом вони дають неправильний результат. Це дія, яка здатна змінювати стан бізнесу. Розробник має самостійно перевірити:

як приклад, якщо змінено правило розрахунку знижки, тест здатна одразу показати, що для певного типу клієнта результат став неправильним. # Тестування оновлень — перевірка переходу системи з однієї версії на іншу. В ERP помилка здатна означати:

Ручне тестування

Пояснення термінів

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

як приклад, якщо замовлення не можна відвантажити без оплати, тест має перевірити не тільки стандартний сценарій, а й спробу обійти це правило через API, зміну статусу або іншу дію. Це дає можливість відстежити, після якої зміни з’явилася проблема, і швидше знайти причину. Саме користувач системи здатна сказати:

Автоматизоване тестування

що код запускається;
що основна логіка функціонує;
що очевидні помилки виправлені;
що не зламані пов’язані частини;
що виступає як зрозумілий SEO-опис змін;
що зміна готова до перевірки аналітиком або користувачем. Зміни в базі даних потрібно тестувати дуже обережно. У ERP одна зміна здатна вплинути на багато пов’язаних процесів. # Перевірити залишки. Ручне тестування потрібне там, де критично перевірити реальний бізнес-сценарій. # Документувати нестандартні сценарії. У K2 ERP тестування розглядається не як формальність і не як «додаткова опція», а як обов’язкова частина відповідальної розробки. # Інтеграційне тестування — перевірка взаємодії між модулями або зовнішніми системами. # Перевірити звіт продажів. * документа і регістру;
модуля продажів і складу;
CRM і замовлень;
ERP і сайту;
ERP і банку;
ERP і служби доставки;
API і зовнішнього клієнта;
звіту і бази даних;
бізнес-процесу і прав доступу. Основні з них:

Інтеграції потрібно тестувати з урахуванням реальних збоїв. # Послідовність дій. * Регресійне тестування — перевірка, що нові зміни не зламали існуючу функціональність. # Перевірити друковану форму. Перед впровадженням змін на бойову систему потрібно перевірити:

Для API критично перевірити:

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

що користувач системи не здатна виконати заборонену дію;
що API так само дотримується прав доступу;
що звіти не показують зайву інформацію;
що кнопки, команди й обробки доступні лише потрібним ролям;
що адміністраторські функції не відкриті звичайним користувачам. * Тестові інформаційні дані — спеціально підготовлені інформаційні дані для перевірки сценаріїв. # користувач системи або роль. # Тестування відмов — перевірка поведінки системи при помилках, недоступності сервісів або некоректних даних.== Тестування бази даних ==

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

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

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

До тестування можуть входити: Потрібно перевіряти:

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

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

Документи в K2 ERP потрібно перевіряти особливо уважно. # Початкові умови. Особливо критично тестувати ситуації, коли користувач системи намагається обійти інтерфейс і звернутися до функціональності напряму. Особливо критично перевіряти звіти, на основі яких приймаються управлінські або фінансові рішення для бізнесу. ERP-система функціонує з реальними бізнес-даними: документами, залишками, фінансами, взаєморозрахунками, замовленнями, складами, виробництвом, клієнтами та звітністю. # Мета перевірки. Тому помилка в коді здатна мати не лише технічні, а й бізнесові наслідки. Тому регресійне тестування виступає як одним із найважливіших видів перевірки. * Модульне тестування — перевірка окремої функції, класу або компонента. У звичайній програмі помилка здатна означати некрасивий інтерфейс або неправильне повідомлення.== Що потрібно тестувати ==

Тестування оновлень

Тестове середовище

У K2 ERP потрібно тестувати не тільки окремі функції Python-коду, а всю поведінку системи. * створення нових таблиць;

зміну полів;
індекси;
обмеження;
міграції;
сумісність зі старими даними;
продуктивність запитів;
коректність зв’язків;
відсутність втрати даних;
можливість відкату.== Тестування API ==

Головна ідея

Програміст K2 ERP не повинен перекладати всю відповідальність за тестування на користувача. # Фактичний результат. Під час тестування коду в K2 ERP варто дотримуватися таких правил:

створення запису;
редагування;
пошук;
фільтрацію;
унікальність;
обов’язкові поля;
ієрархію;
зв’язки з документами;
імпорт;
експорт;
права доступу;
архівацію або деактивацію. * Git — платформа контролю версій. # Не забувати про регресійні тести. як приклад:

Приклад структури сценарію:

Звіти потрібно перевіряти не тільки на відкриття, а й на правильність даних. # Статус перевірки. Тестування повинно виявляти:

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

міграції;
документи;
звіти;
права доступу;
інтеграції;
API;
продуктивність;
резервне копіювання;
можливість відкату;
інструкції для користувачів.== Регресійне тестування ==

оновлення версій K2 ERP або окремих модулів потрібно тестувати до встановлення на бойову систему.== Тестування бізнес-логіки ==

Ручне тестування особливо корисне на етапі впровадження або перевірки нестандартної бізнес-логіки. # Ручне тестування — перевірка сценаріїв користувачем, програмістом або аналітиком. # Провести документ. * Інтеграційне тестування — перевірка взаємодії між частинами системи. * Тестове середовище — окрема копія системи для безпечної перевірки змін. # Зберегти документ. * оновлення версій модуля;

зміни бізнес-логіки;
рефакторингу;
оптимізації запитів;
зміни структури бази даних;
додавання нової інтеграції;
зміни прав доступу;
виправлення помилки. * Коміт — зафіксована зміна в Git. * створення;
редагування;
збереження;
проведення;
скасування проведення;
видалення;
зміну статусу;
табличні частини;
обов’язкові поля;
автоматичні розрахунки;
друковані форми;
зв’язки з іншими документами;
вплив на залишки;
вплив на фінансовий блок;
відображення у звітах;
права доступу.== Джерела ==

модулі;
класи;
команди;
документи;
довідники;
звіти;
друковані форми;
API;
інтеграції;
права доступу;
міграції бази даних;
оновлення версій;
імпорт і експорт даних;
фонові задачі;
обробки;
бізнес-процеси;
дії користувача в інтерфейсі. Права доступу виступає як критичною частиною тестування. Це особливо корисно для:

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

Такий підхід дає можливість не тестувати «на око». # Використовувати тестове середовище. # Пов’язувати зміни з Git-комітами. # Перевіряти права доступу. * тестування тільки одного сценарію;

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

успішний обмін;
повторну відправку;
часткову помилку;
недоступність зовнішнього сервісу;
неправильний формат відповіді;
дублювання даних;
затримку відповіді;
зміну статусів;
журнал обміну;
ручне повторення операції;
повідомлення адміністратору;
відкат або компенсацію дій. Окремо варто відзначити модулів, документів, звітів, API, інтеграцій, прав доступу і оновлень перед використанням змін у реальній роботі підприємства виступає ключовою рисою SEO title: Тестування коду в K2 ERP — перевірка якості, стабільності та безпеки ERP-розробки

SEO keywords: тестування коду K2 ERP, K2 ERP тестування, Python тести K2 ERP, тестування ERP, тестування модулів K2 ERP, тестування API K2 ERP, тестування інтеграцій K2 ERP, регресійне тестування ERP, автоматизоване тестування ERP, ручне тестування ERP, якість коду K2 ERP, перевірка бізнес-логіки ERP, тестування документів ERP, тестування звітів ERP, тестування прав доступу, Git K2 ERP, CI CD ERP, розробка K2 ERP, Python ERP

</noinclude>
 {{SEO
Шаблон для службового SEO-опису сторінки.

}}

Тестування коду в K2 ERP. * чи проходить оновлення версій без помилок;

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

Під час тестування документа варто перевірити:

Для тестування потрібні якісні тестові інформаційні дані.== Тестування довідників == Тестування коду в K2 ERP — це захист бізнесу від помилок, хаосу та непередбачуваних наслідків. Потрібно перевірити:

Тестувати не тільки код, а й бізнес-сценарій. # Тестування продуктивності — перевірка швидкості роботи запитів, звітів, API та обробок. # Тестувати інтеграції на збоях. Але ручне тестування не повинно бути єдиним способом контролю якості. Під час тестування звіту варто перевірити:

ERP з нормальним тестуванням — це керована платформа, яку можна розвивати без страху, що кожна нова зміна зламає стару логіку.== Дивіться так само ==

Чим раніше знайдено помилку, тим дешевше її виправити.== Тестування прав доступу ==