Як і будь-який бізнес банківська система сьогодні надзвичайно видозмінилася і теж максимально наблизилася до своїх клієнтів. Для нас банк по комп’ютеру чи по телефону звична річ. Замість очікування у черзі консультації із працівником банку => ми отримали, онлайн телефонію, онлайн-чати з працівниками банку, SMS сповіщення, online ботів.

Банківські послуги теж наповнені прогресивними технологіями, із все більш складною функціональністю інтеграції з іншими системами. Популярні різноманітні додатки, мобільні гаманці, миттєві перекази, Pay Pass.

Але що означає хороша банківська програма?

Перш за все програма повинна бути здатною обробляти складні бізнес-процеси. Тому Requirement Analysis — збір вимог і документування. Requirement Review — огдяд і перехресна перевірка документації мають неабияке значення щоб максимально передбачити і задовільняти згодом потребам своїх клієнтів у Business key & Business Go.

Сучасна банківська програма повинна бути доступною, клієнти все частіше вимагають доступу 24/7 без прив’язки до банківських днів і операційних годин. З будь-якої локації. Звідси постає потреба постійного мобільного, хмарного та інтернет-покриття. Або робота певного функціоналу без мережі, а потім конект, синхронізація дій із банком, відправка даних.

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

Повинна бути підтримка різноманітних клієнтів: фізичні особи, корпоративні клієнти, індивідуальні підприємці, послуг: позики, депозити, ощадні рахунки тощо. Реалізована підтримка користувачів з різними платіжними системами (VISA, AMEX, MasterCard).

Бути доступною на різних платформах (Mac, Linux, Unix, Windows)

Забезпечена підтримка іншомовних користувачів, інклюзивних користувачів.

Існує нова тенденція для цифрових банків і віртуальних кредитних спілок, які не мають філій. У таких фінансових установ завдання полягає запропонувати максимально просту, зрозумілу схему надання послуг і зручну функціональність UI/UX. Наприклад, ті ж самі Монобанк, АлєксКредіт.

Performance — однозначно важливо!!! банківська аплікація повинна працювати швидко і повинна підтримувати тисячі одночасних сеансів користувачів. Витримувати пікові події, сплески платежів. Обов’язково повинен бути передбачений розумний механізм управління і повідомлення про виникнення якихось труднощів. Оскільки невдачі в роботі на банківських порталах можуть серйозно вплинути на користувача. Окрім Performance обов’язково потрібно ще проводити Stress, Load, Soak, Spike Testing.

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

Complience & Legasy — відповідність міжнародним стандартам і стандартам регулювання банківської діяльності у тій чи іншій країні є обов’язковою та критично важливою для бізнесу вимогою. Із BASEL IV, MiFID II, GDPR, директивами щодо відмивання грошей та інших нормативних документів, які постійно надходять по оновленню регуляторних питань. Дотримання цих різноманітних норм тягне за собою величезні витрати та зусилля з боку банків, а надійна перевірка на Complience може зекономити значні гроші та час.

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

Чим критично відрізняється тестування банківської програми від будь-якої іншої?

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

У банках зазвичай працює велика кількість працівників, яких потрібно щоразу адаптувати до нових версій продукту, фіч. Дуже часто вони виступають і у ролі Альфа та Бета тестерів.  Тому документація повинна бути ретельно систематизованою і описаною.

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

Web Security — банківські системи повинні обробляти транзакції не тільки швидко, але й безпечно. За своєю суттю банківські системи є омріяною мішенню для злому та шахрайської діяльності. Vulnerability testing & penetration testing (тестуванн вразливості та тестування на проникненн) можуть виявити значні хиби у системі.

При проникненні/вході в систему щоб передбачити несанкціонований доступ потрібно встановити повідомлення інформування. Хоча для запобігання злому, банк також повинен впровадити багатошарову перевірку доступу, як одноразовий пароль скажімо на телефон. Для тестування безпеки використовуються засоби автоматизації, такі як IBM AppScan та HPWebInspect, тоді як для інструментів ручного тестування, такі як Proxy Sniffer, Paros proxy тощо.

Рев’ю коду можуть також виявити слабкі сторони.

Повернемося до Compliance — дотримання міжнародних стандартів безпеки, таких як PCI DSS, є надзвичайно важливим моментом.

PCI DSS гарно українською описано у блозі Easy Pay посилання активне

Наприклад, не знаючи, як влаштовані cookie-файли, можна пропустити помилки, пов’язані з безпекою, або не перевірити випадки, коли термін життя cookie-файлу минув.

Ключове у банківських додатках окрім захисту коштів, захистити конфіденційні дані користувача.

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

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

Приклади тест-кейсів:

Для адміністратора:

  • Перевірити логування адміністратора за допомогою дійсних та недійсних даних.
  • Перевірити чи буде відбуватись вхід адміністратора без даних.
  • Перевірити всі домашні посилання адміністратора та надані йому права.
  • Спробувати  змінити пароль адміністратора на правильні та недійсні дані.
  • Спробуйте  змінити пароль адміністратора без даних.
  • Перевіртити пароль адміністратора зі зміненими даними.
  • Перевірити вихід адміністратора.

Додавання операцій:

  • Створити нову гілку з дійсними та невірними даними.
  • Створити нову гілку без даних.
  • Створити нову гілку з наявними даними про філію.
  • Перевірити параметр скидання та скасування.
  • Оновити меню/перейти на ін. розділ з дійсними та недійсними даними.
  • Оновити сторінку без ведення даних.
  • Оновити операцію наявними даними.
  • Підтвердити параметр скасування операції.
  • Перевірити видалення гілки із залежностями та без них.
  • Перевірити варіанти меню пошуку.

Створення ролей юзерів:

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

Тест-кейси для юзерів:

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

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

До теми читайте:

Безпека розрахунків банківськими картками в інтернеті 

Related posts

2 коментарі

Leave a Comment

Цей сайт використовує Akismet для зменшення спаму. Дізнайтеся, як обробляються ваші дані коментарів.