Brug af Gap-analyse i testprocessen til at justere Devs og testere

det er en udbredt tro på, at udviklere og testere fortsætter som kridt og ost. Udviklere ser ofte ned på deres næse på testere og ser dem som et ufleksibelt og uhensigtsmæssigt træk ved at udvikle ny kode, der ikke giver klare detaljer i deres bugbilletter. Ligeledes ser testere ofte udviklere med irritation for ikke at holde dem informeret om kodeændringer og for at skubbe nye ændringer under testcyklusser. Dette er grunden til, at gap-analyse i KVALITETSSIKRINGSTESTPROCESSEN kan være særlig gavnlig for at tilpasse både devs og testere.

selvom denne visning kan være apokryf, er det ofte tilfældet, at udviklere og testere ikke kommunikerer godt. Ofte sker kommunikation kun via ledelse (projektledere og linjeledere) eller via billetter i Jira. Resultatet er, at test ofte viser sig at være utilstrækkelig. Især er alt for ofte ny kode Dårligt testet eller slet ikke testet. Forskning har vist, at denne uprøvede nye kode er den største kilde til fremtidige fejl og fejl. Det er her begrebet Test Gap analyse kommer i spil.

i denne blog vil vi undersøge, hvad Testgabanalyse er, vise, hvordan det kan hjælpe med at identificere den kode, der skal testes, og undersøge, om denne tilgang er det universalmiddel, der kan bygge bro mellem devs og testere.

Hvad er Test Gap analyse?

når du først udvikler et system, er det nemt at være sikker på, at du tester hele systemet. Testere er i stand til at tage kodespecifikationerne og bruge en kombination af planlagt og sonderende test for at sikre, at de tester alle bevægelige dele af kodebasen. De fleste programmer er ikke statiske. Virksomheder laver enten monolitiske periodiske udgivelser af langvarig kode, eller de anvender et vist niveau af kontinuerlig integration og kontinuerlig implementering (CI/CD). I begge tilfælde ændrer kodebasen sig konstant. Men alt for ofte opdateres testsagerne ikke med samme hastighed. Nogle gange ved testerne simpelthen ikke, at der er foretaget en kodeændring. Andre gange skubbes kodeændringen lige efter, at et bestemt sæt tests er kørt. Disse tests ser ud til at være bestået, men kodeændringen kan have brudt dem.

Test Gap analyse er processen med at identificere disse huller, hvor ny kode er blevet implementeret, men ikke er blevet testet endnu. Dette kræver en kombination af statisk analyse af alle kodeændringer og dynamisk analyse af alle aktuelle test. Ved at sammenligne disse to analyser kan du nemt se, hvor der er huller. Det vil sige områder med ny kode, der er blevet testet tilstrækkeligt. Dette gøres typisk ved at plotte koden ved hjælp af en form for trædiagram, hvor koden er opdelt i funktionelle blokke, under hver blok er de sammensatte klasser, under dem er de faktiske metoder og funktioner. På hvert niveau i hierarkiet angiver den relative størrelse af blokken mængden af kode. Ved at overlejre træet, der viser kodeændringerne, med træet, der viser den aktuelle testtilstand, er det let at få øje på de områder, hvor der mangler testdækning.

et trækort, der viser uændret kode (grå), revideret/ny kode, der er testet (grøn), revideret kode, der er uprøvet (orange) og ny kode, der er uprøvet (rød).

Hvorfor kan Test Gap analyse sagen i testprocessen?

i en artikel fra 2013 gennemførte forskere fra Munichs Tekniske Universitet en undersøgelse for at se på sammenhængen mellem nye, uprøvede kode-og fremtidige fejl. De arbejdede med Munich Re (et stort forsikringsselskab) og overvågede deres langvarige IT-system gennem 2 udgivelser. Under frigivelsen, de etablerede, hvilken kode der var ny, og kiggede også på, hvilken kode der blev testet, og hvilken kode der blev frigivet uprøvet. Derefter overvågede de systemet i lang tid og spores alle rapporterede fejl tilbage til den oprindelige kilde. De opdagede to vigtige ting. For det første blev omkring en tredjedel af al kode frigivet uprøvet. For det andet, da de spores fejlene, opdagede de samlet mellem 70 og 80% af alle fejl var i uprøvet kode. Grafen nedenfor viser dette tydeligere.

som du kan se, havde den gamle testede kode ingen fejl. Den nye testede kode havde mellem 22 og 30% af fejlene, og de resterende fejl blev fordelt ret jævnt mellem ny uprøvet kode og gammel uprøvet kode. Da den nye kode kun tegnede sig for 15% af den samlede kode, kan du se, at den nye uprøvede kode tegnede sig for et uforholdsmæssigt stort antal fejl.

Test Gap analyse er designet til at identificere denne uprøvede nye kode. Det kan dog også hjælpe dig på andre måder. For eksempel, fordi det overvåger, hvad du tester, kan det identificere områder af eksisterende kode, der er forældede (f.eks. Det kan også fremhæve, hvilke områder du har brug for at koncentrere dine testressourcer på. Ved at køre det regelmæssigt kan ledere forbedre testplanlægningen, fokusere på at teste ny kode og forsøge at sikre jævn testdækning.

Devs og testere justeret gennem Test Gap analyse

Test Gap analyse er helt klart en kraftfuld koncept. Men det er også klart, at ikke alle hold vil drage lige fordel af det. De hold, der vil gavne mest, er dem, der opretholder langvarige kodebaser med periodiske monolitiske udgivelser. I langlivede kodebaser arbejder udviklere ofte på kode, der blev skrevet af andre mennesker. Testere kan stole på testplaner produceret flere versioner før. Taget i kombination kan disse faktorer betyde, at ingen er helt klar over, hvilken kode der testes, eller hvordan denne kode interagerer med andre dele af systemet. Her kan TGA give testerne mulighed for at se nøjagtigt, hvilken kode der er ændret, hvilket giver dem mulighed for at fokusere på dette. De kan også identificere kode i det eksisterende system, der er uprøvet.

hold, der bruger CI/CD, kan også drage fordel af denne tilgang, da det giver testerne mulighed for hurtigt at identificere nøjagtigt, hvilken kode der ændres, og så give dem mulighed for at koncentrere sig om det. Det kan også undgå det ovennævnte problem, hvor et stykke kode ændres lige efter det er blevet testet og derefter frigives med ændringerne uprøvede.

på den anden side vil hold, der arbejder på ny eller kortvarig kode, have mindre fordel, da de fleste koder pr. Her er det vigtigt at bruge standard testmetoder for at sikre, at din test er god. Det kan dog være nyttigt for sådanne hold at begynde at overvåge testdækningen ved hjælp af TGA, da det giver dem mulighed for at undgå fremtidige problemer.

hvad er de potentielle problemer?

der er et par problemer med TGA. En af de største vedrører det faktum, at det ikke kan fortælle dig, hvilken kode der aktivt kaldes i kodebasen. Udviklere tilføjer ofte ny kode som forberedelse til fremtidige udgivelser, men da dette er inaktivt, kan testsuiten ikke kalde det. Som et resultat vises denne kode altid som ny uprøvet kode. Ligeledes indeholder mange store kodebaser blokke af gammel eller forældreløs kode. Disse skal ryddes op med jævne mellemrum, men igen vil disse fordreje billedet til Testgabanalysen.

en anden vigtig observation er, at bare fordi et stykke kode testes, udelukker det ikke, at koden udløser fejl andre steder. Nogle af de værste fejl er dem, hvor en lille ændring i et stykke kode får en funktion eller metode til at mislykkes i en helt uafhængig kodeblok. Så det er vigtigt at fortsætte med at udføre både sonderende test og regressionstest. Hvad TGA kan gøre er at identificere områder i din eksisterende kodebase, der ikke testes korrekt under din regressionstest.

hvilke andre alternativer hjælper med at bygge bro over kløften?

Test Gap analyse er absolut et nyttigt værktøj for nogle hold. Der er dog andre måder at undgå en uoverensstemmelse mellem, hvad dine testere tester, og hvad dine kodere koder. En måde er at bruge mere intelligent testautomatisering, der er i stand til at identificere, hvor og hvornår tingene har ændret sig, både på frontend, men også vigtigere i backend. Her på Funktion, vores tests bruger intelligent fingeraftryk kombineret med maskinindlæring og selvhelbredelse for at reducere testvedligeholdelse. Dette gør det muligt for testene proaktivt at tilpasse sig frontend-ændringer såvel som at overvåge ting som serveropkald, responstider og om knapper/funktioner faktisk er synlige. Dette betyder, at dine testere ikke bliver fanget af ændringer foretaget i backend-koden eller design/CSS-ændringer, der ændrer frontend-layoutet.

vores intelligente system kan også oprette test ved at overvåge, hvordan brugerne interagerer med systemet. Dette hjælper med at sikre, at der er færre huller i testdækningen. Et af vores nyeste værktøjer giver dig mulighed for at skrive nye tests på almindeligt engelsk. Disse analyseres af vores naturlige Sprogbehandlingsværktøj og konverteres til brugbare tests. Dette betyder, at devs under udvikling simpelthen kan specificere, hvad der skal testes ved hjælp af normal engelsk, og dermed lukke kløften mellem de to discipliner yderligere.

konklusioner

Test Gap-analyse hjælper dig med at identificere, hvilken kode der frigives uprøvet og dermed kan hjælpe dig med at fokusere dine testressourcer mere effektivt. Ikke overraskende viser det sig, at uprøvet kode er langt mere tilbøjelig til at indeholde fejl, og derfor er ethvert værktøj, der kan hjælpe med at sikre, at denne kode testes korrekt, nyttigt. Men som vi har set TGA kan kun supplere eksisterende bedste praksis. Det er vigtigt at holde op med din regressionstest og sonderende test. Mange af fordelene ved TGA kan også opnås ved hjælp af intelligente testværktøjer. Men generelt er det vigtigste at undgå at isolere dit testteam fra dine devs arbejde. For at fejlcitere et gammelt ordsprog skal du sørge for, at venstre hånd ved, hvad højre hånd gør!