Některá jara trvají i několik let aneb o projektu SPRING

Úvod

Projekt SPRING byl založen na přechodu ze zastaralého typu DWH (Data Warehouse – Datový sklad) na nový, který odpovídal požadavkům Rakouské národní a Evropské banky. Naše role na tomto projektu byla primárně manažerská. Jednalo se o koordinaci týmů jednotlivých systémů, management nasazení a vznikajících defektů.

Náš nástup a působení na projektu probíhalo v letech 2019-2021 (poslední oficiální release projektu byl release 2021_010).

Složení týmu

Na projektu se podílel tým v následnujícím složení:

• Jiří Novák (Team leader, UAT test Manager)
• Jaroslav Novák (Defect Manager, UAT test Manager)
• Klára Siegelová (2020, UAT test manager)
• David Sedláček (2020, help with defect management)
• Katarína Vavreková (Solutions Manager, help with FAT test phase)
• Katarína Szaboová (Defect Manager)

Jak se dožít léta

Spolu se změnou jádra datového skladu bylo také nutné přepojit všechny navazující systémy k novému jádru tak, aby nedocházelo k chybám v kalkulaci dat. Cílem projektu bylo sjednotit data jednotlivých zemí tak, aby bylo možné je procesovat v rámci jednoho centrálního systému.

Projekt byl rozdělen na dvě projektové fáze:

• Phase 0 – mít připravenou „Landing Zone“ (GBL – Group Base Layer) pro data zasílaná jednotlivými zeměmi a jejich následné procesování systémem skrze stávající datový sklad (GDP – Group Data Pool).
• Phase 1 – Přechod na nový datový sklad (GDS – Group Data Store), postupné přepínání navazujících systémů k novému datovému skladu při současné kontrole kvality dat, postupné odpojení od GDP a jeho vyřazení z provozu.

Změny hned od začátku aneb nastav si svůj reporting

Do projektu jsme nastoupili v průběhu Phase 0 a s jejím ukončením se přidali další členové. Ve stejnou dobu, kdy jsme na projekt nastupovali, došlo také k rozhodnutí migrovat stávající systém pro práci s testy a defekty do nového, pod který měla být zastřešena celá skupina. Jedním z našich prvních úkolů tedy bylo nastavit tento systém tak, abychom byli schopni celý proces řídit (hovoříme o desetitisících testů a tisících defektů během jednoho nasazení).

Kvůli velkému množství vstupních dat a velkému množství navazujících systémů, docházelo před každým produkčním nasazením k rozsáhlému testování nových struktur a regresním testům každého systému. To vyžadovalo jak vysoké nasazení jednotlivých týmů, tak přesnou a rychlou koordinaci defektů a plánu procesování dat jednotlivých zemí celým systémem.

Systémy, překážky a zádrhely s testovacím pluginem

K monitorování defektů byl použit systém Atlassian JIRA s pluginem TM4J (Test Management for JIRA) pro management testovacích scénářů, cyklů a exekucí. Tato volba nemohla být z naší strany ovlivněna, pracovali jsme tedy s tím, co jsme měli.

Pro rozdělení testů a cyklů byla v systému adresářová struktura, do které jsme testy dělili podle jednotlivých systémů. Každý koncový systém měl tedy vlastní testovací cyklus pro FAT a UAT testování. Pro účely reportingu bylo následně možné všechny cykly spojit do jednoho testovacího plánu pro daný release:

V testovacím pluginu ale chyběla celá řada funkčností, které jsme se snažili marně vykomunikovat s jeho dodavatelem. Mezi jednu z nejdůležitejších patřila nemožnost vyhledávat defekty podle cyklu, ve kterém byly založeny. Podařilo se nám ale objevit workaround v podobě statického reportu, který umožnil extrahovat defekty v podobě .csv a následně je použít pro vyhledání v JIRA instanci. S externím dodavatelem jsme také vyjednali přípravu programu, díky kterému bylo možné editovat větší množství již nahraných testovacích scénářů najednou, což velmi usnadnilo práci.

Vzhledem k tomu, že testování se účastnila jak strana IT, tak strana business uživatelů, rozhodli jsme se pro co nejjednodušší přístup pro obě strany v rámci exekuce testů i zadávání defektů. Komunikace mezi základní instancí JIRA a pluginem pro monitoring testů nebyla v ideálním stavu (Defekty bylo nutné zadávat specifickým způsobem tak, aby došlo ke správnému propojení s testovaným scénářem a originálním požadavkem ze kterého scénář vycházel). Museli jsme proto všechny uživatele systému na používání vyškolit, abychom v co největší míře předešli špatnému zadávání defektů, a usnadnili tak celkový management.

Práce s defekty

Kvůli tomu, že se projektu účastnilo několik systémů, bylo nutné při zakládání defektů vyplnit několik polí, které nám pomohly s následným tříděním a organizací (jak je zmíněno výše, vyhledávat defekty pouze podle cyklu nebylo jednoduše možné). Pro tento účel jsme v defektech zavedli několik polí usnadňujících tuto práci:

Tenant – Označení dat, kterých se defekt týká

Solution – Označení systému, ve kterém byla chyba nalezena (pole se během životního cyklu defektu neměnilo)

Component – Označení systému, který se chybou momentálně zabývá (Pokud byl defekt zachycen v posledním koncovém systému, bylo možné, že samotná chyba se nacházela v systému jemu nadřazeném)

Test Phase/Level – Označení, v jaké fázi testování byl defekt identifikován (Pro fáze FAT a UAT existovaly další specifické úrovně v závislosti na způsobu testování dat)

Ping-pong

Jedním z problémů, se kterými jsme se potýkali, bylo časté „přehazování“ defektů z jednoho systému do druhého kvůli doplnění informací. Pro tento účel sloužil status defektu „Info Needed“. Zavedli jsme sadu pravidel pro komunikaci v rámci řešení defektů, která přispěla k rychlejšímu řešení zadávaných defektů:

Léto je za dveřmi

Díky nasazení celého týmu a všech členů projektu v lednu 2021 jsme dosáhli posledního nasazení projektu SPRING do produkčního prostředí bez odkladů. Na projektu budou nadále probíhat změny a údržba. Během jednotlivých nasazení bylo možné pozorovat, jak se postupně zkracuje doba řešení defektů a díky tomu i celkové počty nevyřešených defektů. K tomu přispěly dva primární faktory: Jak sžití se stávajících uživatelů se systémem, tak inkrementální změny a vylepšení, které jsme do systému postupně dodávali.