Använda Gap-analys i testprocessen för att anpassa Devs och testare

det är en allmänt tro på att utvecklare och testare går vidare som krita och ost. Utvecklare tittar ofta ner i näsan på testare och ser dem som ett oflexibelt och ohjälpligt drag på att utveckla ny kod som inte ger tydliga detaljer i sina buggbiljetter. På samma sätt ser testare ofta utvecklare med irritation för att inte hålla dem informerade om kodändringar och för att driva nya förändringar under testcykler. Det är därför gap-analys i QA-testprocessen kan vara särskilt fördelaktigt för att anpassa både devs och testare.

även om denna vy kan vara apokryfisk, är det ofta så att utvecklare och testare inte kommunicerar bra. Ofta sker kommunikation endast via ledning (projektledare och linjechefer) eller via biljetter i Jira. Resultatet är att testning ofta visar sig vara otillräcklig. I synnerhet är alltför ofta ny kod dåligt testad eller inte testad alls. Forskning har visat att denna otestade nya kod är den största källan till framtida buggar och misslyckanden. Det är här begreppet Testgapanalys spelar in.

i den här bloggen kommer vi att undersöka vad Testgapanalys är, visa hur det kan hjälpa till att identifiera koden som behöver testas och undersöka om detta tillvägagångssätt är panacea som kan överbrygga klyftan mellan devs och testare.

Vad är Testgapanalys?

när du först utvecklar ett mjukvarusystem är det enkelt att vara säker på att du testar hela systemet. Testare kan ta kodspecifikationerna och använda en kombination av planerad och utforskande testning för att säkerställa att de testar varje rörlig del av kodbasen. De flesta program är dock inte statiska. Företag gör antingen monolitiska periodiska utgåvor av långlivad kod eller de använder en viss nivå av kontinuerlig integration och kontinuerlig distribution (CI/CD). I båda fallen förändras kodbasen ständigt. Men alltför ofta uppdateras inte testfallen i samma takt. Ibland vet testarna helt enkelt inte att en kodändring har gjorts. Andra gånger trycks kodändringen strax efter att en viss uppsättning tester har körts. Dessa tester verkar ha passerat, men kodändringen kan ha brutit dem.

Testgapanalys är processen att identifiera dessa luckor där ny kod har distribuerats men inte har testats ännu. Detta kräver en kombination av statisk analys av alla kodändringar och dynamisk analys av all aktuell testning. Genom att jämföra dessa två analyser kan du enkelt se var eventuella luckor är. Det vill säga områden med ny kod som har testats tillräckligt. Vanligtvis görs detta genom att plotta koden med hjälp av en form av träddiagram där koden är uppdelad i funktionella block, under varje block är de ingående klasserna, under dessa är de faktiska metoderna och funktionerna. På varje nivå i hierarkin anger blockets relativa storlek mängden kod. Genom att lägga över trädet som visar koden ändras med trädet som visar det aktuella testläget är det lätt att upptäcka de områden där det saknas testtäckning.

en trädkarta som visar oförändrad kod (grå), reviderad/ny kod som testas (grön), reviderad kod som inte testas (orange) och ny kod som inte testas (röd).

Varför kan testa Gap analys materia i testprocessen?

i ett 2013-papper körde forskare från Munich Technical University en studie för att titta på sambandet mellan Ny, otestad kod och framtida programfel. De arbetade med Munich Re (ett stort försäkringsbolag) och övervakade deras långlivade IT-system genom 2 utgåvor. Under utgåvan fastställde de vilken kod som var ny och tittade också på vilken kod som testades och vilken kod som släpptes otestad. Därefter övervakade de systemet under lång tid och spårade alla rapporterade buggar tillbaka till den ursprungliga källan. De upptäckte två viktiga saker. För det första släpptes ungefär en tredjedel av all kod otestad. För det andra, när de spårade buggarna upptäckte de totalt sett mellan 70 och 80% av alla buggar var i otestad kod. Diagrammet nedan visar detta tydligare.

som du kan se hade den gamla testade koden inga buggar. Den nya testade koden hade mellan 22 och 30% av buggarna och de återstående buggarna fördelades ganska jämnt mellan Ny otestad kod och gammal otestad kod. Eftersom den nya koden endast stod för 15% av den totala koden kan du dock se att den nya otestade koden stod för ett oproportionerligt stort antal buggar.

Testgapanalys är utformad för att identifiera denna otestade nya kod. Men det kan också hjälpa dig på andra sätt. Till exempel, eftersom det övervakar vad du testar, kan det identifiera områden med befintlig kod som är föråldrade (t.ex. de testas fortfarande, men anropas inte av någon kod). Det kan också markera vilka områden du behöver koncentrera dina testresurser på. Genom att köra det regelbundet kan chefer förbättra testplaneringen, fokusera på att testa ny kod och försöka säkerställa jämn testtäckning.

Devs och testare anpassade Genom Testgapanalys

Testgapanalys är helt klart ett kraftfullt koncept. Men det är också klart att inte alla lag kommer att dra lika nytta av det. De lag som kommer att gynna mest är de som upprätthåller långlivade kodbaser med periodiska monolitiska utgåvor. I långlivade kodbaser arbetar utvecklare ofta med kod som skrivits av andra människor. Testare kan förlita sig på testplaner producerade flera versioner tidigare. I kombination kan dessa faktorer innebära att ingen är helt klar vilken kod som testas eller hur den koden interagerar med andra delar av systemet. Här kan TGA låta testarna se exakt vilken kod som har ändrats vilket gör att de kan fokusera på detta. De kan också identifiera kod i det befintliga systemet som inte är testat.

lag som använder CI/CD kan också dra nytta av detta tillvägagångssätt eftersom det gör det möjligt för testarna att snabbt identifiera exakt vilken kod som ändras och så låta dem koncentrera sig på det. Det kan också undvika problemet som nämns ovan där en bit kod ändras direkt efter att den har testats och sedan släpps med ändringarna otestade.

å andra sidan kommer lag som arbetar med ny eller kortlivad kod att gynna mindre, eftersom de flesta kod per definition kommer att vara otestade först. Här är det viktigt att använda standardtestmetoder för att säkerställa att din testning är bra. Det kan dock vara användbart för sådana team att börja övervaka testtäckningen med TGA eftersom det gör det möjligt för dem att undvika framtida problem.

vilka är de potentiella problemen?

det finns några problem med TGA. En av de största hänför sig till det faktum att det inte kan berätta vilken kod som aktivt kallas i kodbasen. Utvecklare lägger ofta till ny kod som förberedelse för framtida utgåvor, men eftersom detta är inaktivt kan testpaketet inte kalla det. Som ett resultat kommer denna kod alltid att visas som ny otestad kod. På samma sätt innehåller många stora kodbaser block av gammal eller föräldralös kod. Dessa bör rengöras regelbundet, men igen kommer dessa att snedvrida bilden för Testgapanalysen.

en annan viktig observation är att bara för att en bit kod testas utesluter inte den koden från att utlösa buggar någon annanstans. Några av de värsta buggarna är sådana där en liten förändring i en kodkod gör att en funktion eller metod misslyckas i ett helt orelaterat kodblock. Så det är viktigt att fortsätta göra både undersökande testning och regressionstestning. Vad TGA kan göra är att identifiera områden i din befintliga kodbas som inte testas ordentligt under din regressionstestning.

vilka andra alternativ hjälper till att överbrygga klyftan?

Testgapanalys är definitivt ett användbart verktyg för vissa lag. Det finns dock andra sätt att undvika en obalans mellan vad dina testare testar och vad dina kodare kodar. Ett sätt är att använda mer intelligent testautomatisering som kan identifiera var och när saker har förändrats, både på frontend men också, viktigare, i backend. Här på Functionize använder våra tester intelligent fingeravtryck i kombination med maskininlärning och självläkning för att minska testunderhållet. Detta gör det möjligt för testerna att proaktivt anpassa sig till frontend-ändringar samt att övervaka saker som serversamtal, svarstider och om Knappar/funktioner faktiskt är synliga. Det betyder att dina testare inte kommer att fångas av ändringar som gjorts i backend-koden eller design/CSS-ändringar som ändrar frontend-layouten.

vårt intelligenta system kan också skapa tester genom att övervaka hur användare interagerar med systemet. Detta hjälper till att säkerställa att det finns färre luckor i testtäckningen. Ett av våra senaste verktyg låter dig skriva nya tester på vanlig engelska. Dessa analyseras av vårt naturliga Språkbehandlingsverktyg och omvandlas till användbara tester. Detta innebär att under utveckling kan devs helt enkelt ange vad som behöver testas med normal engelska och därmed stänga klyftan mellan de två disciplinerna ytterligare.

slutsatser

Testgapanalys hjälper dig att identifiera vilken kod som släpps otestad och kan därmed hjälpa dig att fokusera dina testresurser mer effektivt. Det är inte överraskande att det visar sig att otestad kod är mycket mer sannolikt att innehålla buggar och så är alla verktyg som kan hjälpa till att säkerställa att denna kod är korrekt testad användbar. Men som vi har sett kan TGA bara komplettera befintlig bästa praxis. Det är viktigt att fortsätta med din regressionstestning och utforskande testning. Många av fördelarna med TGA kan också uppnås genom att använda intelligenta testverktyg. Men totalt sett är det viktigaste att undvika att isolera ditt testteam från dina devs arbete. För att felcitera ett gammalt ordspråk bör du se till att vänster hand vet vad höger hand gör!