Řízení testování na základě rizik

Projekt si klade za cíl poskytnout jednodušší řešení pro správu identit v organizaci jako náhradu za současné řešení, které má být vyřazeno z provozu. Cílové řešení by mělo zrušit závislost na dodavateli současného řešení, zlepšit dokumentaci a automatizovat některé procesy, které byly dříve manuální.

Složení týmu:

• Seniorní konzultant testování
• Manažeři testování
• Seniorní analytici testování
• Analytici testování
• Inženýři testování

Popis situace, do které jsme vstupovali

Náš tým se připojil k probíhajícímu projektu. Vývoj cílového řešení probíhal už 2 roky a blížilo se jeho dokončení. Testování mělo začít. Dostali jsme za úkol testování integrací systému, které by ověřilo připravenost na akceptační testování. Bylo to v době první vlny pandemie COVID-19, takže bylo možné se připojit, zaškolit a pracovat jedině na dálku.

Projekt představoval významné změny napříč více systémy. Současné řešení existovalo a bylo udržováno po dobu 15 let. Klíčové znalosti byly rozptýleny mezi zastaralými dokumenty, v samotném zdrojovém kódu a paměti zaměstnanců (řada z nich organizaci už opustila). Projektový tým neměl mnoho zkušeností s projekty tohoto rozsahu, ještě méně pak s integračním testováním.

Testování integrace systému nebylo součástí původního rozsahu a bylo přidáno do již fixního harmonogramu. Proto byl plán pouze rozšířen o paralelní úkoly. Cílem integračního testování bylo pokrýt integrace 11 systémů v rámci projektu včetně jejich základních integrací do zdrojových a konzumentských systémů.

Popis vývoje projektu: začátek, průběh, konec

Počáteční průzkum odhalil, že požadavky byly chabě zdokumentované, těžko testovatelné, a že stávající týmy měly velmi málo zkušeností s testováním softwaru, ale připravily, revidovaly a schválily testovací případy. Během počátečního průzkumu bylo dále zjištěno, že jednotlivé týmy dosud pracovaly až doposud v téměř úplné izolaci, bez komunikace s paralelními týmy a se zástupci koncových uživatelů. Z tohoto důvodu dosud nebyla objevena žádná nedorozumění nebo mezery v návrhu. Dodavatelé uzavřeli své testování bez mnoha významných nálezů.

První indikační test integrace ve vývojovém prostředí identifikoval rozsah návrhových mezer, kvůli kterým musel být přechod do testovací fáze odložen o 3 měsíce. Během těchto tří měsíců všechny týmy společně pracovaly na porozumění klíčovým případům užití a zajištění, aby byly podporovány řešením, jak bylo zamýšleno, bez nežádoucích vedlejších účinků.

Testování ve společném integračním prostředí se ukázalo být obtížnější, než se očekávalo, a to kvůli častým problémům s výkonem, celkové nestabilitě prostředí a kvalitě jedné z klíčových částí cílového řešení. Rozhodnutí o paralelizaci integračního a akceptačního testování pak pomohlo zmírnit zpoždění v realizačních milnících projektu. To mělo za následek zvýšenou pracnost akceptačního testování kvůli doposud neodhaleným nedostatkům v návrhu řešení, a také zpoždění v nasazení do provozu.

V průběhu projektu byly změněny požadavky na administraci a dokumentaci práce, což ovlivnilo pracnost pro všechny týmy účastnící se testování. Testování bylo dokončeno v revidovaném harmonogramu a splňovalo všechny podmínky potřebné pro rozhodnutí přechodu do produkce.

Popis hlavních překážek a jejich řešení

Problém č. 1: Výměna starého systému, kdy klíčové znalosti byly rozptýleny v zastaralých dokumentech, zdrojovém kódu a mezi zaměstnanci, kteří opustili společnost. Problém byl řešen zavedením experimentálních testovacích relací vedených zkušenými testery s využitím zástupců koncových uživatelů a odborníků na jednotlivé komponenty systému. Pomohlo také provést zpětnou analýzu procesů a jejich dodatečnou dokumentaci.

Problém č. 2: Neustále se měnící rozhraní, datové toky a komunikační modely brání jakékoli možnosti automatizace a výrazně snižují účinnost testování na rozhraní. Zodpovědnosti byly odděleny, aby se snížilo překrývání testování mezi továrním testováním a integračním testováním. Dodavatelé se stali odpovědnými za testování rozhraní, interních datových toků a komunikačních modelů vlastní komponenty s nejbližšími systémy. Tým pro integrační testování byl zodpovědný pouze za testování šíření dat E2E.

Problém č. 3: Malá až žádná spolupráce mezi projektovými týmy byla řešena organizováním samostatných schůzek o stavu a závadách s jednotlivými týmy i společných schůzek o stavu vývoje a testování. Bylo zapotřebí mikromanagementu ze strany projektových, testovacích i defektových manažerů.

Problém č. 4: Nezkušeným testovacím týmům byla poskytnuta podpora zkušenými testery. Byly stanoveny časové úseky vyhrazené pro konzultace jejich problémů, otázek a revizi provedené práce.

Problém č. 5: Změny v minimálních přijatelných postupech dokumentace v průběhu testování. Změny byly komunikovány se všemi dotčenými stranami, byl přidělen čas navíc k řešení všech nezbytných změn. Retrospektivní změny, u nichž by nebylo možné shromáždit požadované podrobnosti nebo by spojené úsilí představovalo ohrožení včasného dodání projektu, byly pak řešeny zprávami vysvětlujícími, proč k rozporu dokumentace došlo a co bylo učiněno, aby se v budoucnu takovému rozporu předešlo. K těmto zprávám byly navíc připojeny s doprovodnými podpisy příslušných odpovědných osob.

Problém č. 6: Dodržování předpisů přizpůsobených pro vodopádový projekt výrazně omezuje možnosti zrychlení postupu a představuje riziko významné dodatečné pracnosti při dodržení metodiky. Bylo umožněno použití agilní metodiky při zachování artefaktů, které by vytvořil původní přístup. Některé z artefaktů bylo nutné dodatečně vytvořit čistě pro účely splnění podmínek a pravidel metodiky.

Šťastný konec

Podařilo se nám vést týmy pro testování projektu k úspěšnému a produktivnímu uzavření testovací fáze. Našli jsme přes 500 defektů za období 4 měsíců, z nichž více než 200 mělo kritický charakter. Dohlédli jsme samozřejmě i na to, aby byly opraveny, řádně přetestovány a zaznamenány, případně aby nevyřízené položky byly předány do další fáze projektu. Řešení bylo shledáno životaschopným a mělo by brzy nahradit předchozí řešení.