Testy aplikacji bankowych: know-how is king!

Testować każdy może? Otóż nie. Sprawdzanie poprawności działania aplikacji bankowych nie wymaga jedynie armii testerów, a przede wszystkim zespołu analityków z dogłębną wiedzą dziedzinową.

Podnosząc poziom customer experience i rozszerzając ofertę o nowe usługi, banki stały się obecnie wytwórcami oprogramowania dla wewnętrznego ekosystemu zintegrowanych aplikacji. A ponieważ błędy w systemie bankowym mają ogromne konsekwencje, nie tylko wizerunkowe, ale również prawne, poprzeczka niezawodności rozwiązań IT dla bankowości jest ustawiona niezwykle wysoko.

Outsourcing testów do wyspecjalizowanych partnerów nie jest jeszcze popularny w sektorze bankowym. Głównym hamulcem są oczywiste obawy o bezpieczeństwo, jednak pojawiają się także głosy, że najbardziej palący problem w testowaniu leży głębiej – w braku odpowiedniej kadry testerskiej. A może to także kwestia dobrej organizacji procesu i zrozumienia specyfiki testów w sektorze bankowym?

Arkadiusz Stanimir i Agnieszka Suder, eksperci CCA Europe z wieloletnim doświadczeniem w dziedzinie aplikacji bankowych przybliżają tematykę testów oprogramowania i tłumaczą, dlaczego warto powierzyć to zadanie zewnętrznym specjalistom.

 

Arku, Agnieszko, przedstawcie Wasze role w obszarze testów. Czym się zajmujecie?

Arkadiusz Stanimir: Jestem głównym analitykiem, zajmuję się też superwizją działu testów. W projekcie pełnię zazwyczaj rolę Test Mastera.

Agnieszka Suder: W zależności od metodologii, jaką Klient wybierze do realizacji projektu, pełnię funkcję Project Managera lub Scrum Mastera. Moją rolą jest przede wszystkim planowanie poszczególnych faz projektu, czyli przygotowanie scenariuszy testowych, przeprowadzenie testów czy wsparcie powdrożeniowe zgodnie z harmonogramem Klienta. Dbam również o zachowanie jasnej wizji projektu w zespole, bieżące usuwanie przeszkód i doprowadzenie projektu do finalnej fazy zwieńczonej pozytywną rekomendacją do wdrożenia biznesowego.

Zacznijmy od początku: czym testy aplikacji bankowych różnią się od testów innych rodzajów aplikacji biznesowych?

Agnieszka: W odróżnieniu od “klasycznych” aplikacji, do testowania szeroko rozumianej bankowości potrzebna jest wiedza dziedzinowa, czyli znajomość procesów bankowych: ich przebiegu i wzajemnych zależności. Jest to wręcz niezbędne podczas przygotowywania przypadków testowych, których celem jest kompleksowe ujęcie tematu oraz precyzyjne wskazanie obszaru krytycznej funkcjonalności, którego dosięgnie wprowadzona w ramach realizowanego projektu zmiana.

Arkadiusz: Kluczowym elementem testów aplikacji bankowej jest faza analityczna, podczas której identyfikuje się konkretne problemy, obszary, a następnie określa działania, żeby upewnić się, że aplikacja działa poprawnie. Innymi słowy, bank nie wskazuje z góry, co i jak należy przetestować – przedstawia jedynie dokumentację (funkcjonalną bądź techniczną) dokonanych w systemie zmian. To my, analitycy musimy opracować proces zapewniający maksymalne pokrycie testowe przy jak najmniejszych nakładach, a następnie przeprowadzić odpowiednie działania i przedstawić wyniki oraz rekomendacje.

A co by było, gdyby za projektowanie takiego testu zabrał się zespół bez doświadczenia w bankowości? Gdyby nie zadał odpowiednich pytań?

Agnieszka: Najprościej mówiąc, bez znajomości danego obszaru bankowości cały proces testowania będzie obarczony ogromnym ryzykiem. Chodzi głównie o niekompletność testów, co niestety zostanie szybko i boleśnie zweryfikowane w fazie produkcyjnej. Dogłębna znajomość procesu bankowego i jego powiązań jest konieczna, by móc skrupulatnie przeanalizować zakres zadań i przygotować scenariusze testowe, na podstawie których uda się wykryć wszystkie potencjalne błędy.

Arkadiusz: W bankowości obszar testowy nie jest zdefiniowany aplikacyjnie, tylko procesowo. Procesy występujące w banku nie zachodzą w obrębie jednej aplikacji, a wielu. W architekturze bankowej jest kilkadziesiąt lub nawet kilkaset różnych aplikacji. W fazie analitycznej trzeba ustalić przez jakie elementy architektury przechodzi proces, np. aplikacje czy bazy danych, w jakich kanałach dostępowych się odbywa. Tego się nie da zrobić bez wiedzy i doświadczenia dziedzinowego. Nawet jeśli zmiana w systemie polega na wprowadzeniu nowej aplikacji, obsługującej jakiś konkretny obszar biznesowy, to ta aplikacja zawsze funkcjonuje w kontekście pełnej architektury aplikacji bankowych i ich wzajemnych powiązań w ramach procesów biznesowych.

Czyli w testach dla bankowości nie chodzi o to, żeby “przeklikać” jedną aplikację, tylko o to, żeby zapewnić poprawność działania całego procesu bankowego. Jak do tego podchodzicie? Jaki jest pierwszy krok, gdy przychodzi zapytanie ofertowe?

Agnieszka: Zaczynamy od zapoznania się z otrzymaną dokumentacją, omówienia potencjalnego zakresu i wypunktowania zagadnień wymagających doprecyzowania. Ustalamy m.in. jaki ma być zakres testów oraz jakich aplikacji i baz danych dotyka. Czy są nam znane, czy musimy się z nimi zapoznać Ponieważ to wszystko będzie miało wpływ na czas trwania i wycenę projektu. By wyjaśnić zanotowane zagadnienia kontaktujemy się z właścicielem biznesowym, bo pamiętajmy, że kluczem do sukcesu będzie pełne zrozumienie tematu. W tej sytuacji nie ma miejsca na niedomówienia lub domysły. Ofertę przygotowujemy tylko w oparciu o komplet informacji, gdy jesteśmy pewni, że wyjaśniliśmy wszystkie zidentyfikowane zagadnienia.

Arkadiusz: Integralną częścią fazy projektowania jest omówienie niezbędnych dostępów do aplikacji, narzędzi, baz danych czy serwerów logów. W bankowości dostęp do tych zasobów jest ściśle chroniony i musi być dobrze uzasadniony w dokumentacji. Naszą rolą jest wskazanie klientowi zasobów, do których potrzebujemy dostępu oraz jego zakresu i poziomu, wraz z uzasadnieniem, ponieważ bank jest odpowiedzialny przed swoimi klientami, ale także przed wieloma instytucjami kontrolnymi za zapewnienie bezpieczeństwa dostępu do swoich struktur.

Przetestowanie złożonego procesu bankowego lub całkiem nowej aplikacji we wszystkich kanałach dostępu wiąże się ze sporymi kosztami. Czy jest jakiś sposób optymalizacji kosztów w przypadku, gdy proponowany zakres testów wyjdzie poza określony budżet i założony czas?

Agnieszka: Gdy klient decyduje się zmniejszyć zakres testów, proponujemy najbardziej reprezentatywną próbkę, żeby kompleksowo pokryć najważniejsze funkcjonalności i zmieścić się w harmonogramie i kosztach. Nie możemy się też zgodzić na zbyt ostre cięcia ilościowe i jakościowe, ponieważ częściowe testowanie jest nieraz całkowicie bezzasadne. Podejmując się projektu testowania aplikacji bierzemy odpowiedzialność za jej prawidłowe działanie produkcyjne. Tu znów widać, że w testach dla bankowości liczą się nie tylko umiejętności testerów końcowych, ale również wiedza dziedzinowa analityków. 

Arkadiusz: Jeśli bank ma fundusze na testy tylko części z zaproponowanego zakresu, to tę część należy bardzo precyzyjnie zdefiniować. Nie można wziąć pierwszych z brzegu przypadków, a reszty odrzucić. Należy dokonać wyboru tych najważniejszych, najbardziej reprezentatywnych. Kryteria selekcji mogą opierać się na przykład na analizie statystyk popularności korzystania z konkretnych usług bankowych za pośrednictwem określonych kanałów dostępu – wybierzemy do testów oczywiście te kanały, w których wykonuje się najwięcej operacji danego typu. Dobór kryteriów jest też zależny od samego zakresu funkcjonalnego i specyfiki projektu. To tylko pozornie jest kwestia kosztowa – do optymalizacji trzeba podejść analitycznie, z biznesowego punktu widzenia. 

Załóżmy, że udało się podzielić testy na obszary, zapewnić kompleksowe pokrycie przypadkami testowymi i z powodzeniem przeprowadzić testy. Co dalej?

Agnieszka:  Jeśli fazę testów mamy zakończoną z powodzeniem, to przygotowujemy raport końcowy z pozytywną rekomendacją wdrożeniową.  W takim dokumencie nie ograniczamy się jedynie do szablonowych formułek, ponieważ zależy nam, by jak najdokładniej przekazać zdobytą wiedzę. Podsumowujemy zaistniałe błędy – funkcjonalne lub środowiskowe, zdiagnozowane problemy i decyzje biznesowe, jeśli takie za sobą pociągnęły, ale także wnioski, tzw. lessons learned, które w przyszłości pozwolą na jeszcze efektywniejsze działania. Dodatkowo organizujemy warsztaty, podczas których dzielimy się wiedzą zdobytą podczas projektu, by po jego zakończeniu Klient miał poczucie pełnej kontroli nad realizowanym zakresem.

Arkadiusz: Nie każdy projekt testowy kończy się pełnym sukcesem: czasem część funkcjonalności nie działa, część nie została przetestowana w założonym czasie, ale wiedząc o konsekwencjach i mając nasze rekomendacje bank może zdecydować na własną odpowiedzialność co udostępnić użytkownikom końcowym, a co nie. Oczywiście poprawność działania tzw. krytycznych ścieżek funkcjonalnych powinna zostać potwierdzona, ale procesy pomocnicze lub takie, które można zastąpić innymi – można wdrożyć nawet jeśli ich testów nie zakończono. Jeżeli pozostaną jakieś nieprzetestowane przypadki, przeprowadzamy warsztat podsumowujący z Klientem i udzielamy wskazówek, co należy zrobić w przypadku konkretnych błędów, jakie alternatywne procesy można zastosować, a którą funkcjonalność najbezpieczniej będzie chwilowo wyłączyć do czasu zakończenia testów.

CCA Europe specjalizuje się nie tylko w testach manualnych, ale i automatycznych. Co daje automatyzacja testów i kiedy się ją stosuje?

Agnieszka: Przede wszystkim automatyzacja testów umożliwia wykonanie wielu testów znacznie szybciej, niż gdyby były przeprowadzone manualnie. Oczywiście wiąże się to z pewnymi kosztami wejściowymi, ponieważ przygotowanie skryptów testów automatycznych bywa dość pracochłonne, jednak ich późniejsza reużywalność bardzo szybko rekompensuje poniesiony koszt i wysiłek. Dodatkowo tego typu testy możemy prowadzić bez względu na porę dnia i w znacznym stopniu eliminują czynnik błędu ludzkiego. Jeśli chodzi o zastosowanie, to bazując na powyższych zaletach taka forma testów najkorzystniej sprawdza się podczas działań powtarzalnych, czyli testy regresji, wydajnościowe czy obciążeniowe.

Arkadiusz: Obecnie widać globalny wzrost znaczenia testów regresji w postaci automatycznej, ponieważ architektura IT banków dynamicznie się zmienia i musi podlegać ciągłej walidacji w duchu Continuous Integration. Jeżeli jest szansa, że skrypt będzie wielokrotnie używany, tak jak ma to miejsce w przypadku testów regresji, warto zainwestować czas, żeby potem testować bezkosztowo. Nie bez znaczenia jest również wolumen danych, który może podlegać testom automatycznym, w sposób oczywisty nie do osiągnięcia w przypadku testów manualnych. 

A co w obszarze testów działo się u Was w 2020 roku? 

Agnieszka: Rok 2020 był dla nas pracowity w obszarze testów i wszystko wskazuje na to, że 2021 zaczniemy z równie sporym zaangażowaniem. Jednym z ważniejszych projektów była kolejna już faza rozwoju platformy sprzedażowej SME/AGRO Credit GO!, do której zostaliśmy zaproszeni przez Credit Agricole. Cieszy nas, że Klient widzi w nas partnera podczas prac nad dalszym rozwojem swojego produktu i że oprócz testów funkcjonalnych poszerzamy kompetencje we wspomnianej automatyzacji skryptów. Z dumą mogę przyznać, że choć niemal z dnia na dzień musieliśmy przejść na całkowicie zdalny tryb pracy, odbyło się to bez jakiegokolwiek uszczerbku na realizowanych zadaniach i udowodniło, że bez względu na miejsce pracy, zespół CCA jest tak samo mocno zaangażowany w realizację powierzonych projektów.

Arkadiusz: W ostatnim kwartale zintegrowaliśmy autorską aplikację PATT z jednym z najpopularniejszych rozwiązań do testowania aplikacji webowych, Selenium. Integracja umożliwia nie tylko przyspieszenie pracy testerów, ale także obniżenie kosztów dla firm, a co najważniejsze, z punktu widzenia użytkownika końcowego, szeroką walidację systemu, zapewniającą rzetelne odwzorowanie procesu bankowego. Spodziewamy się wykorzystania jej możliwości w kolejnym roku.

 

Czekamy zatem na wieści o dalszych sukcesach, dziękujemy za rozmowę!