Menu

7 principes van softwaretests: clustering van defecten en het Pareto-principe

  • Hoofd
  • Andere
  • 7 principes van softwaretests: clustering van defecten en het Pareto-principe

7 principles software testing

Probeer Ons Instrument Voor Het Oplossen Van Problemen

Zeven principes van softwaretests: inclusief meer details over het clusteren van gebreken, het Pareto-principe en de paradox van pesticiden.

Ik weet zeker dat iedereen zich bewust is van de ' Zeven principes van softwaretests ​

Deze fundamentele testprincipes helpen de testteams om hun tijd en moeite te gebruiken om het testproces effectief te maken. In dit artikel zullen we in detail leren over twee principes, namelijk Defect Clustering, Pareto-principe en Pesticide Paradox ​

7 principes van softwaretesten

Wat je leert:

Zeven principes van softwaretests

Laten we, voordat we die twee principes uitvoerig bekijken, eerst kort de zeven principes van softwaretesten begrijpen.

Laten we onderzoeken!!

# 1) Testen toont de aanwezigheid van defecten aan

Elke applicatie of elk product wordt in productie genomen na voldoende testen door verschillende teams of doorloopt verschillende fasen, zoals systeemintegratietesten, gebruikersacceptatietesten en bètatesten enz.

Zo heb je ooit gezien of gehoord van een van de testteams dat ze de software volledig hebben getest en dat er geen defect is in de software ​In plaats daarvan bevestigt elk testteam dat de software aan alle zakelijke vereisten voldoet en functioneert volgens de behoeften van de eindgebruiker.

In de softwaretestindustrie zal niemand zeggen dat dat zo is geen defect in de software, wat helemaal waar is, aangezien testen niet kunnen aantonen dat de software foutloos of defect is.

Het doel van testen is echter om steeds meer verborgen defecten te vinden met behulp van verschillende technieken en methoden. Testen kan onontdekte defecten aan het licht brengen en als er geen defecten worden gevonden, betekent dit niet dat de software defectvrij is.

voorbeeld 1 ​

Beschouw een banktoepassing, deze toepassing is grondig getest en ondergaat verschillende testfasen zoals SIT, UAT enz. En momenteel worden er geen defecten in het systeem geïdentificeerd.

Er kan echter een mogelijkheid zijn dat in de productieomgeving de daadwerkelijke klant een functionaliteit probeert die zelden wordt gebruikt in het banksysteem en de testers die functionaliteit over het hoofd hebben gezien, waardoor er tot op heden geen defect is gevonden of de code nooit is aangeraakt door ontwikkelaars .

Voorbeeld 2:

We hebben verschillende advertenties op televisie gezien voor zeep, tandpasta, handwas of desinfecterende sprays enz.

Overweeg een advertentie voor handwas die op de televisie zegt dat 99% ziektekiemen kunnen worden verwijderd als die specifieke handwas wordt gebruikt. Dit bewijst duidelijk dat het product niet 100% kiemvrij is. In ons testconcept kunnen we dus zeggen dat geen enkele software defectvrij is.

# 2) Vroege testen

Testers moeten in een vroeg stadium van de Software Development Life Cycle (SDLC) worden betrokken. Zo kunnen de defecten tijdens de fase van de behoefteanalyse of eventuele documentatiefouten worden geïdentificeerd. De kosten die gemoeid zijn met het herstellen van dergelijke defecten zijn veel lager in vergelijking met die welke worden aangetroffen tijdens de latere testfasen.

Beschouw de onderstaande afbeelding, die laat zien hoe de kosten van het verhelpen van defecten worden verhoogd naarmate het testen dichter bij de live productie komt.

vroeg testen - kosten voor het herstellen van defecten

(beeld bron ​

De bovenstaande afbeelding laat zien dat de kosten die nodig zijn voor het verhelpen van een defect dat tijdens de behoefteanalyse is gevonden, lager zijn en blijven stijgen naarmate we de test- of onderhoudsfase nadert.

Nu is de vraag hoe vroeg moet het testen beginnen ​

Zodra de vereisten zijn afgerond, moeten de testers worden ingeschakeld om te testen. Testen moeten worden uitgevoerd op vereiste documenten, specificatie of elk ander type document, zodat als de vereisten onjuist zijn gedefinieerd, dit onmiddellijk kan worden opgelost in plaats van ze tijdens de ontwikkelingsfase te repareren.

# 3) Uitputtend testen is niet mogelijk

Het is niet mogelijk om tijdens het testen alle functionaliteiten te testen met alle geldige en ongeldige combinaties van invoergegevens. In plaats van deze benadering wordt het testen van enkele combinaties overwogen op basis van prioriteit met behulp van verschillende technieken.

Uitputtende tests zullen onbeperkte inspanningen vergen en de meeste van die inspanningen zijn niet effectief. Ook laten de tijdlijnen van het project het testen van zoveel aantal combinaties niet toe. Daarom wordt aanbevolen om invoergegevens te testen met behulp van verschillende methoden, zoals equivalentiepartitionering en grenswaardeanalyse.

Bijvoorbeeld ​Stel dat we een invoerveld hebben dat alleen alfabetten, speciale tekens en cijfers van 0 tot 1000 accepteert. Stel je voor hoeveel combinaties er zouden verschijnen om te testen, het is niet mogelijk om alle combinaties voor elk invoertype te testen.

De testinspanningen die nodig zijn om te testen, zullen enorm zijn en het zal ook van invloed zijn op de tijdlijn en kosten van het project. Daarom wordt altijd gezegd dat uitgebreide tests praktisch niet mogelijk zijn.

# 4) Testen is contextafhankelijk

Er zijn verschillende domeinen beschikbaar op de markt, zoals bankieren, verzekeringen, medisch, reizen, advertenties enz. En elk domein heeft een aantal toepassingen. Ook voor elk domein hebben hun applicaties verschillende vereisten, functies, verschillende testdoeleinden, risico's, technieken etc.

Verschillende domeinen worden verschillend getest, dus het testen is puur gebaseerd op de context van het domein of de applicatie.

Bijvoorbeeld ​het testen van een bankapplicatie is anders dan het testen van een e-commerce- of advertentietoepassing. Het risico dat aan elk type applicatie is verbonden, is anders, dus het is niet effectief om dezelfde methode, techniek en testtype te gebruiken om alle soorten applicaties te testen.

# 5) Clustering van defecten

Tijdens het testen kan het gebeuren dat de meeste gevonden defecten verband houden met een klein aantal modules. Hiervoor kunnen meerdere redenen zijn, zoals de modules kunnen complex zijn, de codering met betrekking tot dergelijke modules kan ingewikkeld zijn, enz.

Dit is het Pareto-principe van softwaretests waarbij 80% van de problemen in 20% van de modules wordt aangetroffen. We zullen later in dit artikel meer leren over het clusteren van defecten en het Pareto-principe.

# 6) Paradox van pesticiden

Het Pesticide Paradox-principe zegt dat als dezelfde set testcases in de loop van de tijd keer op keer wordt uitgevoerd, deze set tests niet in staat zijn om nieuwe defecten in het systeem te identificeren.

Om deze 'pesticidenparadox' te overwinnen, moet de reeks testcases regelmatig worden herzien en herzien. Indien nodig kan een nieuwe set testcases worden toegevoegd en kunnen de bestaande testcases worden verwijderd als ze geen defecten meer uit het systeem kunnen vinden.

# 7) Afwezigheid van fouten

Als de software volledig is getest en als er geen defecten worden gevonden vóór de release, kunnen we zeggen dat de software 99% defectvrij is. Maar wat als deze software wordt getest op verkeerde vereisten? In dergelijke gevallen zou zelfs het vinden van defecten en het op tijd repareren ervan niet helpen, aangezien het testen wordt uitgevoerd op verkeerde eisen die niet voldoen aan de behoeften van de eindgebruiker.

Bijvoorbeeld, stel dat de toepassing betrekking heeft op een e-commercesite en de vereisten voor de functionaliteit van “Winkelwagen of winkelmandje” die verkeerd geïnterpreteerd en getest is. Hier helpt zelfs het vinden van meer defecten niet om de applicatie naar de volgende fase of in de productieomgeving te brengen.

Dit zijn de zeven principes van softwaretests.

Laten we nu eens kijken Defect Clustering, Pareto Principle en Pesticide Paradox in detail- ​

Defect Clustering

Bij het testen van software komen de testers meestal een situatie tegen waarin de meeste gevonden defecten verband houden met een bepaalde functionaliteit en de rest van de functionaliteiten een lager aantal defecten zal hebben.

Clustering van defecten betekent een klein aantal modules met de meeste defecten. In feite zijn de defecten niet uniform verdeeld over de hele applicatie, maar worden defecten geconcentreerd of gecentraliseerd over twee of drie functionaliteiten.

Soms is het mogelijk vanwege de complexiteit van de applicatie, kan codering complex of lastig zijn, en kan een ontwikkelaar een fout maken die alleen van invloed kan zijn op een specifieke functionaliteit of module.

Defect Clustering is gebaseerd op “ Pareto-principe ”Die ook bekend staat als 80-20 regel ​Dit betekent dat 80% van de gevonden defecten te wijten zijn aan 20% van de modules in de applicatie. Het concept van Pareto-principe werd aanvankelijk gedefinieerd door een Italiaanse econoom - Vilfrodo Pareto ​

Als testers naar 100 defecten kijken, is het niet duidelijk of er een onderliggende betekenis is voor die 100 defecten. Maar als die 100 defecten worden gecategoriseerd op basis van een aantal specifieke criteria, dan kan het voor de testers mogelijk zijn om te begrijpen dat een groot aantal defecten slechts bij een paar specifieke modules horen.

Bijvoorbeeld ​Laten we eens kijken naar de onderstaande afbeelding die is getest voor een van de bankapplicaties en die laat zien dat de meeste defecten verband houden met de 'Overdraft' -functionaliteit. De rest van de functionaliteiten, zoals Accountoverzicht, Overboeking, Doorlopende Instructie etc., hebben een beperkt aantal defecten.

Defect Clustering

(beeld bron ​

Bovenstaande afbeelding geeft aan dat er 18 defecten rond de Overdraft-functionaliteit zijn van de in totaal 32 defecten, wat betekent dat 60% van de defecten wordt aangetroffen in de “Overdraft” -module.

Daarom concentreren testers zich tijdens de uitvoering meestal op dit gebied om steeds meer defecten te vinden. Het wordt aanbevolen dat de testers tijdens het testen een vergelijkbare focus op de andere modules hebben.

Wanneer dezelfde code of module keer op keer wordt getest met een reeks testcases dan tijdens de eerste iteraties, dan is het aantal defecten hoog, maar na enige iteratie zal het aantal defecten aanzienlijk worden verminderd. Defectclustering geeft aan dat het defectgevoelige gebied grondig moet worden getest tijdens regressietesten.

Paradox van pesticiden

Als een van de modules meer defecten blijkt te hebben, doen de testers extra inspanningen om die module te testen.

Na een paar iteraties van testen wordt de kwaliteit van de code verbeterd en begint het aantal defecten af ​​te nemen, aangezien de meeste defecten worden opgelost door het ontwikkelteam, aangezien de ontwikkelaars ook voorzichtig zijn bij het coderen van een bepaalde module waar de testers meer defecten hebben gevonden.

Daarom worden op een gegeven moment de meeste defecten ontdekt en verholpen, zodat er geen nieuwe defecten in die module worden gevonden.

Soms kan het echter gebeuren dat, terwijl u extra voorzichtig bent tijdens het coderen op een bepaalde module (hier in ons geval de “ Rekening-courantkrediet ”Module), kan de ontwikkelaar de andere modules negeren om deze correct te coderen of kunnen de wijzigingen die in die specifieke module worden aangebracht een negatieve invloed hebben op de andere functionaliteiten zoals Accountoverzicht, Overboeking en Doorlopende Instructies.

Wanneer de testers dezelfde set testcases gebruiken om de module uit te voeren waar de meeste defecten zijn gevonden (Overdraft-module), zijn die testcases na het verhelpen van die defecten door de ontwikkelaars niet veel effectief om nieuwe defecten te vinden. Als de end-to-end flow van de Overdraft wordt de module grondig getest en hebben de ontwikkelaars ook de code voor die module voorzichtig geschreven.

Het is noodzakelijk om deze testcases te herzien en bij te werken. Het is ook een goed idee om nieuwe testcases toe te voegen, zodat er nieuwe en meer defecten kunnen worden gevonden in verschillende gebieden van software of applicatie.

Preventieve methoden van pesticidenparadox

Er zijn twee opties waarmee we Pesticide Paradox kunnen voorkomen, zoals hieronder weergegeven:

naar) Schrijf een nieuwe set testcases die zich zullen concentreren op een ander gebied of andere modules (anders dan eerdere defectgevoelige module - Voorbeeld: 'Overdraft') van de software.

b) Bereid nieuwe testcases voor en voeg ze toe aan de bestaande testcases.

In de ' methode A ”, Kunnen testers meer defecten vinden in de andere modules waarop ze niet gefocust waren tijdens de eerdere tests of de ontwikkelaars waren niet extra voorzichtig tijdens het coderen.

In ons bovenstaande voorbeeld kunnen testers meer defecten vinden in de modules Accountoverzicht, Overboeking of Doorlopende instructies met behulp van de nieuwe set testcases.

Maar het kan gebeuren dat de testers de eerdere module ( Voorbeeld: “Overdraft”) waar de meeste defecten werden gevonden in de eerdere iteratie en dit zou een risico kunnen zijn aangezien deze module (Overdraft) mogelijk geïnjecteerd is met de nieuwe defecten na codering van de andere modules.

In de ' methode B ”, Worden nieuwe testcases voorbereid zodat nieuwe potentiële defecten in de rest van de modules kunnen worden gevonden.

Hier in ons voorbeeld kunnen nieuw gemaakte testcases helpen bij het identificeren van defecten in de modules zoals Rekeningoverzicht, Overboeking en Doorlopende instructie. Testers kunnen de eerder defecte modules ( Voorbeeld: “Overdraft”) aangezien deze nieuwe testcases worden samengevoegd met de bestaande testcases.

De bestaande testcases waren meer gericht op de module “Overdraft” en de nieuwe testcases waren gericht op de andere modules. Daarom worden alle testgevallen minstens één keer uitgevoerd, zelfs als er een codewijziging op een module plaatsvindt. Dit zorgt ervoor dat de juiste regressie wordt uitgevoerd en dat het defect kan worden geïdentificeerd als gevolg van deze codewijziging.

Met de tweede benadering wordt het totale aantal testgevallen aanzienlijk hoog, wat resulteert in meer inspanningen en tijd die nodig zijn voor de uitvoering. Dit heeft uiteraard invloed op de projecttijdlijnen en vooral ook op het projectbudget.

Om dit probleem op te lossen, kunnen de overtollige testgevallen worden beoordeeld en vervolgens worden verwijderd. Er zijn veel testcases die onbruikbaar worden na het toevoegen van nieuwe testcases en het aanpassen van de bestaande testcases.

Het is nodig om te controleren welke testgevallen niet zijn geslaagd om de defecten in de laatste 5 iteraties te identificeren (laten we 5 iteraties aannemen) en welke testgevallen niet zo belangrijk zijn. Het kan ook zijn dat de enkele stroom die in een paar testcases wordt gedekt, kan worden afgedekt in een andere end-to-end testcases en die testcases met een enkele flow kunnen worden verwijderd.

Dit zal op zijn beurt het totale aantal testgevallen verminderen.

Bijvoorbeeld ​we hebben 50 testcases voor een bepaalde module en we hebben gezien dat van deze 50 testcases 20 testcases er niet in slaagden een nieuw defect te detecteren in de laatste paar test-iteraties (laten we aannemen dat er 5 iteraties zijn). Dus deze 20 testcases moeten grondig worden beoordeeld en we moeten controleren hoe belangrijk deze testcases zijn, en op basis daarvan kan een beslissing worden genomen om de 20 testcases te behouden of te verwijderen.

Voordat u een testcase verwijdert, moet u controleren of de functionaliteitsstroom die in die testcases wordt gedekt, in een andere testcase wordt gedekt. Dit proces moet voor alle modules worden gevolgd, zodat het totale aantal testgevallen aanzienlijk wordt verminderd. Dit zorgt ervoor dat het totale aantal testgevallen wordt verminderd, maar er is nog steeds 100% dekking van de vereisten.

Het betekent dat alle resterende testcases alle zakelijke vereisten dekken, dus er is geen compromis over kwaliteit.

Gevolgtrekking

Softwaretests zijn een essentiële stap in SDLC omdat het controleert of de software werkt zoals de eindgebruiker nodig heeft of niet.

Testen identificeert zoveel mogelijk defecten. Om tests effectief en efficiënt uit te voeren, moet iedereen zich daarom bewust zijn van en de zeven principes van het testen van software duidelijk begrijpen, en ze staan ​​bekend als de pijlers voor het testen.

De meeste testers hebben deze principes geïmplementeerd en ervaren tijdens het daadwerkelijke testen.

selenium testen interviewvragen en antwoorden

Over het algemeen betekent de term principe de regels of wetten die moeten worden gevolgd. Daarom moet iedereen in de softwaretestindustrie deze zeven principes volgen, en als iemand een van deze principes negeert, kan dit enorme kosten met zich meebrengen voor het project.

Veel leesplezier !!

Aanbevolen literatuur

^