Тестування банківського ПЗ (Banking domain applications/BFSI)

Банківські програми (Сектор BFSI або Banking, Financial Services, and Insurance - банківські, фінансові послуги та страхування) є одними з найскладніших додатків у сучасній індустрії розробки та тестування програмного забезпечення. Що робить банківські програми такими складними? Який підхід слід використовувати для тестування складних робочих процесів, пов'язаних із банківськими програмами? Банківські програми безпосередньо пов'язані з конфіденційними фінансовими даними. Усі операції, що виконуються банківським програмним забезпеченням, мають виконуватися без збоїв та помилок. Банківське ПЗ виконує різні функції, такі як переказ та внесення коштів, запит балансу, історія транзакцій, виведення коштів тощо. Тестування банківської програми гарантує, що ці дії не тільки добре виконуються,

Давайте спочатку розберемося з характеристиками банківської програми:

• Багаторівнева функціональність для підтримки тисяч одночасних сеансів користувача;

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

• Складні бізнес-процеси;

• Обробка в режимі реального часу та пакетна обробка (Real-Time and Batch processing);

• Висока швидкість транзакцій на секунду;

• Безпечні транзакції;

• Надійний розділ звітності для відстеження повсякденних трансакцій;

• Суворий аудит для усунення проблем клієнтів;

• Масивна система зберігання;

• Управління аварійними ситуаціями/відновленнями.

Що робить банківські програми такими складними?

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

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

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

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

• Очікується, що банківські послуги працюватимуть 24*7 із високою продуктивністю. Оновлення програмного забезпечення, миттєві виправлення тощо не повинні вплинути на цю доступність;

• На банківський світ також сильно впливають постійні зміни, які уряд вносить у вигляді банківських правил. Будь-які зміни у структурі оподаткування вплинуть і на банківську систему;

• Банківська система також має бути сучасною щодо нових технологій. Аналітика даних, така як обробка великих даних, і отримання інформації з великих даних за допомогою науки даних (Data Science), стають все більш популярними в банківському світі.

Коли ми говоримо про тестування банківських програм, потрібна методологія наскрізного тестування (End to End Testing methodology), що включає кілька методів тестування програмного забезпечення, щоб гарантувати:

• Повне охоплення всіх банківських робочих процесів (banking workflows) та бізнес-вимог (Business Requirements);

• Функціональний аспект програми;

• Аспект безпеки програми;

• Цілісність даних (Data Integrity);

• Паралелізм (Concurrency);

• Користувальницький досвід.

Banking App Testing Workflow

Типові етапи тестування банківських додатків показані в наведеному нижче робочому процесі. Ми обговоримо кожний етап індивідуально. Це модель Waterfall для тестування програми.

1. Збір вимог : етап збору вимог включає документування вимог або у вигляді функціональних специфікацій (Functional Specifications), або у вигляді варіантів використання (Use Cases). Вимоги збираються відповідно до потреб клієнтів та документуються банківськими експертами чи бізнес-аналітиками. Експерти беруть участь у написанні вимог на більш ніж одну тему, оскільки банківська справа сама по собі має кілька піддоменів, і один повноцінний банківський додаток інтегруватиме всі ці домени. Наприклад, банківський додаток може мати окремі модулі для переказів, кредитних карток, звітів, позичкових рахунків, оплати рахунків, торгівлі тощо;

2. Огляд вимог : результати збору вимог перевіряються всіма заінтересованими сторонами, такими як QA, керівники розробки та бізнес-аналітики. Вони перевіряють ще раз, щоб ні існуючі бізнес-процеси, ні нові робочі процеси не порушувалися. Усі вимоги перевірено та затверджено. Наступні дії та перегляди документів вимог виконуються на основі того ж;

3. Підготовка бізнес-сценарії : на цьому етапі QA складають бізнес-сценарії (Business Scenarios) з документів з вимогами (requirement documents - Functions Specs or Use Cases); Бізнес-сценарії розроблені таким чином, що охоплюють усі бізнес-вимоги. Бізнес-сценарії - це сценарії високого рівня без будь-яких докладних кроків. Крім того, ці бізнес-сценарії перевіряються бізнес-аналітиками, щоб переконатися, що всі бізнес-вимоги виконані. BA легше переглядати сценарії високого рівня, ніж переглядати детальні тестові випадки низького рівня. Наприклад, клієнт, який відкриває терміновий депозит в інтерфейсі цифрового банкінгу, може бути бізнес-сценарієм. Так само у нас є різні бізнес-сценарії, пов'язані зі створенням банківського рахунку, онлайн-депозитами, онлайн-переказами тощо;

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

• Підготовка тестових випадків (Test Case Preparation): на цьому етапі тестові випадки створюються на основі бізнес-сценаріїв, один бізнес-сценарій призводить до кількох позитивних та негативних тестових випадків;

• Огляд тестових випадків (Test Case Review): огляди, зроблені колегами-інженерами із забезпечення якості;

• Виконання тестових випадків (Test Case Execution): Виконання тестового набору.

Функціональне тестування банківської програми дуже відрізняється від звичайного тестування програмного забезпечення. Оскільки ці програми працюють із грошима клієнтів та конфіденційними фінансовими даними, їх необхідно ретельно протестувати. Жоден важливий бізнес-сценарій не повинен залишатися непоміченим. Крім того, ресурс QA, який тестує програму, повинен мати базові знання у банківській області.

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

• Завантаження даних;

• Міграція бази даних;

• Тестування схеми БД та типів даних;

• Тестування правил;

• Тестування процедур і функцій, що зберігаються;

• Тестування тригерів;

• Цілісність даних.

Основна мета тестування бази даних полягає в тому, щоб переконатися, що:

• Програма може зберігати та витягувати дані з бази даних без втрати даних;

• Завершені транзакції мають бути зафіксовані, а перервані транзакції мають бути повернуті назад, щоб уникнути будь-яких невідповідностей у збережених даних;

• Доступ до бази даних та базових таблиць дозволено лише авторизованим додаткам та користувачам.

В основному існує три способи тестування бази даних:

• Структурне тестування: включає тестування об'єктів бази даних, таких як бази даних, схеми, таблиці, уявлення, тригери, елементи управління доступом і т. д. Забезпечення синхронізації типів даних у таблицях з відповідними змінними в додатку. Перевірка даних та цілісності посилання в таблицях. Наприклад, поле суми у додатку повинно мати у таблиці тип даних decimal/float. Щоб відповідати цим стандартам, користувачам слід надати засоби керування доступом через уявлення;

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

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

6. Тестування безпеки: тестування безпеки є останнім етапом циклу тестування. Обов'язковою умовою для початку тестування безпеки є завершення функціонального та нефункціонального тестування. Тестування безпеки одна із основних етапів всього циклу тестування додатків, оскільки цьому етапі забезпечується відповідність докладання федеральним і галузевим стандартам. Через характер даних, які вони несуть, банківські програми дуже чутливі і є головною метою для хакерів та шахрайських дій. Тестування безпеки гарантує, що програма не має таких веб-уразливостей, які можуть розкрити конфіденційні дані зловмиснику. Це також гарантує, що програма відповідає таким стандартам, як OWASP. На цьому етапі основним завданням є сканування всієї програми,різних інструментів . Після завершення сканування публікується звіт про сканування. У цьому звіті помилкові спрацьовування відфільтровуються, а інші уразливості повідомляються команді розробників, щоб вони могли розпочати усунення проблем залежно від серйозності кожної проблеми. На цьому етапі проводиться тестування на проникнення, щоб виявити поширення помилок. Необхідно проводити ретельне тестування безпеки на різних платформах, мережах та ОС. Декілька інших використовуваних ручних інструментів для тестування безпеки: Paros Proxy, Http Watch, Burp Suite та Fortify. Основна мета тестування безпеки – виявити будь-які вразливості, які можуть бути у програмному додатку.

Тестування безпеки перевіряє додаток на:

• Будь-яку зовнішню атаку або спробу злому додатку зі злим наміром;

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

• Будь-яку вразливість у мережі, серверах або робочих станціях, на яких розміщено програму.

Нижче наведено різні типи тестування безпеки:

• Тестування уразливостей (Vulnerability Testing): розробляється та виконується автоматизована програма для перевірки на наявність різних уразливостей;

• Сканування безпеки (Security Scanning): цей варіант обертається навколо дослідження вразливостей мережі та системи, тим самим надаючи рішення для зниження пов'язаного з цим ризику;

• Тестування на проникнення (Penetration Testing): цей варіант тестування безпеки імітує спробу злому для захоплення вразливостей та лазівок, які могли б дати хакеру доступ до бази даних або даних програми;

• Аудит безпеки (Security Audit): це включає аудит програми і пов'язаних мереж на предмет будь-яких порушень безпеки;

• Оцінка ризику (Risk Assessment): виконується аналіз для оцінки рівня ризику у випадку, якщо вразливість або лазівка ​​використовуються зі злим наміром. Такий ризик можна розділити на низький, середній та високий. Залежно від рівня ризику, група тестування рекомендує належні заходи для зниження або запобігання ризику;

• Етичний злом (Ethical Hacking): виконується організацією у своїх системах для виявлення лазівок, які можуть бути використані у її додатку чи мережі. Мета цього виду злому не полягає в тому, щоб вкрасти або завдати шкоди додатку чи мережі;

• Оцінка стану (Posture Assessment): це комплексна оцінка, що включає сканування безпеки, оцінку ризиків та злом з дотриманням етичних норм;

• SQL-ін'єкція : SQL-ін'єкція може використовуватися для отримання доступу до бази даних сервера. Тестування виконується, щоб переконатися, що код працює правильно, виконуючи запити в базі даних на основі наступних вхідних даних від користувача: Дужки, Апострофи, Коми, Кавички.

Інші етапи тестування BFSI додатків

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

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

• Для нової філії (New Branch):

  • Створіть нову філію з допустимими та недійсними тестовими даними;

  • Створіть нову філію без даних;

  • Створіть нову філію з наявними даними;

  • Перевірте параметри скидання та скасування;

  • Поновіть відомості про філію з допустимими та недійсними тестовими даними;

  • Поновіть відомості про філію за допомогою наявних тестових даних;

  • Перевірте, чи можна зберегти нову філію;

  • Переконайтеся, що опція скасування працює;

  • Перевірте видалення філії із залежностями та без них;

  • Перевірте, чи працює опція пошуку філій.

• Для нової ролі:

  • Створіть нову роль з допустимими та недійсними тестовими даними;

  • Створіть нову роль без даних;

  • Перевірте, чи можна створити нову роль із існуючими тестовими даними;

  • Перевірте опис ролі та тип ролі;

  • Переконайтеся, що опція скасування та скидання працює;

  • Перевірте процес видалення ролі із залежністю і без неї;

  • Перевірте посилання на сторінці відомостей про роль.

  • Перевірте вхід адміністратора без тестових даних;

  • Перевірте всі домашні посилання на роль адміністратора;

  • Переконайтеся, що адміністратор може змінити пароль із допустимими та недійсними тестовими даними;

  • Переконайтеся, що адміністратор успішно вийшов із системи.

• Для Клієнта та Банкіра:

  • Переконайтеся, що посилання відвідувачів і клієнтів працюють правильно;

  • Перевірте вхід клієнта з дійсними та недійсними тестовими даними;

  • Перевірте логін клієнта без будь-яких даних;

  • Перевірте логін банкіра без будь-яких даних;

  • Перевірте логін банкіра з дійсними або недійсними тестовими даними

  • Перевірте, чи зміг клієнт та банкір успішно вийти із системи.

• Для нових користувачів:

  • Перевірте, чи можна створити нового користувача з допустимими та недійсними тестовими даними;

  • Створіть нового користувача з наявними тестовими даними філії;

  • Переконайтеся, що опція скасування та скидання працює правильно;

  • Оновіть відомості про користувача, вказавши дійсні та недійсні тестові дані;

  • Перевірте видалення нового користувача;

  • Перевірте, чи можна верифікувати нового користувача;

  • Перевірте обов'язкові параметри;

  • Перевірте додаткові параметри;

  • Перевірте, чи можна створити користувача без додаткових параметрів.

• Для створення нового облікового запису:

  • Створіть новий обліковий запис із дійсними та недійсними даними користувача;

  • Переконайтеся, що інформація про користувача може бути оновлена;

  • Перевірте, чи можна зберегти нового користувача;

  • Створіть новий обліковий запис з наявними даними користувача;

  • Переконайтеся, що користувач може внести суму до новоствореного облікового запису (і оновити баланс);

  • Перевірте, чи може користувач зняти суму з нового облікового запису (після внесення депозиту та оновлення балансу);

  • У разі заробітної плати обліковий запис перевіряє назву компанії та інші дані, надані користувачем;

  • Перевірте, чи вказано номер основного облікового запису у разі додаткового облікового запису;

  • Перевірте дані користувача, зазначені у разі поточного облікового запису;

  • Перевірте наведений доказ для спільного рахунку у разі сумісного рахунку;

  • Перевірте, чи можете ви підтримувати нульовий баланс на рахунку заробітної плати;

  • Перевірте, чи можете ви підтримувати нульовий або мінімальний баланс для рахунку, не пов'язаного із зарплатою;

  • Переконайтеся, що новий користувач успішно вийшов із системи.

• Для мережевого банківського додатку (Net Banking Application):

  • Користувач може відкрити сайт банку;

  • усі посилання на сайті працюють;

  • користувач може створити новий обліковий запис;

  • Перевірте, чи може користувач увійти до системи з допустимим і недійсним ім'ям користувача та паролем.

  • Перевірте, що якщо ім'я користувача або пароль порожні при вході в систему, користувачеві не повинно бути дозволено увійти до системи, і відображатиметься попереджувальне повідомлення;

  • Перевірте, чи дозволено користувачеві змінювати пароль;

  • Якщо введено неправильне ім'я користувача або пароль, буде відображено відповідне повідомлення про помилку;

  • Користувачам з неправильним паролем не дозволяється входити до системи;

  • Переконайтеся, що після неодноразових спроб входу з неправильним паролем користувачеві має бути показане повідомлення про помилку та його заблоковано;

  • Перевірте, чи користувач може виконувати деякі основні транзакції;

  • Переконайтеся, що користувач може додати одержувача з допустимими та недійсними даними;

  • Перевірте, чи користувач може видалити одержувача;

  • Переконайтеся, що користувач може здійснювати транзакції для нового одержувача;

  • Після транзакції перевірте, чи обновлено облікові записи користувача та одержувача;

  • Перевірте, чи може користувач ввести суму у десятковому вигляді (4.50);

  • Переконайтеся, що користувач не може вводити негативні числа у поле суми;

  • Перевірте, чи дозволено користувачеві здійснювати транзакції з мінімальним балансом або без нього;

  • Перевірте, чи користувач може створити новий RD;

  • Переконайтеся, що відображається правильне повідомлення у випадку транзакції, виконаної з недостатнім балансом;

  • Перевірте, чи запитується у користувача підтвердження перед виконанням будь-якої транзакції;

  • Переконайтеся, що квитанції про підтвердження надано для кожної успішної транзакції;

  • Перевірте, чи може користувач переказувати гроші на кілька рахунків;

  • Перевірте, чи може користувач скасувати транзакцію;

  • Переконайтеся, що дані облікового запису відображають виконані фінансові операції;

  • Переконайтеся, що функцію тайм-ауту реалізовано;

  • Переконайтеся, що у разі закінчення часу сеансу користувач має знову увійти до системи;

  • Переконайтеся, що у випадку бездіяльності встановлено правильний тайм-аут сеансу;

  • Переконайтеся, що при виконанні транзакції переведено в безпечний режим;

  • Переконайтеся, що користувач зміг успішно вийти із системи;

  • Перевірте параметри пошуку та скидання.

Джерела:

• How To Test Banking Applications: A Complete BFSI Testing Guide

Дод. матеріал:

• How To Test Investment Banking Application (З 34+ Important Test Scenarios)
• How To Test Retail Banking System