7 principles software testing
Sju principer för programvarutestning: inklusive mer information om defektkluster, pareto-princip och bekämpningsmedelsparadox.
Jag är säker på att alla är medvetna om Sju principer för programvarutestning ”.
Dessa grundläggande testprinciper hjälper testteamen att utnyttja sin tid och ansträngning för att göra testprocessen effektiv. I den här artikeln lär vi oss i detalj om två principer, dvs. Defektkluster, Pareto-princip och bekämpningsmedelsparadox .
Vad du kommer att lära dig:
- Sju principer för programvarutestning
Sju principer för programvarutestning
Innan vi tar en djupgående titt på dessa två principer, låt oss kort förstå de sju principerna för programvarutestning.
Låt oss utforska !!
# 1) Testning visar närvaron av defekter
Varje applikation eller produkt släpps i produktion efter tillräcklig testning av olika team eller passerar genom olika faser som systemintegrationstestning, användaracceptansprovning och betatestning etc.
Så har du någonsin sett eller hört från något av testteamet att de har testat programvaran helt och att det inte finns något fel i programvaran ? Istället för det bekräftar varje testteam att programvaran uppfyller alla affärskrav och att den fungerar enligt slutanvändarens behov.
Inom mjukvarutestningsindustrin kommer ingen att säga att det finns det ingen defekt i programvaran, vilket är riktigt sant eftersom testning inte kan bevisa att programvaran är felfri eller felfri.
Målet med testningen är dock att hitta fler och mer dolda defekter med olika tekniker och metoder. Testning kan avslöja oupptäckta defekter och om inga fel upptäcks betyder det inte att programvaran är felfri.
Exempel 1 :
Tänk på en bankapplikation, denna applikation testas grundligt och genomgår olika faser av testning som SIT, UAT etc. och för närvarande identifieras inga defekter i systemet.
Det kan emellertid finnas en möjlighet att den faktiska kunden i produktionsmiljön försöker en funktionalitet som sällan används i banksystemet och testarna förbisåg denna funktionalitet, därför hittades ingen defekt hittills eller koden har aldrig berörts av utvecklare .
Exempel 2:
Vi har sett flera annonser för tvål, tandkräm, handtvätt eller desinfektionsmedel etc. på tv.
Tänk på en handtvättannons som säger på TV: n att 99% bakterier kan tas bort om det specifika handtvätten används. Detta visar tydligt att produkten inte är 100% bakteriefri. I vårt testkoncept kan vi alltså säga att ingen programvara är felfri.
# 2) Tidig testning
Testare måste engagera sig i ett tidigt skede av Software Development Life Cycle (SDLC). Således kan bristerna under kravanalysfasen eller eventuella dokumentationsfel identifieras. Kostnaden för att åtgärda sådana defekter är mycket lägre jämfört med de som finns under de senare stadierna av testningen.
Tänk på bilden nedan som visar hur kostnaden för att fixa defekter ökar när testet går mot den levande produktionen.
(bild källa )
Ovanstående bild visar att kostnaden som krävs för att åtgärda en defekt som upptäcktes under kravanalysen är mindre och den fortsätter att öka när vi går mot test- eller underhållsfasen.
Nu är frågan hur tidigt ska testningen börja ?
När kraven har slutförts måste testarna involvera för testning. Testning bör utföras på kravdokument, specifikationer eller någon annan typ av dokument så att om kraven är felaktigt definierade kan det fixas omedelbart snarare än att fixa dem i utvecklingsfasen.
# 3) Uttömmande testning är inte möjligt
Det är inte möjligt att testa alla funktioner med alla giltiga och ogiltiga kombinationer av indata under faktisk testning. Istället för detta tillvägagångssätt anses testning av några kombinationer utifrån prioritet med olika tekniker.
Omfattande testning kräver obegränsade ansträngningar och de flesta av dessa ansträngningar är ineffektiva. Projektets tidslinjer tillåter inte testning av så många antal kombinationer. Därför rekommenderas att testa ingångsdata med olika metoder som Equivalence Partitioning och Boundary Value Analysis.
Till exempel ,Om vi antar att vi har ett inmatningsfält som endast accepterar alfabet, specialtecken och siffror från 0 till 1000. Tänk dig hur många kombinationer som skulle visas för testning, det är inte möjligt att testa alla kombinationer för varje ingångstyp.
De testansträngningar som krävs för att testa kommer att vara enorma och det kommer också att påverka projektets tidslinje och kostnad. Därför sägs det alltid att uttömmande testning praktiskt taget inte är möjligt.
# 4) Testning är beroende av sammanhanget
Det finns flera domäner tillgängliga på marknaden som bank, försäkring, medicinsk, resor, reklam etc. och varje domän har ett antal applikationer. Även för varje domän har deras applikationer olika krav, funktioner, olika teständamål, risk, tekniker etc.
Olika domäner testas annorlunda, så testningen baseras helt på sammanhanget för domänen eller applikationen.
Till exempel ,testa en bankapplikation skiljer sig från att testa någon e-handel eller reklamapplikation. Risken för varje typ av applikation är annorlunda, så det är inte effektivt att använda samma metod, teknik och testtyp för att testa alla typer av applikationer.
# 5) Defektkluster
Under testning kan det hända att de flesta fel som hittats är relaterade till ett litet antal moduler. Det kan finnas flera orsaker till detta eftersom modulerna kan vara komplexa, kodning relaterade till sådana moduler kan vara komplicerad etc.
Detta är Pareto-principen för programvarutestning där 80% av problemen finns i 20% av modulerna. Vi kommer att lära oss mer om defektkluster och Pareto-princip senare i den här artikeln.
# 6) Bekämpningsmedelsparadox
Pesticidparadoxprincipen säger att om samma uppsättning testfall utförs om och om igen under tidsperioden är dessa uppsättningar tester inte tillräckligt kapabla för att identifiera nya defekter i systemet.
För att övervinna denna 'bekämpningsmedelsparadox' måste uppsättningen testfall regelbundet ses över och revideras. Om det behövs kan en ny uppsättning testfall läggas till och befintliga testfall kan tas bort om de inte kan hitta fler defekter från systemet.
# 7) Frånvaro av fel
Om programvaran testas fullständigt och om inga defekter upptäcks före utgivningen kan vi säga att programvaran är 99% felfri. Men tänk om denna programvara testas mot fel krav? I sådana fall skulle det inte hjälpa att hitta fel och åtgärda dem i tid eftersom testning utförs på fel krav som inte är enligt slutanvändarens behov.
Till exempel, antag att applikationen är relaterad till en e-handelswebbplats och kraven på 'Kundvagn eller kundvagn' -funktionalitet som felaktigt tolkas och testas. Här hjälper inte ens att hitta fler defekter att flytta applikationen till nästa fas eller i produktionsmiljön.
Dessa är de sju principerna för programvarutestning.
Låt oss nu utforska Defect Clustering, Pareto Principle and Pesticide Paradox in detalj .
Defektkluster
Under testningen av någon programvara stöter testarna mest på en situation där de flesta av de defekter som hittats är relaterade till viss specifik funktionalitet och resten av funktionerna kommer att ha ett lägre antal defekter.
Defektklustring betyder ett litet antal moduler som innehåller de flesta av defekterna. I grund och botten är defekterna inte fördelade enhetligt över hela applikationen, utan defekter är koncentrerade eller centraliserade över två eller tre funktioner.
Ibland är det möjligt på grund av applikationens komplexitet, kodning kan vara komplex eller knepig, en utvecklare kan göra ett misstag som bara kan påverka en viss funktionalitet eller modul.
Defektkluster bygger på “ Pareto-princip ”Som också kallas 80-20 regel . Det betyder att 80% av de upptäckta bristerna beror på 20% av modulerna i applikationen. Begreppet Pareto Principle definierades ursprungligen av en italiensk ekonom - Vilfrodo Pareto .
Om testare tittar på 100 defekter kommer det inte att vara klart om det finns någon bakomliggande mening mot dessa 100 defekter. Men om de 100 defekterna är kategoriserade på vissa specifika kriterier, kan det vara möjligt för testarna att förstå att ett stort antal defekter bara tillhör ett fåtal specifika moduler.
Till exempel ,låt oss överväga bilden nedan som testas för en av bankapplikationerna och den visar att de flesta av bristerna är relaterade till 'Overdraft' -funktionen. Resten av funktionerna som kontosammanfattning, överföring av pengar, stående instruktioner etc. har begränsat antal defekter.
(bild källa )
Ovanstående bild anger att det finns 18 fel runt Overdraft-funktionaliteten av de totalt 32 defekterna, vilket innebär att 60% av defekterna finns i modulen “Overdraft”.
Därför koncentrerar sig testare mest på detta område under utförandet för att hitta fler och fler defekter. Det rekommenderas att testarna också har liknande fokus på de andra modulerna under testningen.
När samma kod eller modul testas, om och om igen, med hjälp av en uppsättning testfall än under de initiala iterationerna, är antalet defekter höga, men efter en viss iteration minskar antalet defekter avsevärt. Defektkluster indikerar att det defekta området ska testas noggrant under regressionstestning.
Bekämpningsmedelsparadox
När en av modulerna visar sig ha fler defekter, gör testarna ytterligare ansträngningar för att testa den modulen.
Efter några iterationer av test förbättras kodens kvalitet och antalet defekter börjar sjunka eftersom de flesta av defekterna åtgärdas av utvecklingsteamet eftersom utvecklarna också är försiktiga när de kodar en viss modul där testarna hittade fler defekter.
Därför upptäcks och fixas de flesta av defekterna vid ett tillfälle så att inga nya defekter hittas i den modulen.
Ibland kan det dock hända att medan du är extra försiktig vid kodning på en viss modul (här i vårt fall ' Övertrassering ”-Modulen), kan utvecklaren försumma de andra modulerna för att koda den ordentligt eller de ändringar som gjorts i den specifika modulen kan ha en negativ inverkan på andra funktioner som Kontosammanfattning, Överföring av pengar och Stående instruktioner.
När testarna använder samma uppsättning testfall för att utföra modulen där de flesta av defekterna finns (Overdraft-modul), efter att ha fixat dessa defekter av utvecklarna är dessa testfall inte mycket effektiva för att hitta nya defekter. Som slutet på slutet av Overdraft testas modulen noggrant och utvecklarna har också skrivit koden för den modulen försiktigt.
Det är nödvändigt att revidera och uppdatera dessa testfall. Det är också en bra idé att lägga till nya testfall så att nya och fler defekter kan hittas i olika program- eller applikationsområden.
Förebyggande metoder för bekämpningsmedelsparadox
Det finns två alternativ genom vilka vi kan förhindra bekämpningsmedelsparadox enligt nedan:
till) Skriv en ny uppsättning testfall som fokuserar på olika områden eller moduler (annat än tidigare defekt benägen modul - Exempel: ”Overdraft”) av programvaran.
b) Förbered nya testfall och lägg till befintliga testfall.
I ” metod A ”, Kan testare hitta fler defekter i de andra modulerna där de inte var fokuserade under den tidigare testningen eller utvecklarna inte var extra försiktiga under kodningen.
I vårt ovanstående exempel kan testare hitta fler fel i modulerna Kontosammanfattning, Överföring av pengar eller Stående instruktioner med den nya uppsättningen testfall.
Men det kan hända att testarna kan försumma den tidigare modulen ( Exempel: ”Overdraft”) där de flesta defekterna hittades i den tidigare iterationen och detta kan vara en risk eftersom denna modul (Overdraft) kan ha injicerats med de nya defekterna efter kodning av de andra modulerna.
I ” metod B ”, Nya testfall bereds så att nya potentiella defekter kan hittas i resten av modulerna.
Här i vårt exempel kommer nyskapade testfall att kunna hjälpa till att identifiera defekter i modulerna som kontosammanfattning, överföring av pengar och stående instruktion. Testare kan dock inte ignorera de tidigare defektbenägna modulerna ( Exempel: ”Overdraft”) eftersom dessa nya testfall slås samman med befintliga testfall.
De befintliga testfallen fokuserade mer på modulen “Overdraft” och de nya testfallen fokuserade på de andra modulerna. Därför utförs alla uppsättningar testfall minst en gång till och med en kodändring sker på vilken modul som helst. Detta kommer att säkerställa att korrekt regression utförs och defekten kan identifieras på grund av denna kodändring.
Med det andra tillvägagångssättet blir det totala antalet testfall högt betydligt och resulterar i mer ansträngningar och tid som krävs för utförande. Detta kommer uppenbarligen att påverka projektets tidslinjer och viktigast av allt också på projektets budget.
Därför kan de överflödiga testfallet granskas och sedan tas bort för att övervinna detta problem. Det finns många testfall som blir värdelösa efter att ha lagt till nya testfall och modifierat befintliga testfall.
Det är nödvändigt att kontrollera vilka testfall som misslyckats för att identifiera bristerna i de senaste 5 iterationerna (låt oss anta 5 iterationer) och vilka testfall som inte är mycket viktiga. Det kan också vara så att det enda flödet som täcks i ett fåtal testfall kan täckas i ett annat slutfall till slutfall och de testfall som har ett enda flöde kan tas bort.
Detta i sin tur kommer att minska det totala antalet testfall.
Till exempel ,vi har 50 testfall som täcker en viss modul och vi har sett att av dessa 50 testfall misslyckades 20 testfall med att upptäcka en ny defekt under de senaste testeteringarna (låt oss anta 5 iterationer). Så dessa 20 testfall måste granskas noggrant och vi måste kontrollera hur viktiga dessa testfall är och ett beslut kan fattas i enlighet med detta om vi vill behålla de 20 testfallen eller ta bort dem.
Innan du tar bort ett testfall ska du kontrollera att funktionalitetsflödet som omfattas av dessa testfall omfattas av ett annat testfall. Denna process måste följas i alla moduler så att det totala antalet testfall minskas avsevärt. Detta säkerställer att det totala antalet testfall minskas men det finns fortfarande 100% kravtäckning.
Det betyder att alla återstående testfall täcker alla affärsbehov, så det finns ingen kompromiss med kvaliteten.
Slutsats
Programvarutestning är ett viktigt steg i SDLC eftersom det verifierar om programvaran fungerar som per slutanvändare behöver eller inte.
Testning identifierar så mycket defekt som möjligt. För att kunna utföra testning effektivt och effektivt bör alla därför vara medvetna om och förstå de sju principerna för programvarutestning tydligt och de är kända som pelarna för testning.
De flesta testarna har implementerat och upplevt dessa principer under faktisk testning.
metod som tar in en matris
Generellt betyder termen princip de regler eller lagar som måste följas. Därför måste alla i mjukvarutestningsindustrin följa dessa sju principer, och om någon ignorerar någon av dessa principer kan det kosta enormt för projektet.
Glad läsning!!
Rekommenderad läsning
- Bästa verktyg för testning av programvara 2021 (QA Test Automation Tools)
- Programvarutestning QA-assistentjobb
- Programvarutestningskurs: Vilket programvarutestinstitut ska jag gå med?
- Välja programvarutestning som din karriär
- Programvarutestning Tekniskt innehåll Writer Freelancer Jobb
- Vad är testbaserad testteknik?
- Några intressanta programtestintervjufrågor
- Programtestkursfeedback och recensioner