Met behulp van Gap-analyse in het testproces om Devs en Testers

op één lijn te brengen, wordt algemeen aangenomen dat ontwikkelaars en testers met elkaar opschieten als krijt en kaas. Ontwikkelaars kijken vaak neer hun neus op testers, het bekijken van hen als een inflexibele en onbehulpzame slepen op het ontwikkelen van nieuwe code die er niet in slagen om duidelijke details in hun bug tickets. Evenzo, testers vaak zien ontwikkelaars met irritatie voor het niet om hen op de hoogte te houden van code veranderingen en voor het duwen van nieuwe veranderingen tijdens de testcycli. Dit is de reden waarom gap analyse in het QA testproces kan vooral gunstig zijn voor het uitlijnen van zowel devs en testers.

hoewel dit beeld apocrief kan zijn, is het vaak het geval dat ontwikkelaars en testers niet goed communiceren. Vaak gebeurt communicatie alleen via management (projectmanagers en lijnmanagers) of via tickets in Jira. Het resultaat is dat testen vaak onvoldoende blijkt te zijn. In het bijzonder wordt nieuwe code maar al te vaak slecht of helemaal niet getest. Onderzoek heeft aangetoond dat deze ongeteste nieuwe code is de grootste bron van toekomstige bugs en mislukkingen. Dit is waar het concept van Test Gap analyse in het spel komt.

In deze blog zullen we onderzoeken wat Test Gap analyse is, laten zien hoe het kan helpen bij het identificeren van de code die moet worden getest en onderzoeken of deze aanpak het wondermiddel is dat de kloof tussen devs en testers kan overbruggen.

Wat is test Gap analyse?

wanneer u voor het eerst een softwaresysteem ontwikkelt, is het gemakkelijk om er zeker van te zijn dat u het hele systeem test. Testers zijn in staat om de codespecificaties te nemen en een combinatie van geplande en verkennende tests te gebruiken om ervoor te zorgen dat ze elk bewegend deel van de codebase testen. De meeste software is echter niet statisch. Bedrijven maken ofwel monolithische periodieke releases van langlevende code of ze maken gebruik van een bepaald niveau van continue integratie en continue implementatie (CI/CD). In beide gevallen verandert de codebase voortdurend. Maar al te vaak worden de testcases niet in hetzelfde tempo bijgewerkt. Soms weten de testers gewoon niet dat er een code is gewijzigd. Andere keren, de code verandering wordt geduwd net nadat een bepaalde set van tests zijn uitgevoerd. Die tests lijken te zijn geslaagd, maar de code verandering kan ze gebroken hebben.

Test Gap Analysis is het proces van het identificeren van deze hiaten waar nieuwe code is ingevoerd, maar nog niet is getest. Dit vereist een combinatie van statische analyse van alle codewijzigingen en dynamische analyse van alle huidige tests. Door het vergelijken van deze twee analyses, kunt u gemakkelijk zien waar eventuele hiaten zijn. Dat wil zeggen, gebieden met nieuwe code die adequaat zijn getest. Typisch, dit wordt gedaan door het plotten van de code met behulp van een vorm van boomdiagram waar de code is verdeeld in functionele blokken, onder elk blok zijn de samenstellende klassen, onder die zijn de werkelijke methoden en functies. Op elk niveau in de hiërarchie geeft de relatieve grootte van het blok de hoeveelheid code aan. Door de boom met de wijzigingen in de code te overlappen met de boom met de huidige teststatus, is het gemakkelijk om de gebieden te herkennen waar de testdekking ontbreekt.

een boomkaart met ongewijzigde code (grijs), herziene/nieuwe code die is getest (groen), herziene code die niet is getest (oranje) en nieuwe code die niet is getest (rood).

waarom zou Test Gap analyse belangrijk zijn in het testproces?

in een paper uit 2013 voerden onderzoekers van de Technische Universiteit van München een studie uit naar de correlatie tussen nieuwe, niet-geteste code en toekomstige software-bugs. Ze werkten samen met München Re (een grote verzekeringsmaatschappij), monitoring van hun langlevende IT-systeem door middel van 2 releases. Tijdens de release stelden ze vast welke code nieuw was en keken ook naar welke code werd getest en welke code niet werd getest. Daarna, ze bewaakt het systeem voor een lange tijd en bijgehouden alle gerapporteerde bugs terug naar de oorspronkelijke bron. Ze ontdekten twee belangrijke dingen. Ten eerste, ongeveer een derde van alle code werd vrijgegeven ongetest. Ten tweede, toen ze de bugs traceerden ontdekten ze over het algemeen tussen 70 en 80% van alle bugs waren in ongeteste code. De grafiek hieronder toont dit duidelijker.

zoals je kunt zien, de oude geteste code had geen bugs. De nieuwe geteste code had tussen 22 en 30% van de bugs en de resterende bugs werden redelijk gelijkmatig verdeeld tussen nieuwe ongeteste code en oude ongeteste code. Echter, aangezien de nieuwe code slechts 15% van de totale code uitmaakte, kunt u zien dat de nieuwe niet-geteste code een onevenredig groot aantal bugs voor zijn rekening nam.

Test Gap Analysis is ontworpen om deze niet-geteste nieuwe code te identificeren. Het kan u echter ook op andere manieren helpen. Bijvoorbeeld, omdat het controleert wat je test, kan het gebieden van bestaande code identificeren die verouderd zijn (bijvoorbeeld ze worden nog steeds getest, maar worden niet echt aangeroepen door een code). Het kan ook aangeven op welke gebieden u uw testbronnen moet concentreren. Door het regelmatig uit te voeren, kunnen managers de testplanning verbeteren, zich richten op het testen van nieuwe code en proberen om een gelijkmatige testdekking te garanderen.

Devs en Testers uitgelijnd door middel van Test Gap analyse

Test Gap analyse is duidelijk een krachtig concept. Maar het is ook duidelijk dat niet alle teams er evenveel van zullen profiteren. De teams die het meest zullen profiteren zijn degenen die langlevende codebases met periodieke monolithische releases onderhouden. In langlevende codebases werken ontwikkelaars vaak aan code die door andere mensen is geschreven. Testers kunnen vertrouwen op testplannen geproduceerd verschillende versies voor. In combinatie kunnen deze factoren betekenen dat niemand duidelijk is welke code wordt getest of hoe die code samenwerkt met andere delen van het systeem. Hier, TGA kan toestaan dat de testers om precies te zien welke code is veranderd die hen in staat stelt om zich te concentreren op deze. Ze kunnen ook code in het bestaande systeem identificeren die niet is getest.

Teams die CI/CD gebruiken, kunnen ook baat hebben bij deze aanpak, aangezien de testers hierdoor snel precies kunnen vaststellen welke code wordt gewijzigd en zich daarop kunnen concentreren. Het kan ook voorkomen dat het hierboven genoemde probleem waar een stuk code wordt gewijzigd direct nadat het is getest en vervolgens wordt vrijgegeven met de wijzigingen niet getest.

aan de andere kant zullen teams die werken aan nieuwe of kortstondige code minder profiteren, aangezien de meeste code per definitie eerst niet zal worden getest. Hier is het belangrijk om standaard testmethoden te gebruiken om ervoor te zorgen dat uw testen goed is. Het kan echter nuttig zijn voor dergelijke teams om te beginnen met het monitoren van de testdekking met behulp van TGA, omdat dit hen in staat zal stellen toekomstige problemen te voorkomen.

wat zijn de mogelijke problemen?

er zijn enkele problemen met TGA. Een van de grootste heeft betrekking op het feit dat het u niet kan vertellen welke code actief wordt aangeroepen in de codebase. Ontwikkelaars voegen vaak nieuwe code toe ter voorbereiding op toekomstige releases, maar omdat dit inactief is, kan de test suite het niet noemen. Als gevolg hiervan zal deze code altijd verschijnen als nieuwe niet-geteste code. Ook veel grote codebases bevatten blokken oude of verweesde code. Deze moeten periodiek worden opgeruimd, maar opnieuw zullen deze het beeld voor de test Gap analyse verstoren.

een andere belangrijke opmerking is dat het feit dat een stukje code wordt getest, niet uitsluit dat die code ergens anders bugs kan veroorzaken. Sommige van de ergste bugs zijn degenen waar een kleine verandering in een stuk code zorgt ervoor dat een functie of methode om te mislukken in een totaal ongerelateerde code blok. Dus, het is van vitaal belang om te blijven doen zowel verkennende testen en regressie testen. Wat TGA kan doen is Gebieden in uw bestaande codebase identificeren die niet goed worden getest tijdens uw regressietests.

welke andere alternatieven helpen de kloof te overbruggen?

Test Gap analyse is zeker een nuttig instrument voor sommige teams. Er zijn echter andere manieren om een mismatch te voorkomen tussen wat je testers testen en wat je programmeurs coderen. Een manier is om meer intelligente testautomatisering te gebruiken die in staat is om te identificeren waar en wanneer dingen zijn veranderd, zowel op de frontend, maar ook, belangrijker, in de backend. Hier bij Functionize gebruiken onze tests intelligente fingerprinting in combinatie met machine learning en zelfgenezing om testonderhoud te verminderen. Hierdoor kunnen de tests zich proactief aanpassen aan frontend-wijzigingen en kunnen ze dingen controleren zoals serveroproepen, responstijden en of knoppen/functies daadwerkelijk zichtbaar zijn. Dit betekent dat uw testers niet betrapt door wijzigingen in de backend code of ontwerp / CSS wijzigingen die de frontend lay-out te veranderen.

ons intelligente systeem kan ook tests maken door te controleren hoe gebruikers met het systeem omgaan. Dit helpt ervoor te zorgen dat er minder hiaten zijn in de testdekking. Een van onze nieuwste tools kunt u nieuwe tests te schrijven in gewoon Engels. Deze worden ontleed door onze natuurlijke Taalverwerkingstool en omgezet in bruikbare tests. Dit betekent dat tijdens de ontwikkeling, devs kan gewoon specificeren wat moet worden getest met behulp van normaal Engels, waardoor de kloof tussen de twee disciplines verder te sluiten.

conclusies

Test Gap Analysis helpt u te bepalen welke code niet getest wordt vrijgegeven en kan u dus helpen uw testbronnen effectiever te concentreren. Het is niet verwonderlijk dat ongeteste code veel meer kans heeft om bugs te bevatten en dus is elke tool die kan helpen ervoor te zorgen dat deze code goed is getest nuttig. Zoals we echter hebben gezien, kan TGA de bestaande beste praktijken alleen maar aanvullen. Het is van vitaal belang om uw regressie testen en verkennende testen te houden. Veel van de voordelen van TGA kunnen ook worden bereikt door gebruik te maken van intelligente testtools. Maar over het algemeen, het belangrijkste ding om te voorkomen is het isoleren van uw test team van het werk van uw devs. Om een oud gezegde verkeerd te citeren, moet je ervoor zorgen dat de linkerhand weet wat de rechterhand doet!