Použití analýzy mezer v procesu testování k zarovnání vývojářů a testerů

je všeobecně uznávaným přesvědčením, že vývojáři a testeři pokračují jako křída a sýr. Vývojáři často hledí na testery, považují je za nepružný a neužitečný tah na vývoj nového kódu, který nedokáže poskytnout jasné podrobnosti ve svých lístcích na chyby. Stejně tak testeři často vidí vývojáře s podrážděním za to, že je neinformovali o změnách kódu a za prosazování nových změn během testovacích cyklů. To je důvod, proč analýza mezer v procesu testování QA může být zvláště přínosná pro zarovnání vývojářů i testerů.

i když tento pohled může být apokryfní, často se stává, že vývojáři a testeři nekomunikují dobře. Komunikace často probíhá pouze prostřednictvím managementu (projektových manažerů a liniových manažerů) nebo prostřednictvím ticketů v Jira. Výsledkem je, že testování se často ukáže jako nedostatečné. Zejména až příliš často je nový kód špatně testován nebo vůbec netestován. Výzkum ukázal, že tento netestovaný nový kód je největším zdrojem budoucích chyb a selhání. Zde přichází do hry koncept analýzy testovacích mezer.

v tomto blogu prozkoumáme, co je analýza testovacích mezer, ukážeme, jak může pomoci identifikovat kód, který je třeba otestovat, a prozkoumáme, zda je tento přístup všelékem, který může překlenout propast mezi vývojáři a testery.

co je test Gap analýza?

při prvním vývoji softwarového systému je snadné se ujistit, že testujete celý systém. Testeři jsou schopni vzít SPECIFIKACE kódu a použít kombinaci plánovaného a průzkumného testování, aby zajistili, že otestují každou pohyblivou část kódové základny. Většina softwaru však není statická. Společnosti buď monolitické periodické vydání kódu s dlouhou životností, nebo používají určitou úroveň nepřetržité integrace a nepřetržitého nasazení (CI / CD). V obou případech se kódová základna neustále mění. Až příliš často se však testovací případy neaktualizují stejnou rychlostí. Někdy testeři prostě nevědí, že došlo ke změně kódu. Jindy je změna kódu tlačena těsně po spuštění určité sady testů. Zdá se, že tyto testy prošly, ale změna kódu je mohla zlomit.

Test Gap Analysis je proces identifikace těchto mezer, kde byl nový kód nasazen, ale dosud nebyl testován. To vyžaduje kombinaci statické analýzy všech změn kódu a dynamické analýzy všech současných testů. Porovnáním těchto dvou analýz můžete snadno zjistit, kde jsou mezery. To znamená oblasti Nového kódu, které byly adekvátně testovány. Obvykle se to provádí vykreslením kódu pomocí formy stromového diagramu, kde je Kód rozdělen na funkční bloky, pod každým blokem jsou základní třídy, pod nimi jsou skutečné metody a funkce. Na každé úrovni v hierarchii relativní velikost bloku označuje množství kódu. Překrytím stromu zobrazujícího změny kódu se stromem zobrazujícím aktuální stav testování je snadné zjistit oblasti, kde chybí pokrytí testu.

stromová mapa zobrazující nezměněný kód (šedý), revidovaný / nový kód, který je testován (zelený), revidovaný kód, který je netestovaný (oranžový) a nový kód, který je netestovaný (červený).

proč by Test Gap analýza záležitost v procesu testování?

v roce 2013 vědci z Mnichovské Technické univerzity provedli studii, aby se podívali na korelaci mezi novým, netestovaným kódem a budoucími softwarovými chybami. Spolupracovali s Munich Re (velkou pojišťovnou) a sledovali svůj it systém s dlouhou životností prostřednictvím 2 vydání. Během vydání, zjistili, který kód je nový, a také se podívali na to, který kód byl testován a který kód byl vydán netestovaný. Poté systém dlouho sledovali a všechny nahlášené chyby sledovali zpět k původnímu zdroji. Objevili dvě klíčové věci. Za prvé, zhruba třetina veškerého kódu byla vydána netestovaná. Za druhé, když vystopovali chyby, které objevili celkově mezi 70 a 80% všech chyb bylo v netestovaném kódu. Níže uvedený graf to ukazuje jasněji.

jak vidíte, starý testovaný kód neměl žádné chyby. Nový testovaný kód měl mezi 22 a 30% chyb a zbývající chyby byly distribuovány poměrně rovnoměrně mezi nový netestovaný kód a starý netestovaný kód. Protože však nový kód představoval pouze 15% celkového kódu, můžete vidět, že nový netestovaný kód představoval nepřiměřeně vysoký počet chyb.

Test Gap Analysis je navržen tak, aby identifikoval tento netestovaný nový kód. Může vám však pomoci i jinými způsoby. Například, protože monitoruje to, co testujete, může identifikovat oblasti existujícího kódu, které jsou zastaralé (např. jsou stále testovány ,ale ve skutečnosti nejsou volány žádným kódem). Může také zvýraznit, na které oblasti musíte soustředit své testovací zdroje. Pravidelným spuštěním mohou manažeři zlepšit plánování testů, zaměřit se na testování nového kódu a snažit se zajistit rovnoměrné pokrytí testů.

vývojáři a testeři zarovnáni pomocí analýzy testovacích mezer

analýza testovacích mezer je jednoznačně silný koncept. Ale je také jasné, že ne všechny týmy z toho budou mít stejný prospěch. Týmy, které budou mít největší prospěch, jsou ti, kteří udržují dlouhodobé základové kódy s periodickými monolitickými vydáními. V kódových základnách s dlouhou životností vývojáři často pracují na kódu, který napsali jiní lidé. Testeři mohou spoléhat na testovací plány vyrobené několik verzí dříve. V kombinaci mohou tyto faktory znamenat, že nikdo není zcela jasný, který kód je testován nebo jak tento kód interaguje s jinými částmi systému. Zde může TGA umožnit testerům přesně zjistit, jaký kód se změnil, což jim umožňuje soustředit se na to. Mohou také identifikovat kód ve stávajícím systému, který je netestovaný.

týmy používající CI / CD mohou také těžit z tohoto přístupu, protože umožní testerům rychle určit, jaký kód se změnil, a tak jim umožní soustředit se na to. Může se také vyhnout výše uvedenému problému, kdy je část kódu změněna ihned poté, co byla testována, a poté se uvolní se změnami netestovanými.

na druhé straně týmy, které pracují na Novém nebo krátkodobém kódu, budou mít menší prospěch, protože podle definice bude většina kódu nejprve netestována. Zde je důležité používat standardní testovací metodiky, aby bylo zajištěno, že vaše testování je dobré. Pro tyto týmy však může být užitečné začít sledovat pokrytí testů pomocí TGA, protože jim to umožní vyhnout se budoucím problémům.

jaké jsou potenciální problémy?

existuje několik problémů s TGA. Jeden z největších souvisí se skutečností, že vám nemůže říct, který kód je aktivně volán v kódové základně. Vývojáři často přidávají nový kód v rámci přípravy na budoucí vydání, ale protože je neaktivní, testovací sada jej nemůže volat. V důsledku toho se tento kód vždy zobrazí jako nový netestovaný kód. Stejně tak mnoho velkých kódových základen obsahuje bloky starého nebo osamoceného kódu. Ty by měly být pravidelně čištěny, ale opět to zkreslí obraz pro analýzu mezer testu.

dalším důležitým poznatkem je, že jen proto, že je testován kus kódu, nevylučuje, aby tento kód spustil chyby jinde. Některé z nejhorších chyb jsou ty, kde malá změna v jednom kusu kódu způsobí selhání funkce nebo metody ve zcela nesouvisejícím bloku kódu. Je tedy nezbytné pokračovat v průzkumném testování i regresním testování. Co může TGA udělat, je identifikovat oblasti ve vaší stávající kódové základně, které nejsou během regresního testování řádně testovány.

jaké další alternativy pomáhají překlenout mezeru?

test Gap analysis je pro některé týmy rozhodně užitečným nástrojem. Existují však i jiné způsoby, jak se vyhnout nesouladu mezi tím, co testeři testují, a tím, co kodéry kódují. Jedním ze způsobů je použití inteligentnější automatizace testů, která dokáže zjistit, kde a kdy se věci změnily, a to jak na frontendu, ale také, co je důležité, v backendu. Zde ve Functionize používají naše testy inteligentní otisky prstů spojené se strojovým učením a samoléčbou ke snížení údržby testů. To umožňuje testům aktivně se přizpůsobit změnám frontendu a sledovat věci, jako jsou volání serveru, doby odezvy a to, zda jsou tlačítka/funkce skutečně viditelné. To znamená, že vaši testeři nebudou chyceni změnami provedenými v backendovém kódu nebo změnami designu / CSS, které mění rozvržení frontendu.

náš inteligentní systém může také vytvářet testy sledováním interakce uživatelů se systémem. To pomáhá zajistit, aby v pokrytí testu bylo méně mezer. Jeden z našich nejnovějších nástrojů vám umožňuje psát nové testy v jednoduché angličtině. Ty jsou analyzovány pomocí našeho nástroje pro zpracování přirozeného jazyka a převedeny na použitelné testy. To znamená, že během vývoje mohou vývojáři jednoduše určit, co bude třeba testovat pomocí normální angličtiny, čímž se mezera mezi oběma disciplínami dále uzavře.

závěry

Test Gap Analysis vám pomůže zjistit, jaký kód se vydává netestovaný, a tak vám může pomoci efektivněji zaměřit své testovací zdroje. Není překvapením, že se ukázalo, že netestovaný kód je mnohem pravděpodobnější, že bude obsahovat chyby, a proto je užitečný jakýkoli nástroj, který může pomoci zajistit, aby byl tento kód správně testován. Jak jsme však viděli, TGA může pouze doplnit stávající osvědčené postupy. Je nezbytné, aby se vaše regresní testování a průzkumné testování. Mnoho výhod TGA lze také dosáhnout pomocí inteligentních testovacích nástrojů. Ale celkově, hlavní věcí, které je třeba se vyhnout, je izolace testovacího týmu od práce vašich vývojářů. Chcete-li špatně citovat staré pořekadlo, měli byste se ujistit, že levá ruka ví, co dělá pravá ruka!