Automatyczne testy regresji – rozwiązanie „szyte na miarę” – cz. 2 – przegląd rozwiązań

3.07.2024 |  Paweł Krakowczyk

Z artykułu dowiesz się

• Jakie rozwiązania rozważaliśmy z dostawcą
• Jakie były zalety i wady wszystkich czterech wariantów
• Na które rozwiązanie się zdecydowaliśmy i dlaczego

Projekt Bazylea IV wiązał się z wprowadzeniem zmian w raportowaniu danych przez bank. Wraz z dostawcą stanęliśmy przed wyzwaniem wyboru odpowiedniego rozwiązania, które miało spełnić nasze oczekiwania i zminimalizować ryzyko.

Odpowiedź na kryzys lat 2007-2009 – perspektywa biznesowa

„W latach 2006 i 2007 Lehman Brothers (4 największy bank w USA istniejący na rynku od ponad 150 lat) notuje rekordowe poziomy zysków. Pomimo znakomitych wyników finansowych już w 2007 roku pojawiają się informacje na temat zagrożeń spowodowanych kryzysem na rynku kredytów hipotecznych tzw. kryzysu subprime. 

Q1 2008 to pierwszy kwartał w historii banku zakończony stratą. Wszelkie próby ratowania banku (dokapitalizowanie banku – brak efektu, poszukiwanie kapitału na rynkach – brak zaufania) zakończyły się niepowodzeniem i 15 września 2008 roku ogłoszono bankructwo 158 letniego Banku Lehman Brothers. 

Wystarczyło kilka godzin, by świat przekonał się, że nie ma takiego banku, który byłby za duży, by upaść. W chwili bankructwa bank zarządzał 600 miliardami dolarów. 

Kryzys finansowy rozlał się na cały świat, nie oszczędzając nikogo. W trakcie kryzysu wiele instytucji finansowych pomimo utrzymania odpowiednich poziomów kapitałowych doświadczyło poważnych problemów z płynnością.

Na poziomie międzynarodowym problematyka płynności banków nie była dotychczas obszarem regulowanym. Ostatni kryzys pokazał wyraźnie, że płynność jest bardzo niedocenianym aspektem bezpieczeństwa finansowego banków, wymagającym pilnych regulacji. Polska była o krok do przodu, ponieważ w polskim systemie bankowym zaimplementowano już wcześniej instrumenty monitorujące płynność poszczególnych instytucji, a nowe decyzje Komitetu Bazylejskiego jedynie modyfikują istniejące miary.”

Żródło: Prezentacja w ramach śniadania ze studentami – Pion Finansów Banku Śląskiego S.A.

Odpowiedź na kryzys lat 2007-2009 – perspektywa techniczna

„Zespół biznesowy Banku w ramach wdrażania nowego NSFR3 potrzebuje mieć możliwość przeprowadzania testów autowypełniania raportów w oparciu o realistyczne i porównywalne dane względem dotychczasowego produkcyjnego NSFR2.9.

Niestety Bank nie ma możliwości dostępu do takich danych w środowiskach testowych/UAT, ponieważ maskowanie niektórych danych zmienia wynik autowypełniania raportów, właściciel danych nie wyraził zgody na ich odmaskowanie.

NSFR EBA 3.0 będzie obowiązywał od 2021-06, we wcześniejszych okresach będzie nadal sprawozdawany NSFR EBA 2.9.

System (…) umożliwia wersjonowanie szablonów raportów okresami sprawozdawczymi - dzięki czemu możliwa jest implementacja zmian wprowadzanych przez regulatora z jednoczesnym zachowaniem możliwości sprawozdawania dotychczasowej wersji wg dotychczasowych wymogów.

Bardzo istotnym celem jest minimalizacja wpływu prac i testowania NSFR3 na funkcjonowanie dotychczasowych wersji sprawozdawczości LCR i NSFR2.9, w szczególności ograniczenie potrzeby zaangażowania w testy regresyjne zespołu biznesowego.

W ramach projektu NSFR3 po stronie Banku planowane jest generowanie osobnego zestawu danych wejściowych dla NSFR3. Wiąże się to z potrzebą zapewnienia minimalizacji wpływu rozbudowy Bankowego generatora ekstraktów wejściowych na generację danych dla dotychczasowych wersji NSFR2.9 i LCR.”

Źródło: Draftu dokumentu od dostawcy oprogramowania z wypracowanymi 4 wariantami realizacji projektu NSFR3 z dnia 2020-09-28

Powrót do przeszłości, czyli rozwiązania zaproponowane przez dostawcę¹

Po wielu spotkaniach i dyskusjach z dostawcą oraz po analizie możliwości realizacji w realiach bankowych procedur, ostatecznie dostawca przedstawił cztery warianty realizacji projektu NSFR3:

1. Wariant OFFSET: przetransformowanie dat danych na nowy okres (rekomendowany)
2. Wariant RAPORTY-BIS: dodatkowe raporty NSFR3 w bieżącym okresie sprawozdawczym
3. Wariant APLIKACJA-BIS: instalacja w środowisku produkcyjnym drugiej aplikacji
4. Wariant SPRAWOZDAWCZOŚĆ-BIS: dodanie do systemu drugiego rodzaju sprawozdawczości.

Wariant RAPORTY-BIS

Wariant RAPORTY-BIS zakłada w ramach już istniejącego, produkcyjnego JAR-a raportowego, w dotychczasowym okresie sprawozdawczym dodanie nowych wersji raportów NSFR3 pod nowymi nazwami, np. NSFR_PZSF → NSFR3_PZSF. Takie rozwiązanie umożliwia testowanie NSFR3 na danych produkcyjnych, wygenerowanych w bieżącym okresie sprawozdawczym. Na koniec realizacji projektu nazwy raportów zmieniają się do standardowych wersji (NSFR3_PZSF → NSFR_PZSF) w okresie obowiązywania NSFR3. Analogiczny wariant był stosowany podczas wdrażania zmian w związku z wdrożeniem EBA 2.9.

Zaleta:

• niska pracochłonność i koszt realizacji po stronie dostawcy

Wady:

• zmiany NSFR3 dostarczane są wspólnym JAR-em produkcyjnym (ale można wykorzystać kontrole zabezpieczające przed regresją (przyp. red. tutaj również mowa o wykorzystaniu testów regresji)
• zmiany w nazewnictwie raportów dotyczą też nowych formuł arytmetycznych i weryfikacyjnych oraz generacji XBRL². Jednak jest to proste do przetestowania – dostawca może przetestować zgodność XBRL dla wszystkich komórek raportowych
• ekstrakty dla dotychczasowego NSFR2.9/LCR i NSFR3 będą występowały w tym samym okresie (niewielkie ryzyko pomylenia ekstraktów - tj. potraktowania danych NSFR3 jako dane produkcyjne).

Wariant APLIKACJA-BIS

Rozwiązanie w wariancie APLIKACJA-BIS polega na wdrożeniu drugiej instalacji serwera aplikacji na środowisku produkcyjnym. Dzięki temu można zastosować autowypełnianie w oparciu o dane produkcyjne. Dla pełniejszej separacji zakładamy również kolejny schemat bazodanowy. Użytkownik pod jednym adresem WWW ma wtedy dostęp do obecnej produkcyjnej wersji systemu, a pod drugim do wersji z NFSR3. Zmiany dotyczące NSFR3 są dostarczane osobną wersją JAR-a raportowego, w którym raporty dla bieżącego okresu NSFR są już w wersji NSFR3.

Zalety:

• pełna separacja zmian w ramach NSFR3 względem obecnej wersji systemu
• zmiany dot. NSFR3 dostarczane osobnym JAR-em raportowym na osobne środowisko
• średnia pracochłonność (wykreowanie drugiej instancji JBOSS, testowa instalacja u dostawcy przed dostawą)
• brak możliwości wprowadzenia błędów dla dotychczasowego NSFR2.9/LCR (zarówno na poziomie raportów jak i samego systemu)
• wprowadzanie zmian systemowych w ramach NSFR3 bez wpływu na dotychczasowy system.

Wady:

• większa konsumpcja pamięci RAM przez 2 instancje JBOSS na jednym serwerze
• weryfikacja procedur po stronie banku, czy możliwa jest instalacja drugiej instancji systemu w środowisku produkcyjnym (uwaga red. jest możliwa)
• utrzymywanie zgodności kodu pomiędzy modułami w trakcie projektu
• wymaga drugiego schematu bazodanowego.

Wariant SPRAWOZDAWCZOŚĆ-BIS

Wariant SPRAWOZDAWCZOŚĆ-BIS zakłada dodanie do dystrybucji systemu dodatkowego modułu (traktowanego jako zupełnie osobny rodzaj sprawozdawczości). Użytkownik z poziomu systemu może (za pomocą standardowej funkcjonalności przełączania okresów sprawozdawczych) przełączać się pomiędzy sprawozdawczościami. Dostawca dostarcza osobny JAR raportowy dla obu sprawozdawczości. Dane w wersji NSFR3 są wtedy importowane i przetwarzane w nowym module. W celu ograniczenia pracochłonności automat testujący nie funkcjonuje dla nowego modułu. Po zakończeniu/akceptacji projektu NSFR3 zmiany realizowane w ramach nowego modułu są zaaplikowane na standardowy moduł aplikacji.

Zalety:

• zmiany dot. NSFR3 dostarczane osobnym JAR-em raportowym
• brak możliwości wprowadzenia błędów dla dotychczasowego NSFR/LCR na poziomie JAR-a raportowego
• większość modyfikacji dot. NSFR3 można wykonać przez zmiany tylko do nowego modułu
• brak potrzeby zakładania nowego schematu bazodanowego (separacja następuje automatycznie ze względu na inny rodzaj sprawozdawczości).

Wady:

• największa ze wszystkich wariantów pracochłonność/koszt realizacji po stronie dostawcy, związany z:
  • zduplikowaniem kodu modułu – połączone ze zamianą powiązań w kodzie, tak by funkcjonowały oba moduły w obrębie tego samego systemu
  • dodaniem nowego rodzaju sprawozdawczości
  • szerszym testowaniem po stronie dostawcy, ze względu na możliwość w duplikacji modułu
  • dodaniem mechanizmu budowania i dystrybucji nowego modułu i budowania osobnego JAR-a raportowego
  • utrzymywaniem zgodności kodu pomiędzy modułami w trakcie projektu
  • aplikacją zwrotną zmian z nowego do standardowego modułu na koniec projektu i ponownymi testami zgodności 
• utrudnienia po stronie dostawcy przy pracy nad NSFR3 dla pozostałych banków (zazwyczaj po prostu mają dostęp do realistycznych danych w środowisku UAT – przyp. red. w naszym banku ze względu bardzo restrykcyjne polityki bezpieczeństwa dane na środowisku testowym muszą być zamaskowane, co jednak w niektórych przypadkach komplikuje testowanie aplikacji).

Komentarz dostawcy dotyczący „kontroli regresji Bankowego generatora ekstraktów wejściowych”³:

„Poza potrzebą zachowania niezmienności szablonów raportów NSFR2.9/LCR istotne jest zachowanie stabilności generacji danych wejściowych dla dotychczasowych wersji NSFR2.9/LCR. Przy czym co jakiś czas mogą być potrzebne zmiany typu poprawki/udoskonalenia generacji obecnych danych produkcyjnych co należy uwzględnić tak by ich weryfikacja nie angażowała nadmiernie zespołu biznesowego.

Wskazane jest odseparowanie kodu generatora ekstraktów wejściowych dla NSFR2.9/LCR od generatora NSFR3, tak by zmiany dot. NSFR3 nie miały żadnego wpływu na generację NSFR2.9/LCR.

Do rozważenia po stronie Banku jest też wprowadzenie mechanizmów porównujących i raportujących różnice w ekstraktach wygenerowanych różnymi wersjami generatora na tych samych danych z hurtowni.”

Odpowiedź banku na propozycje dostawcy

Rozwiązanie problemów od strony hurtowni danych i przygotowania ekstraktów z danymi źródłowymi aplikacji nie wydawało się skomplikowane. Intensywne zmiany związane z rozwojem aplikacji w tej części są jednak również istotne biznesowo.

Tak naprawdę do wyboru pozostały dwie opcje:

• Nowy mechanizm tworzenia ekstraktów - utworzenie wiernej kopii, aby to na niej wprowadzać zmiany związane do NSFR3 (red. rozwiązanie bardzo rekomendowane wówczas przez biznes)
• Brak nowego mechanizmu tworzenia ekstraktów – dodanie do istniejącego procesu dwóch kolejnych typów ekstraktów: LCR3 oraz NSFR3, czyli z 2in1 powstałoby 4in1 (red. cztery typy ekstraktów w jednym procesie).

Pierwsze rozwiązanie rekomendował zespół biznesowy, ze względu na całkowitą separację testowego środowiska projektowego NSFR3 oraz obecnego produkcyjnego. Prawdopodobnie byłaby to jedyna zaleta tego rozwiązania.

Zaleta:

• separacja środowisk projektowego NSFR3 oraz produkcyjnego.

Wady:

• konieczność powoływania:
• nowego pakietu sterującego
• nowych struktur bazodanowych, odpowiedzialnych za przechowywanie informacji o zadaniach i ich wzajemnych relacjach
• nowych struktur tabel i widoków wykorzystywanych w zadaniach
• powyższe może być realizowane na 2 sposoby: w ramach nowego, specjalnego schematu bazodanowego lub w ramach istniejącego schematu bazodanowego
• w przypadku nowych struktur tabel i widoków tworzonych na tym samym schemacie bazodanowym – nowe nazwy, a co za tym idzie konieczność ich uwzględnienia we wszystkich dotychczasowych zadaniach skopiowanych na potrzeby projektu NSFR3
• w przypadku powołania nowego schematu bazodanowego – konieczność spełnienia procedur bankowych (powołanie nowego użytkownika na bazie danych, wybór opiekuna użytkownika, dodanie do Vault, spełnienie wszystkich polityk związanych z utrzymywaniem dodatkowego konta w bazie danych, np. okresowa zmiana hasła, jeżeli biznes za wymaganie stawia, możliwość testowania bieżących zmian na produkcji – dochodzą dodatkowo kolejne procedury produkcyjne – rozbudowa SIEM, MRA, uwzględnienie procedur RMM)
• powtarzanie kodu źródłowego - w przypadku błędów produkcyjnych konieczność wprowadzania poprawek w dwóch miejscach
• w przypadku pełnej separacji powołanie nowych lokalizacji, zarówno po stronie miejsca zapisu ekstraktów na Hurtowni danych, jak również po stronie aplikacji
• powołanie nowych definicji transferów wewnątrz banku
• scalenie rozwiązania – lub zastąpienie nowego mechanizmu starym, co jest problematyczne: projekt zakłada modyfikację NSFR, a nie LCR – wprowadzając zmiany projektowe NSFR3 i tak musimy uważać, żeby nie zmienić nic w obecnym LCR – który i tak jest powiązany jednym mechanizmem.

Drugie rozwiązanie wzbudzało najwięcej kontrowersji po stronie biznesowej. Prowadzenie projektu na obecnym produkcyjnym środowisku to konieczność wgrywania wszystkich zmian na produkcję. Wtedy też trzeba mieć pewność, że zmiany w projekcie NSFR3 nie mają negatywnego wpływu na bieżące raportowanie.
Zalety:

• utrzymanie kodu źródłowego w jednym miejscu dla wszystkich obecnych oraz przyszłych typów ekstraktów
• płynne przejście z aktualnej wersji NSFR2.9 do NSFR3
• uzgodniona z analizą separacja wersji na poziomie ewentualnych nowych widoków/tabel w przypadku istotnych zmian.

Wada:

• wspólny mechanizm generacji ekstraktów na etapie wdrażania kolejnych zmian w projekcie NSFR3 może powodować błędy w obecnych ekstraktach produkcyjnych.

Po tej analizie pojawiło się tytułowe rozwiązanie, które spełniło oczekiwania dostawcy i banku – testy regresji. Testy pozwalały wykluczyć zmiany w niespodziewanych miejscach, zarówno po stronie projektu NSFR3, jak również podczas wprowadzania zmian na środowisku produkcyjnym. Rozwiązanie powinno zapewnić szczegółowy obraz sytuacji, na które obszary każda zmiana ma wpływ.

Wybór należy do biznesu

Ostatecznie w banku wybraliśmy wariant pierwszy (OFFSET) z wykorzystaniem testów regresji.

Tak brzmiała odpowiedź zespołu biznesowego, która stała się wiążącą decyzją w tej sprawie:

„Z zaproponowanych przez dostawcę sposobów wdrożenia NSFR3, zgodnie z rekomendacją IT wybieramy Wariant 1 'OFFSET': Przetransformowanie dat danych na nowy okres (wstępna pracochłonność min. 6 dni).
Warunkiem realizacji testów nowego NSFR przy wykorzystaniu tego wariantu, są testy potwierdzające brak wpływu zmiany daty na dane prezentowane w raportach (porównanie raportów wygenerowanych na UAT na bieżącej dacie z raportami wygenerowanymi po zmianie dat). W związku z koniecznością realizacji testów, będzie wymagane możliwie najszybsze dostarczenie omawianego mechanizmu w aplikacji przez dostawcę.
W przypadku negatywnego wyniku testu będziemy rozważali Wariant 2 'RAPORTY-BIS': Dodatkowe raporty NSFR3 w bieżącym okresie sprawozdawczym (wstępna pracochłonność min. 4 dni).”

Podsumowanie

W tej części pokazaliśmy skalę problemu, z którym się zmierzyliśmy. Było to konieczne, aby lepiej zrozumieć mechanizm generacji ekstraktów, dla którego wprowadziliśmy w banku autorskie rozwiązanie. Warto podkreślić też bliską współpracę kilku zespołów, zarówno w banku, jak również po stronie dostawcy. To dzięki doświadczeniu oraz długiej współpracy mogliśmy sprawnie przeprowadzić wdrożenie tak trudnego przedsięwzięcia.

W kolejnej części

Po wyborze konkretnego rozwiązania pokażemy proces implementacji oraz wdrożenie rozwiązania w banku. Przedstawimy także działanie mechanizmu automatycznych testów regresji ekstraktów generowanych w Hurtowni danych.

---

^1,3 Draft dokumentu od dostawcy oprogramowania z wypracowanymi 4 wariantami realizacji projektu NSFR3 z dnia 2020-09-28.

² XBRL – znakowanie informacji, które umożliwia ich identyfikację i opis w ramach sprawozdania finansowego danej jednostki.