Bruke Gap Analyse I Testprosessen For Å Justere Devs Og Testere

Det er en utbredt tro på at utviklere og testere får på som kritt og ost. Utviklere ser ofte ned i nesen på testere, ser dem som en ufleksibel og unhelpful dra på å utvikle ny kode som ikke klarer å gi klare detaljer i sine feilbilletter. På samme måte ser testere ofte utviklere med irritasjon for ikke å holde dem informert om kodeendringer og for å presse nye endringer under testsykluser. Dette er grunnen til at gapanalyse i QA-testprosessen kan være spesielt gunstig for å tilpasse både devs og testere.

selv om denne visningen kan være apokryfe, er det ofte tilfelle at utviklere og testere ikke kommuniserer godt. Ofte skjer kommunikasjon bare via ledelse (prosjektledere og linjeledere) eller via billetter I Jira. Resultatet er at testingen ofte viser seg å være utilstrekkelig. Spesielt er alt for ofte ny kode dårlig testet eller ikke testet i det hele tatt. Forskning har vist at denne uprøvde nye koden er den største kilden til fremtidige feil og feil. Det er her Begrepet Testgapanalyse kommer inn i spill.

i denne bloggen vil vi utforske Hva Testgapanalyse er, vise hvordan det kan bidra til å identifisere koden som må testes og undersøke om denne tilnærmingen er panacea som kan bygge bro over gapet mellom utviklere og testere.

Hva Er Testgapanalyse?

når du først utvikler et programvaresystem, er det enkelt å være sikker på at du tester hele systemet. Testere er i stand til å ta kodespesifikasjonene og bruke en kombinasjon av planlagt og utforskende testing for å sikre at de tester alle bevegelige deler av kodebasen. Imidlertid er de fleste programvare ikke statisk. Selskaper enten gjøre monolittiske periodiske utgivelser av lang levetid kode eller de benytter noen grad av kontinuerlig integrasjon og kontinuerlig distribusjon (CI / CD). I begge tilfeller er kodebasen i stadig endring. Men alt for ofte blir testtilfellene ikke oppdatert i samme takt. Noen ganger vet testerne ganske enkelt ikke at en kodeendring er gjort. Andre ganger blir kodeendringen presset like etter at et bestemt sett med tester er kjørt. Disse testene ser ut til å ha bestått, men kodeendringen kan ha brutt dem.

Testgapanalyse er prosessen med å identifisere disse hullene der ny kode har blitt distribuert, men ikke blitt testet ennå. Dette krever en kombinasjon av statisk analyse av alle kodeendringer og dynamisk analyse av all gjeldende testing. Ved å sammenligne disse to analysene, kan du enkelt se hvor eventuelle hull er. Det vil si områder med ny kode som har blitt tilstrekkelig testet. Vanligvis gjøres dette ved å plotte koden ved hjelp av en form for trediagram hvor koden er delt inn i funksjonelle blokker, under hver blokk er de bestanddelene, under de er de faktiske metodene og funksjonene. På hvert nivå i hierarkiet angir den relative størrelsen på blokken mengden kode. Ved å legge over treet som viser koden endres med treet som viser den nåværende tilstanden for testing, er det enkelt å få øye på områdene der det mangler testdekning.

et trekart som viser uendret kode (grå), revidert/ny kode som er testet (grønn), revidert kode som ikke er testet (oransje) og ny kode som ikke er testet (rød).

Hvorfor Kan Teste Gap Analyse saken i testprosessen?

i et 2013-papir kjørte forskere fra Munich Technical University en studie for å se på sammenhengen mellom ny, uprøvd kode og fremtidige programvarefeil. De jobbet med Munich Re (et stort forsikringsselskap), overvåker DERES LANGLIVEDE IT-system gjennom 2 utgivelser. Under utgivelsen etablerte de hvilken kode som var ny og så også på hvilken kode som ble testet og hvilken kode som ble utgitt uprøvd. Etter det overvåket de systemet i lang tid og sporet alle rapporterte feil tilbake til den opprinnelige kilden. De oppdaget to viktige ting. For det første ble omtrent en tredjedel av all kode utgitt uprøvd. For det andre, da de sporet feilene, oppdaget de samlet mellom 70 og 80% av alle feilene var i uprøvd kode. Grafen nedenfor viser dette tydeligere.

Som du kan se, hadde den gamle testede koden ingen feil. Den nye testede koden hadde mellom 22 og 30% av feilene, og de resterende feilene ble fordelt ganske jevnt mellom ny uprøvd kode og gammel uprøvd kode. Men siden den nye koden bare utgjorde 15% av den totale koden, kan du se at den nye uprøvde koden utgjorde et uforholdsmessig høyt antall feil.

Testgapanalyse er utformet for å identifisere denne uprøvde nye koden. Det kan imidlertid også hjelpe deg på andre måter. For eksempel, fordi det overvåker hva du tester, kan det identifisere områder av eksisterende kode som er utdaterte(f. eks. Det kan også markere hvilke områder du trenger å konsentrere testressursene dine på. Ved å kjøre den regelmessig kan ledere forbedre testplanleggingen, fokusere på å teste ny kode og forsøke å sikre jevn testdekning.

Devs og Testere justert Gjennom Testgapanalyse

Testgapanalyse er klart et kraftig konsept. Men det er også klart at ikke alle lag vil ha like stor nytte av det. Lagene som vil være mest til nytte, er de som opprettholder langlivede kodebaser med periodiske monolitiske utgivelser. I langlivede kodebaser jobber utviklere ofte med kode som ble skrevet av andre mennesker. Testere kan stole på testplaner produsert flere versjoner før. Tatt i kombinasjon, kan disse faktorene bety at ingen er helt klart hvilken kode som testes eller hvordan koden samhandler med andre deler av systemet. HER KAN TGA tillate testerne å se nøyaktig hvilken kode som er endret, noe som gjør at DE kan fokusere på dette. De kan også identifisere kode i det eksisterende systemet som ikke er testet.

Lag som bruker CI / CD kan også dra nytte av denne tilnærmingen, da det vil tillate testerne å raskt identifisere nøyaktig hvilken kode som er endret og så tillate dem å konsentrere seg om det. Det kan også unngå problemet nevnt ovenfor der et stykke kode endres rett etter at det er testet og deretter blir utgitt med endringene som ikke er testet.

på den annen side vil lag som jobber med ny eller kortvarig kode, ha mindre nytte, siden de fleste koder per definisjon ikke vil bli testet først. Her er det viktig å bruke standard testmetoder for å sikre at testingen er god. Det kan imidlertid være nyttig for slike lag å begynne å overvåke testdekningen ved HJELP AV TGA, siden det vil tillate dem å unngå fremtidige problemer.

hva er de potensielle problemene?

DET er noen problemer MED TGA. En av de største er knyttet til det faktum at det ikke kan fortelle deg hvilken kode som aktivt kalles i kodebasen. Utviklere legger ofte til ny kode som forberedelse til fremtidige utgivelser, men siden dette er inaktivt, kan testpakken ikke kalle det. Som et resultat vil denne koden alltid vises som ny uprøvd kode. På samme måte inneholder mange store kodebaser blokker med gammel eller foreldreløs kode. Disse bør ryddes opp med jevne mellomrom, men igjen vil disse forvride bildet for Testgapanalysen.

En annen viktig observasjon er at bare fordi et stykke kode er testet, utelukker ikke at koden utløser feil andre steder. Noen av de verste feilene er de der en liten endring i ett stykke kode fører til at en funksjon eller metode mislykkes i en helt uavhengig kodeblokk. Så det er viktig å fortsette å gjøre både utforskende testing og regresjonstesting. HVA TGA kan gjøre er å identifisere områder i din eksisterende kodebase som ikke blir testet riktig under regresjonstesting.

Hvilke andre alternativer bidrar til å bygge bro over gapet?

Testgapanalyse er definitivt et nyttig verktøy for noen lag. Det er imidlertid andre måter å unngå mismatch mellom hva testerne dine tester og hva koderne dine koder. En måte er å bruke mer intelligent testautomatisering som er i stand til å identifisere hvor og når ting har endret seg, både på frontend, men også, viktigere, i backend. Her På Functionize bruker våre tester intelligent fingeravtrykk kombinert med maskinlæring og selvhelbredelse for å redusere testvedlikehold. Dette gjør at testene kan proaktivt tilpasse seg frontend-endringer, samt overvåke ting som serveranrop, responstid og om knapper/funksjoner faktisk er synlige. Dette betyr at testerne ikke vil bli fanget ut av endringer i backend kode eller design / CSS endringer som endrer frontend layout.

vårt intelligente system kan også lage tester ved å overvåke hvordan brukerne samhandler med systemet. Dette bidrar til å sikre at det er færre hull i testdekningen. Et av våre nyeste verktøy lar deg skrive nye tester på vanlig engelsk. Disse analyseres av Vårt Naturlige Språkbehandlingsverktøy og konverteres til brukbare tester. Dette betyr at devs under utvikling bare kan spesifisere hva som må testes ved hjelp av vanlig engelsk, og dermed lukke gapet mellom de to fagområdene ytterligere.

Konklusjoner

Testgapanalyse hjelper deg med å identifisere hvilken kode som blir utgitt, ikke testet, og kan dermed hjelpe deg med å fokusere testressursene dine mer effektivt. Ikke overraskende viser det seg at uprøvd kode er langt mer sannsynlig å inneholde feil, og ethvert verktøy som kan bidra til å sikre at denne koden er riktig testet, er nyttig. MEN SOM VI har sett TGA kan bare supplere eksisterende beste praksis. Det er viktig å holde opp regresjonstesting og utforskende testing. Mange av fordelene MED TGA kan også oppnås ved å bruke intelligente testverktøy. Men generelt er det viktigste å unngå å isolere testlaget ditt fra arbeidet til devs. For å misquote et gammelt ordtak, bør du sørge for at venstre hånd vet hva høyre hånd gjør!