Kulisy pracy testera w sektorze bankowym

Jeśli zastanawiasz się czy praca testera w banku wygląda tak samo jak praca testera w innych miejscach, np. software house'ach, poniższy artykuł może Cię zainteresować. 

Na wstępie pragnę zaznaczyć, że tekst bazuje na mojej subiektywnej ocenie. Pracując wiele lat w działach testów w bankach poznałam nieco specyfikę tej pracy i chętnie Ci ją przybliżę. Nie oznacza to, rzecz jasna, że w każdej instytucji finansowej proces testowy wygląda tak samo. Przypuszczam jednak, że ze względu na charakter zaufania publicznego jakie one pełnią, pewne procesy są w nich ustandaryzowane.

Jak trafiłam do działu testów w banku?

Już wiele lat temu, będąc jeszcze pracownikiem call center, miałam okazję zasmakować pracy jako tester oprogramowania. Bank, który obsługiwałam wdrażał wówczas nową usługę dla klientów związaną z interaktywną obsługą telefoniczną – w testowanie tego projektu zaangażowano także kilka osób z mojego działu, dzięki temu już wtedy miałam okazję sprawdzić się jako tester. Produkcyjny system banku był mi już znany a weryfikowanie czy nowe artefakty komunikują się z nim w prawidłowy sposób sprawiło mi dużą frajdę. Dzięki ścisłej współpracy z analitykiem systemów informatycznych, deweloperem i starszym testerem, poznałam bliżej proces wytwarzania oprogramowania oraz rolę, jaką pełni w nim tester. W niedługim czasie w ramach rekrutacji wewnętrznej przeszłam do działu testów i tak zaczęła się moja przygoda z testowaniem oprogramowania. Można powiedzieć więc, że testy dla banków są mi wyjątkowo bliskie.

Poznaj, a zrozumiesz

Jestem zdania, że zrozumienie dla pewnych sytuacji przychodzi dopiero w momencie poznania ich bliżej. Zapewne większość z nas podczas zakupów była kiedyś świadkiem tego jak roztrzęsione dziecko krzyczy przy regale a obok stoją bezradni rodzice? Ilu będzie współczuć rodzicom, a ilu ich potępiać? Otóż to! Nikt nie zrozumie tej sytuacji tak dobrze, jak rodzice posiadający równie niesforne urwisy. Proszę wybaczyć ten przykład ale skojarzył mi się on ze zrozumieniem dla systemów informatycznych. By the way, czyż dzieci nie są idealnymi testerami systemu nerwowego swoich rodziców? 😉

Chcę przez to powiedzieć, że po wejściu w świat IT banku stałam się bardziej świadoma tego, co tak naprawdę odbywa się pod spodem (w backendzie) aplikacji wyświetlanej doradcy klienta. Zdałam sobie sprawę, że kliknięcie przez operatora w button „Sprawdź ofertę” generuje szereg wywołań do baz i innych systemów – ma prawo to chwilę potrwać, ale musi działać dobrze! Pojawiło się zrozumienie dla pani z konkurencyjnego banku, która zakłopotana wyjaśniała, że właśnie trwa aktualizacja danych. Pojawiła się też duma, że u nas działa to szybciej a ja mogę testować systemy, których dotychczas używałam jako klient lub doradca klienta.

Bez wątpienia, będąc jednocześnie użytkownikiem końcowym aplikacji oraz jej testerem, co jest możliwe w przypadku bankowości elektronicznej, o wiele lepiej rozumiemy jej sposób działania. Jako tester nie musimy stawiać się w roli użytkownika systemu, ponieważ nim jesteśmy a nasze korzystanie z aplikacji bankowej w domowym zaciszu jest niczym test usability „po godzinach”. Rozumiemy też doskonale, że w przypadku awarii nie mamy co liczyć na zrozumienie ze strony klientów, zatem do przeprowadzanych testów należy podejść poważnie.

Tester pracujący w banku, jeśli jeszcze nie jest jego klientem, to z pewnością prędzej czy później nim zostanie. Będzie bowiem ciekaw jak aplikacja zachowuje się „w realu”. Prawdopodobnie spotka się też kiedyś z prośbą dewelopera aby porównać „jak coś działa obecnie na produkcji”. W każdym razie ja po rozpoczęciu testów szybko podpisałam umowę umożliwiającą dostęp do bankowości internetowej 🙂

Liczby mówią wiele

Z danych podanych przez Związek Banków Polskich na koniec III kwartału 2020 liczba klientów korzystających aktywnie z bankowości elektronicznej (internetowej i mobilnej) sięgnęła 19,3 mln. Już sama ta liczba pokazuje, że mamy do czynienia z systemami o bardzo dużym zasięgu, będącymi w powszechnym użyciu milionów użytkowników. Pracując jako tester systemów bankowych trzeba być świadomym tego, że ewentualne zaniedbania w testach mogą przynieść olbrzymie straty wizerunkowe i finansowe, a o awariach będziemy czytać w internecie. Jest to duża odpowiedzialność. Co więcej, banki konkurują między sobą także na polu wprowadzanych rozwiązań cyfrowych, dlatego priorytetem jest, żeby innowacja szła w parze z jakością dostarczanych rozwiązań. Testerzy w dużym stopniu przyczyniają się do zapewnienia tej jakości.

Systemy bankowe to oczywiście nie tylko bankowość internetowa, mobilna czy telefoniczna – z nich klient banku korzysta bezpośrednio. Nie można jednak zapominać o systemie centralnym, z którego korzystają doradcy w placówkach i cała centrala banku. Obok nich są systemy księgowe czy hurtownia danych. Wszystkie one współdziałają ze sobą. W każdym z nich przyszło mi przeprowadzać testy lub weryfikację jak jedna aplikacja wpływa na inną. To niewątpliwa zaleta pracy w tej branży – testowanie nie ogranicza się do jednej aplikacji lecz polega na testach integracji między nimi.

Trochę więcej o specyfice pracy i środowiskach testowych

Dział Testów, w którym zaczynałam współpracował ściśle z Działem Oprogramowania Biznesowego oraz Działem Analizy Systemowej. W dobie obecnych spotkań online z sentymentem wspominam omawianie działania systemu z programistami przy kawie we wspólnej kuchni. Dział Analiz dostarczał w formie specyfikacji wymagania systemowe niezbędne do przeprowadzenia testów, natomiast wymagania biznesowe co do zmian potrzebnych w systemie, płynęły od Departamentu Rozwoju Produktów Bankowych. W przypadku organizacji, w której pracowałam, ta współpraca była bardzo dobra – wszyscy stacjonowaliśmy w jednej centrali i graliśmy do jednej bramki.

Większe wdrożenia odbywały się średnio co 1-2 miesięce. W ramach takiego wydania możliwe były zmiany w różnych obszarach i systemach. Na przykład w wydaniu 2008.x.x. mogły być wprowadzane zmiany dotyczące bankowości internetowej oraz systemu centralnego. Dla każdego wdrożenia, w systemie do zarządzania projektami,  przygotowywany był tzw. RFC wdrożeniowy (Request for comments). Był to spis wszystkich zmian technicznych, jakie w zadanej kolejności trzeba będzie wykonać podczas wdrożenia produkcyjnego oraz zbiór wszystkich wdrażanych artefaktów. Był to rodzaj instrukcji dla administratora, który fizycznie zrealizuje takie wdrożenie. Jeśli jakiś zespół w ramach wdrożenia wprowadzał zmiany w swoim obszarze, musiał zadbać też o aktualizację RFC. Było to głównie zadanie managera wdrożenia ze strony programistów. Nie była to rola stała tylko dedykowana dla wdrożenia i w różnych wdrożeniach managerowie się zmieniali. Kierownicy i liderzy poszczególnych działów przydzielali projekty do implementacji dla deweloperów oraz do testowania dla testerów. Na tym etapie specyfikacje od analityków najczęściej były już gotowe lub na ukończeniu. Kilkanaście lat temu Scrum nie był jeszcze tak popularny więc korzystaliśmy z metodyki Waterfall. W uproszczeniu najpierw wytwarzano oprogramowanie a dopiero po nim rozpoczynano testy. Obecnie taki model ma wielu przeciwników, krytykujących długie oczekiwanie na release od momentu zdefiniowania potrzeby. Jednak wiele lat temu to podejście sprawdzało się z powodzeniem, zwłaszcza w tak formalnej organizacji, jaką jest bank. W czasie oczekiwania na implementację, testerzy zapoznawali się ze specyfikacjami, na ich podstawie tworzyli plany testów i zgłaszali ewentualne błędy, dotyczące dokumentacji w systemie do śledzenie błędów (JIRA). 

Testerzy mieli również swojego managera testów wdrożenia. Analogicznie jak u programistów, funkcję tę obejmowały osoby z większym stażem pracy, mogły też zmieniać się co wdrożenie. Mi samej przyszło pełnić taką funkcję po zdobyciu większego doświadczenia. Zadanie to było ciekawe ale niełatwe. W pierwszej kolejności trzeba było utworzyć kopię RFC wdrożeniowego, ale przerobić ją tak, aby była dostosowana do środowiska testowego. Tutaj muszę wspomnieć, że mieliśmy do swojej dyspozycji kilka środowisk testowych. W większości jednoserwerowych, które były używane dla testów funkcjonalnych. Do testów UAT korzystaliśmy ze środowiska wieloserwerowego zbliżonego do systemu produkcyjnego. To manager testów przygotowywał środowisko do testów, wprowadzał zmiany zgodnie z RFC dla środowiska testowego – tutaj mógł się posiłkować wiedzą z poprzednich wdrożeń oraz wsparciem osób, które to już przeprowadzały, a także programistów czy zespołu R&D (Research and Development, czyli upraszczając architektów systemowych). Przykładem takich zmian były odpowiednie wpisy w plikach konfiguracyjnych czy wykonanie skryptów na bazach danych (po uprzednim ich scaleniu wewnętrznym narzędziem). Do jego zadań należało też codzienne utrzymywanie środowiska (restarty, upload zmian).

Z biegiem czasu architektura systemu przeszła rewolucję i dotychczasowe rozwiązania, wymagające osobnego serwera aplikacji, zastąpiono mikroserwisami. Po wydzieleniu części funkcjonalności z dużej aplikacji do mikroserwisów cały proces continuous integration stał się prostszy. Nie trzeba było już robić restartów całej aplikacji aby zretestować błąd, co w sytuacji, gdy wiele osób pracuje na tym samym środowisku, jest dość uciążliwe.

Niektórzy mogą uważać, że w bankach przeważają stare technologie. Pewnie zależy to od podejścia danego banku, ale moje doświadczenie pokazuje, że wcale tak być nie musi. Owszem, zdarza się natknąć na stare, licencjonowane systemy księgowe, które banki zakupiły, ale tam nic się nie zmienia, a jedynie weryfikuje np. księgowanie transakcji. Tester pracujący w banku najpewniej spotka się z bardzo zróżnicowani systemami i technologiami.

Przygotowanie przypadków testowych nie takie oczywiste. Przykłady testów funkcjonalnych

Załóżmy, że mamy już przydzielony projekt do testów w ramach wdrożenia. Zrobiliśmy plany testów i wrzuciliśmy je do systemu kontroli wersji. Środowisko testowe działa. Co dalej?

Skąd brać dane do logowania podczas testów dla banku?

Pierwszy projekt, który przyszło mi testować dotyczył systemu bankowości internetowej. Do sprawdzenia była pewna zmiana w menu. Żeby przeprowadzić testy potrzebowałam danych do logowania W banku dane klientów są szyfrowane, na środowisku testowym nie zalogujemy się na rzeczywiste dane, nawet gdybyśmy chcieli wykorzystać w tym celu własne konto. Przypadek należało odpowiednio przygotować. Jak radzić sobie w takich sytuacjach?

Jeśli weryfikujemy zmiany związane z wyświetlaniem elementów na stronie, dla których nie są zadane żadne warunki co do klienta, możemy stworzyć sobie nowego klienta testowego, czyli najpierw wprowadzić dane klienta w systemie centralnym (dowolne dane, ale poprawnie walidowane przez system) a następnie produkt i umowę umożliwiającą dostęp do e-bankowości wraz z wydaniem dostępów w backoffice. Jeśli potrzebowalibyśmy klienta ze środkami na koncie, bo sprawdzamy dajmy na to realizację przelewów, możemy sobie w systemie księgowym zasilić jego konto, a po poprawnej synchronizacji podczas logowania zobaczymy w bankowości tą kwotę.

Sytuacja komplikuje się, gdy potrzebujemy przypadek klienta na przykład z kredytem. Wtedy sięgamy do bazy danych i wyszukujemy taki przypadek. Tutaj potrzebna jest znajomość SQL i umiejętność tworzenia złożonych zapytań ale przede wszystkim zapoznanie się ze strukturą baz danych (w jakiej tabeli i bazie szukać interesujących nas danych). Danych logowania oczywiście nie dostaniemy z bazy (dane szyfrowane i inna autentykacja niż na produkcji), ale wystarczy kilka trików z wydaniem nowego hasła tymczasowego i już jesteśmy u celu. Jak widać, nawet prosty test często wymaga długiego przygotowania przypadku i przeklikania się przez inne systemy. Nieco prostsza była praca z systemem centralnym, gdyż na testach logowaliśmy się na specjalne konta doradców i użytkowników back office, którzy posiadali odpowiednie role do wykonywania określonych czynności w systemie. Później wystarczyło wyszukać odpowiedniego klienta.

Testowanie przelewów ekspresowych

Inny przykład, też związany z obszarem bankowości internetowej dotyczy przelewów ekspresowych, czyli takich, gdzie środki trafiają na konto odbiorcy niemal natychmiast. Tutaj współpracowaliśmy ze znanym dostawcą tej usługi, który realizował przelew w imieniu banku na konto odbiorcy. System komunikował się poprzez API (Application Programming Interface) z pośrednikiem, a tamten na podstawie informacji od odbiorcy (także przekazywanej poprzez API) pozwalał na transfer lub zwracał informację, że jest to niemożliwe. Z rzeczywistego API korzystało się dopiero podczas testów akceptacyjnych na środowisku UAT, natomiast podczas testów funkcjonalnych używaliśmy często zaślepki (tzw. mocka) symulującej odpowiedź na zadane warunki. Chodziło o to, żeby wstępnie zwalidować możliwe odpowiedzi tak, aby system banku poprawnie je zinterpretował.

Testy generowania oferty kredytowej

Podobnie było podczas testów generowania oferty kredytowej (w systemie centralnym). Nasz system komunikował się z różnymi bazami klientów (np bazą dokumentów zastrzeżonych, czarną listą klientów czy biurem informacji kredytowej). W przypadku tej ostatniej do właściwej komunikacji dochodziło na poziomie testów UAT – wcześniej korzystaliśmy z symulacji odpowiedzi tego serwisu, gdyż komunikacja rzeczywista była kosztowna i zbędna przy testach funkcjonalnych. Na środowisku UAT dochodziło czasem do śmiesznych sytuacji, gdyż BIK oczywiście nie udostępnia realnych danych podczas komunikacji z systemami testowymi, ale wystawia klientów testowych, którzy nie mogli być zwalidowani przez system bankowy ze względu na wiek.

Testy bankowości mobilnej

Ostatni przykład, który chciałabym przytoczyć, dotyczy testów bankowości mobilnej. Testy mogłam przeprowadzać jedynie na urządzeniach bankowych, które miały wskazaną sieć banku jako punkt dostępowy. Rodziło to pewne ograniczenia, które zapewne nie istnieją w innych instytucjach. Kontrola dostępów jest jednak kwestią nieodzowną w banku.

Czasem testy dodatkowo komplikował fakt rozjazdu danych między bazami spiętymi ze środowiskiem testowym. Tutaj muszę wyjaśnić, że produkcyjne bazy danych były cyklicznie kopiowane i szyfrowane po to, by móc wykorzystać je w środowisku testowym. Czas kopiowania dla różnych baz był inny, przez co jedna baza podłączona do środowiska mogła być starsza niż druga co skutkowało tym, że klient w jednej bazie występował, a w drugiej nie. Wtedy należało szukać  innego przypadku do testów.

Przy niektórych testach istniała potrzeba zamknięcia dnia lub nawet kilku dni w systemie księgowym, na przykład, gdy trzeba było sprawdzić naliczenie odsetek. Tester musiał wcześniej przewidzieć taką sytuację i ją zgłosić, aby zespół od systemu księgowego mógł zaplanować zamknięcie dnia nie kolidując przy tym z pracą innych testerów.

Reasumując, tester pracujący w banku musi uzbroić się w podwójną cierpliwość, gdyż często znalezienie lub przygotowanie odpowiedniego przypadku testowego trwa dłużej niż same testy funkcjonalne. Wynika to z mnogości systemów, czasem rozbieżności danych w bazach testowych i szyfrowania tych danych.

User Acceptance Tests

Nieodłącznym elementem procesu wytwarzania oprogramowania w bankach są testy regresji oraz testy akceptacyjne (User Acceptance Tests). Przeprowadza się je na środowisku UAT, które swoją architekturą odzwierciedla system produkcyjny banku. PM Managerowie, osoby odpowiedzialne za procesy biznesowe, mogą wówczas sami ocenić czy system działa zgodnie z ich oczekiwaniami. Testerzy dostarczają im odpowiednie przypadki testowe umożliwiające tę weryfikację oraz sami przeprowadzają testy regresji w oparciu o plany testów dla każdego systemu. W mojej pracy część testów regresji była zautomatyzowana i testerzy automatyzujący uruchamiali swoje skrypty.

Jeżeli testy UAT i regresji nie wykazywały nieprawidłowości, zapadała decyzja o realizacji wdrożenia (tzw. decyzja GO/NOT GO na szczeblu dyrektorskim). Osobiście pamiętam tylko decyzje GO, z ewentualnym opóźnieniem terminu wydania. Wdrożenie było realizowane przez administratorów (z innego departamentu) w godzinach nocnych, gdyż system banku był wówczas niedostępny dla klientów, o czym informowano w serwisie internetowym. Jeśli podczas wykonywania kolejnych kroków zgodnie z RFC administrator spotkał się z niejasną instrukcją lub coś poszło nie tak, manager wdrożenia programistów mógł spodziewać się nocnego telefonu:) Takie sytuacje należały jednak do rzadkości, gdyż administrator najcześciej przeprowadzał wcześniej próbne wdrożenie na środowisku UAT.

Testy powdrożeniowe

Po udanym wdrożeniu i uruchomieniu systemów produkcyjnych, wcześnie rano jeden lub dwóch testerów weryfikowało na produkcyjnym systemie krytyczne ścieżki w systemie centralnym oraz systemie bankowości internetowej. Na ten jeden dzień wydawano im dostępy do centralnego systemu produkcyjnego, dzięki czemu mogli się w nim uwierzytelnić, udzielić kredytu specjalnemu klientowi, czy też założyć konto. W bankowości internetowej przechodzili przez kluczowe funkcjonalności, a weryfikację mogli przeprowadzić na swoich danych, jeśli posiadali dostęp do e-bankowości.

Obsługa błędów produkcyjnych

Jedno ze środowisk testowych (zwane hotfix) było dedykowane do weryfikacji błędów zgłaszanych na produkcji przez doradców i klientów bankowości elektronicznej. Zgłoszenia takie napływały do działu odpowiedzialnego za utrzymanie systemów a następnie były przekazywane w formie zgłoszeń w JIRA do Działu Testów. Bazy danych podpięte do hotfixa były codziennie odświeżane i miały zgodną datę, aby testerzy mogli łatwo zreprodukować przypadek. W naszym dziale mieliśmy podział na zespoły specjalizujące się w danym systemie czy komponencie po to, aby zapewnić jak najszybszą i najbardziej rzetelną obsługę zgłoszenia. Część zgłoszeń była nieprawidłowa, inne wystarczyło wyjaśnić w komentarzu, aby osoba kontaktująca się z autorem zgłoszenia przekazała odpowiedni feedback. Zdarzały się też zasadne, które wymagały szybkiej ingerencji programisty i łatki z poprawką.

Bez wątpienia będąc testerem w banku nie można się nudzić, a zadania, jak widać, są bardzo zróżnicowane i ciekawe. Duży nacisk jest kładziony na dotrzymanie terminów wdrożeń. Zmiany wprowadzane w systemach mają na celu nie tylko rozszerzenie oferty bankowej, wprowadzenie nowych usprawnień technologicznych  czy zwiększenie zysków. Często testowane zmiany wynikają z narzuconych przez KNF (Komisję Nadzoru Finansowego) regulacji prawnych lub na przykład unijnej dyrektywy PSD2 (ang. Payment Services Directive).

Bank jako instytucja podlegająca kontroli Komisji Nadzoru Finansowego

Trzeba być świadomym tego, że banki to instytucje podlegające Komisji Nadzoru Finansowego. KNF może narzucać instytucjom podległym zmiany w zapisach umów, które wpływają na sposób liczenia zdolności kredytowej, czy dotyczą zbierania informacji o eksponowanych stanowiskach. Określony zostaje wtedy termin wprowadzenia tych modyfikacji. W takiej sytuacji realizowane przez testerów projekty będą czysto regulacyjne i może mniej ciekawe, jeśli przyjdzie im zweryfikować kilkanaście wydruków.

Banki muszą w ogromnym stopniu dbać o bezpieczeństwo danych klientów i każdy pracownik, także tester, musi mieć to na uwadze. Na specjalnych szkoleniach udostępnianych na platformie wewnętrznej, dowiaduje się jak chronić dane przed przedostaniem się w niepowołane ręce i jak nie paść ofiarą phishingu (technika wyłudzenia danych), zobligowany jest też do nieujawniania technologii i zachowania tajemnicy bankowej.

Praca zdalna w banku?

Czas pandemii zweryfikował nieco możliwość pracy zdalnej dla sektora IT w banku. Na bazie mojego doświadczenia stwierdzam, że wcześniej faktycznie nie było to takie oczywiste. Departament Bezpieczeństwa blokował możliwość logowania do systemów testowych z zewnętrznych sieci. Wynikało to nie tyle z braku technicznych możliwości a z przekonania, że lepiej jest pracować w sieci wewnętrznej. Gdy pojawiła się, że obawa, że ewentualna kwarantanna zatrzyma pracowników w domach i nie będzie komu pracować, zdalne testowanie stało się możliwe. Podejrzewam, że managerowie także innych firm IT przekonali się, że praca zdalna może być równie efektywna jak praca z biura.

Podsumowując

Praca w dziale testów w banku umożliwiła mi poznanie i testowanie wielu systemów oraz wzięcie udziału w ciekawych projektach. To bardzo cenne doświadczenie. Uważam, że największą zaletą pracy testera w banku jest różnorodność zadań oraz potrzeba prześledzenia kilku systemów i baz danych w celu przygotowania przypadków testowych. Powinno to sprawiać satysfakcję osobom mającym w sobie nutkę  detektywa. Warto jednak pamiętać o dużej odpowiedzialności i wiążących deadline’ach, które są nieodłączną częścią tej pracy.

Karolina Błaszczak

Testerka z kilkunastoletnim stażem w sektorze bankowym specjalizująca się w testach funkcjonalnych. Prywatnie miłośniczka dobrej kuchni i pasjonatka pięknych wnętrz. W wolnych chwilach aranżuje przestrzenie i planuje remonty.