Testy automatyczne aplikacji bankowych

2015-06-16

Dla jednego z największych banków w Polsce świadczyliśmy usługę konsultingu i wsparcia zespołu testerów przy projekcie automatyzacji testów wewnętrzynych systemów informatycznych. Projekt trwał około roku.

Generalnym celem działań było istotne zwiększenie pokrycia testami aplikacji bankowych oraz odciążenie testerow manualnych.  Realizacja tego celu pozwoliła  przyspieszyć proces wdrażania kolejnych wersji i ograniczyła ilość błędów przy wdrożeniach. Istotna część testowanych systemow dostarczona została przez zewnętrzne firmy jako tzw. „czarne skrzynki”, więc tylko poprzez testowanie interfejsu można było sprawdzić ich działanie w banku. Do testów wykorzystywany był framework Selenium webdriver z różnymi przeglądarkami (internet explorer, firefox) oraz klient Java w postaci jBehave (Behavioral Driven Development) pozwaljący tworzyć skrypty testowe zrozumiałe dla osób nietechnicznych.

Nasz wkład polegał na konsultacjach i kouczingu (w tym pomoc w rozwiązywaniu napotkanych problemów) podczas tworzenia testów automatycznych dla systemów realizujących  około 30 istotnych procesów biznesowych banku. Były to między innymi:

  • Obsługa klienta (system wykorzystywany przez pracowników banku do realizacji najróżniejszych operacji na kontach klientów)
  • Systemy obsługi bankomatow
  • Nowy frontend
  • Centralny system transakcyjny
  • i inne

Spore wyzwanie przy takiej różnorodności środowisk stanowiło zagadnienie odtwarzania  stanu startowego testów (np. danych, kontekstu aplikacji w postaci zintegrowanych komponentów, itp). Na potrzeby testów powstał więc projekt Mock zrealizowany do symulowania centralnej szyny danych w przyjazny dla testerów sposób. Mechanizm ten został wpięty pomiędzy testową centralną szynę danych, a testowane wersje aplikacji.
 
Projekt mock

Aplikacja mock-ująca (udająca) centralną szynę danych banku może być łatwo podłączana do istniejących (i często zamkniętych) aplikacji, również dostarczanych przez zewnętrznych dostawców. Mock może działać w trybie nagrywającego proxy pośredniczącego w ruchu pomiędzy aplikacją i szyną danych albo w trybie generowania odpowiedzi autonomicznie (bez komunikacji z szyną). Dla aplikacji wszystko to jest przejrzyste, dokładnie tak samo, jakby komunikowała się z prawdziwą szyną danych. Mechanizmy generowania odpowiedzi są w pełni skryptowalne, zarówno jeśli chodzi o reguły rozpoznawania requestów przychodzących z aplikacji, jak i generowania samej odpowiedzi na taki request. Dzięki temu odpowiedzi nie są zupełnie statyczne i mogą np. wykorzystywać część danych przychodzących w requeście lub dane środowiskowe (zmienne konfigurowane przez test, aktualny czas, itp.). Mock udostępnia także interfejs web do konfiguracji i sterowania pracą, oraz programistyczny (Rest API), który pozwala na zmianę parametrów działania mocka bezpośrednio przez uruchomiony test. Taka architektura pozwala na testowanie różnych wariantów odpowiedzi na requesty w zależności od wymagań testu (np. jak aplikacja reaguje na prawidłową odpowiedź, jak na błędną, jak na pozytywną, a jak na negatywną, itp.).
 
Tego typu wzorzec wspierania testów może być z powodzeniem stosowany z szerszej gamie testów funkcjonalnych, aczkolwiek w tym wypadku implementacja interfejsów do komunikacji z aplikacją i szyną danych była mocno specyficzna.