Leestijd : 1 minuten
Manieren om de testdekking te verbeteren
Iedereen heeft misschien wel eens van de beroemde serie “Money Heist” gehoord of gezien. De Protagonist, die zichzelf The Professor noemt, slaagt erin om alle toekomstige gebeurtenissen die zich tijdens zijn missie kunnen voordoen te voorspellen en formuleert ruim voor de overval een plan. De reden voor hem om de overval te plegen, was zijn inzicht in alle mogelijke scenario’s en deze afdekken nog voordat het daadwerkelijke probleem zich voordoet. Zonder een goed begrip van de overval en de bijbehorende gevaren, zou dit een grote negatieve impact hebben gehad. Door dit te doen, was hij in staat om een bepaald aantal taken uit te voeren dat voldoet aan de minimale criteria voor zijn exitstrategie.
Verbind dit nu met de software-industrie. Er wordt een applicatie ontwikkeld en deze is klaar om in de echte wereld te worden ingezet. Het testteam zal de rol van professor op zich nemen om te meten hoeveel van hun applicatie moet worden getest voordat de code wordt vrijgegeven. Metingen worden gebouwd op basis van de vastgestelde vereisten die kunnen worden vergeleken met de verwachte uitkomst van Heist. Door de vereisten te begrijpen, kunnen testgevallen zodanig worden gevormd dat bugs worden geïdentificeerd voordat ze worden vrijgegeven, wat kan worden vergeleken met de negatieve impact van de overval. Deze metingen worden vaak vastgelegd als percentages die kunnen worden vergeleken met de hoeveelheid taak. Door het maximale percentage te dekken, zorgt het team ervoor dat wordt voldaan aan de kwaliteit voor vrijgave die betrekking heeft op de exitstrategie van de overval. Dit definieert uiteindelijk de term testdekking die gerelateerd kan worden aan de overval.
De terminologie Test Coverage verschilt van de daadwerkelijke codedekking zelf. Wij als testteam maken ons meer zorgen over deze benchmark van een softwareproduct. De gehele applicatie wordt als één beschouwd en er worden kwaliteitstesten toegepast.
Test benaderen dekking?
Het belangrijkste om y rekening houdend met de volgende twee factoren:< span class="EOP SCXW253921194 BCX0" data-ccp-props="{"134245418":false,"134245529":false,"201341983":0,"335559739":160,"335559740": 360 }">
Bedrijfstypen:
Als tester zou het belangrijkste doel moeten zijn om voldoende informatie te hebben over alle zakelijke functionaliteiten en hun vereisten. Wat de klant heeft en wat hij/zij van plan was te bereiken speelt de grootste impact bij het formuleren van de testdekking.
Nu de Agile-methodiek een hoge vlucht neemt in het huidige softwaretijdperk, is het voor de QA een absoluut minimumcriterium geworden om op de hoogte te blijven van het huidige bedrijfsproces en regelmatig contact te houden met de eindgebruikers . Of het nu B2B of B2C is, de tester moet kennis nemen van de gebruikerservaring en zich snel aan deze veranderingen kunnen aanpassen en zich in de schoenen van de gebruiker kunnen verplaatsen om effectief een goede hoeveelheid testdekking te bedenken.
Software tools:
De traditionele methode van testdekking met behulp van handmatig testen heeft zijn eigen zegen en vloek. Testautomatisering kan een exponentiële factor zijn die ons de luxe biedt van testdekking op een zodanige manier dat testen elk moment gedaan kunnen worden met minder, soms zelfs zonder menselijke tussenkomst.
Het vinden van de juiste testtool voor de juiste software maakt je werk lichter en bespaart veel tijd. De afgelopen jaren zijn er voor elke doelgroep veel open/betaalde tools op de markt gekomen. Deze tools bieden een breed scala aan functies die zowel de testers als het bedrijf helpen bij kwaliteitsborging. Deze tools voor het testen van software kunnen variëren op basis van de vereisten.
Bij het testen van een webtoepassing is Selenium bijvoorbeeld de beste open-sourcetoepassing die algemeen wordt overwogen. Voor mobiel testen komt Appium om de hoek kijken. Daarnaast zijn er tools zoals Katalon, Cucumber, Tosca, Cypress die de laatste tijd aan populariteit winnen. Het punt dat hier moet worden opgemerkt, is dat deze toolselectie ook afhangt van het projectbudget en de beschikbaarheid van middelen met de juiste vaardigheden.
Door de bovenstaande factoren in overweging te nemen en met mijn ervaring, heb ik een aantal opmerkelijke manieren opgesomd die kunnen worden geïmplementeerd in het testproces en die de potentie hebben om de testdekking te verbeteren.
Verzamelen van vereisten:
Een van de grote nadelen van het real-time scenario is dat het QA-team pas na de ontwikkeling de functionaliteit van de applicatie leert kennen. Dit beperkt de QA om de testdekking te formuleren op basis van de input van ontwikkelaars. Maar idealiter zou het verzamelen van vereisten rechtstreeks van de BA of soms zelfs van de eindgebruikers moeten plaatsvinden om de volledige reikwijdte van de gebruikersverhalen te begrijpen. Door dit te doen, kunnen precieze functionaliteiten worden geconcentreerd voor het testen en de testdekking vergroten zonder extra stappen te schrijven.
Functiebestand:
Met de integratie van het BDD-framework worden de testscenario’s die ooit alleen toegankelijk waren voor het technische team, bekend gemaakt aan alle zakelijke gebruikers. Dit is mogelijk omdat we niet voor een gebruikelijke programmeertaal gaan, maar Gherkin gebruiken, gewone Engels-achtige taal om de testscenario’s over te brengen in de vorm van een feature-bestand.
Deze scenario’s worden vervolgens ter beoordeling gedeeld met de BA/eindgebruikers en op basis van hun feedback kunnen ook aanvullende scenario’s worden opgenomen. Deze beoordeelde functiebestanden kunnen vervolgens worden gebruikt als referentie voor het schrijven van de automatiseringstestgevallen. Zodra deze functies stabiel en geautomatiseerd zijn, kan de regressietestsuite worden uitgevoerd met minimale/geen menselijke tussenkomst.
Parallelle test:
Stel dat we een grote pool van geautomatiseerde cases beschikbaar hebben, en de tijd die nodig is om al die cases dagelijks uit te voeren een punt van zorg wordt, dan kunnen we meerdere thread counts introduceren. Hierdoor kunnen, in plaats van één testcase tegelijk uit te voeren, meerdere testcases parallel worden uitgevoerd, waardoor de algehele uitvoeringstijd effectief wordt verkort en de overtollige tijd wordt gebruikt voor extra testdekking.
Parallel testen kan ook nuttig zijn voor het testen van verschillende browsers door de toepassing te verifiëren via een breed scala aan webbrowsers. Een testsuite die bijvoorbeeld twee minuten zou duren voor 15 browsercombinaties (30 minuten in totaal) kan in slechts 10 minuten worden uitgevoerd als we deze op drie parallellen tegelijk uitvoeren.
CI/CD-pijplijnen:
Automatiseringstools kunnen in de CI/CD-pijplijn worden geïntroduceerd om de menselijke tussenkomst van testen praktisch te elimineren. In plaats van handmatig snapshots te maken en te proberen fout-positieven uit te sluiten, kunnen deze tools helpen bij het maken van screenshots, deze vergelijken met een basislijn en eventuele wijzigingen markeren. De pijplijnen kunnen ook worden geïntegreerd met tools voor defectbeheer om de bugs effectief op te sporen en indien nodig een rode vlag te activeren.
Ongebruikte codes verwijderen:
Gedurende een bepaalde periode in een project kunnen sommige functionaliteiten uit de applicatie zijn verwijderd. De automatiseringscodes die voor die reeks functionaliteiten zijn geschreven, blijven echter nog steeds actief, tenzij ze worden gevonden en verwijderd. Deze dode codes moeten worden verwijderd nadat ervoor is gezorgd dat de functionaliteiten nog steeds blijven werken volgens de zakelijke vereisten. Dit verhoogt de testdekking door de totale omvang van het pakket te verkleinen en ook aanvullende tests te vermijden.
Een productachterstand bijhouden voor automatisering:
Productachterstanden in agile geven ons een overzicht van al het ontwikkelingswerk dat is afgeleid van de zakelijke vereisten. Naast de ontwikkeltaken kunnen er ook automatiseringstestachterstanden worden toegevoegd met medeweten van de producteigenaar. Deze achterstanden moeten zo worden gecreëerd dat alle mogelijke scenario’s als afzonderlijke taken worden behandeld en vervolgens klaar zijn om in de sprint te worden opgepakt.
Het sprintteam kan dan op basis van prioriteit de taken uit de backlogs oppakken en starten met de automatisering. Dit samenwerkingsproces waarbij de producteigenaar en het scrumteam betrokken zijn, vergroot de reikwijdte van precieze scenario’s die worden gedekt, waardoor de weg wordt vrijgemaakt voor verbeterde testdekking door automatisering.
Regressie rond uitgelekte bug:
In het geval van een uitgelekte bug in de productie, is de eerste stap het opnemen van die taken in de automatiseringsproductachterstand. Zorg er vervolgens voor dat deze in de volgende sprint als de taken met hoge prioriteit worden genomen, waardoor de bug op elk moment in de toekomst wordt geëlimineerd. Om de testdekking verder te versterken, is het altijd raadzaam om automatiseringsgevallen rond die gelekte bugs te maken en om de testdekking rond de productiebug verder uit te breiden.
Conclusie:
Het leveren van een product van hoge kwaliteit is de allerbelangrijkste waarde van het QA Consulting-team. Om ervoor te zorgen dat de tests op peil zijn, wordt aangenomen dat een gestructureerde aanpak van de testdekking een belangrijke factor is bij het waarborgen van de kwaliteit van de software.
Ons team bij Zuci maakt maximaal gebruik van deze factoren in de vroege fase van het testplan en ontwerpt de testdekking op een zodanige manier dat deze voldoet aan de zakelijke normen en vergelijkbaar is met de markt. Deze eenvoudige maar effectieve technieken zorgen hoogstwaarschijnlijk voor een verhoogde kwaliteit en een vlottere levering van het product.
We hopen dat je deze blogpost informatief en nuttig vond. Het was een gezamenlijke inspanning, co-auteur met Prithvi Raj
An INFJ personality wielding brevity in speech and writing. Marketer @ Zucisystems.
Deel deze blog, kies uw platform!
gerelateerde berichten
