Articles

Röktestning vs Sanity-testning vs regressionstestning Explained

introduktion

livslängden för en QA-testare anses vara ofullständig om termerna ’Röktestning’, ’Sanity-testning’ och ’regressionstestning’ inte infunderas i den. Även om dessa är några regelbundet använda termer, det finns några vanliga missuppfattningar kring dem också.

innan vi börjar med detaljerna om rök, sanity och regressionstestning och vad de faktiskt menar, kan vi gå igenom några vanliga missuppfattningar och myter kring dem:

  1. Röktestning och Sanitetstestning är desamma och kan användas omväxlande : Detta är inte sant och bör aldrig göras, varför? vi kommer att diskutera det i den här artikeln.
  2. Sanity-testning motsvarar acceptanstestning: Acceptanstestning görs för att säkerställa att byggnaden uppfyller alla krav som kunden angav före utgåvan medan Sanity-testning görs för att säkerställa att produkten är förnuftig, rationell för mer detaljerad testning. Dessa är inte och bör inte användas omväxlande.
  3. Om jag gör Rökprovning kan jag hoppa över sanitetstestning: Röktestning är en mycket hög nivåtestning, som i, denna testning görs för att säkerställa att denna byggnad är lämplig för att påbörja någon annan typ av testning. Till exempel, detta kan bara vara ett test för att säkerställa att bygga installationer och sedan Sanity testning kan börja. Även om röktestfallen ibland körs tillsammans med Sanity testfall, bör dessa inte förväxlas för att vara samma sak.
  4. regressionstestning är inte relaterad till Röktestning eller Sanitetstestning: i teorin är Sanitetstestning en delmängd av regressionstestning. Vissa högprioriterade regressionstestfall utgör vanligtvis sanitetstestfall.
  5. Om jag tänker köra hela regressionstestpaketet-behöver jag inte köra något röktest eller sanitetstest: även om detta kan vara sant i vissa fall, eftersom Sanitetstestning ändå är en delmängd av regressionstestning, är det fortfarande lämpligt att utföra sanitetstestfallen först och sedan följa dem med resten av regressionstestfallen.

i den här artikeln kommer vi att försöka rensa ovanstående förvirringar för en gång för alla.

om du vill läsa mer om manuell testning, se länken här.

Obs: eftersom vi kommer att använda termen ’Software Build’ många gånger i artikeln, låt oss definiera det här. ”Software Build” är en process för att konvertera källkod, till en användarapplikation, efter flera revisioner och kodändringar och skapande av programvara involverar flera processer som ”versionskontroll, kodkvalitet & kompilering” och programvarubyggnad är också resultatet av denna byggprocess. I den här artikeln kommer en byggnad att kallas en testbar version av programvaran.

Röktestning

Röktestning är ett tillvägagångssätt som vanligtvis utförs under de första utvecklingsstadierna i PROGRAMUTVECKLINGSLIVSCYKELN(SDLC) för att se till att kärnfunktionerna i ett program fungerar bra utan problem. Den körs innan några detaljerade funktionstester görs på programvaran.

huvudsyftet med röktestning är inte att utföra djuptestning utan att verifiera att kärnan eller huvudfunktionerna i programmet eller programvaran fungerar bra. Röktestning syftar till att avvisa en dåligt trasig byggnad i början så att testteamet inte slösar bort tid vid installation av & testa programvaran.

Röktestning kallas också som Byggverifieringstest.

Låt oss se ett enkelt exempel där du får ett e-postprogram att testa. De viktiga funktionerna skulle vara att logga in på e-postprogrammet, komponera ett e-postmeddelande och skicka det, eller hur? Och, om e-postmeddelandet inte skickas, gör det någon mening att testa andra funktioner som utkast, raderade meddelanden, arkiv, etc? Detta innebär att du måste släppa byggnaden utan ytterligare validering. Detta kallas Rökprovning.

huvudfokus för röktestning är att testa de kritiska områdena och inte den fullständiga applikationen.

När ska man utföra Röktestning

  • när utvecklare ger en ny byggnad till QA-teamet. En ny byggnad här betyder när byggnaden har nya förändringar gjorda av utvecklarna.
  • när en ny modul läggs till i den befintliga funktionaliteten.

Automation & Rökprovning:

vanligtvis är detta den typ av testning som utförs innan faktiska automatiseringstestfall kan köras. För organisation som har kontinuerlig testning inbyggd, rökprovning motsvarar framgångsrik installation av byggnaden för att köra testfall eller utförande av det första testfallet. Så det här är inte en typ av testning som medvetet automatiseras, men om testautomatisering sätts på plats kan testautomatiseringen bara köras framgångsrikt när programvaran har passerat röktestning. Eller annars kan det första testfallet som körs misslyckas.

Sanity Testing

Sanity testing är en typ av testning som utförs för att kontrollera om en mjukvaruprodukt fungerar korrekt när en ny modul eller funktionalitet implementeras till en befintlig produkt. Sanity testing är en mjukvarutestteknik som gör en snabb utvärdering av kvaliteten på mjukvaruutgåvan för att avgöra om den är berättigad till ytterligare testrundor eller inte.

Sanity-testning utförs vanligtvis efter att ha fått en ganska stabil mjukvarubyggnad eller ibland när en mjukvarubyggnad kan ha genomgått mindre förändringar i koden eller funktionaliteten. Den beslutar om Slutprovning av en mjukvaruprodukt ska utföras ytterligare eller inte.

Sanity testing är också en Ytnivåtestning som hjälper till att avgöra om programvarubyggnaden är tillräckligt bra för att skicka den till nästa testnivå.

varför utföra sanity-testning

  • för att verifiera och validera överensstämmelsen med Nyligen tillagda funktioner och funktioner i befintlig kod.
  • för att säkerställa att de införda ändringarna inte påverkar andra befintliga funktioner i produkten.
  • för att bestämma ytterligare tester kan föras vidare eller inte.

När ska man utföra Sanitetstestning

  • Build tas emot efter många regressioner eller om det finns en mindre förändring i koden.
  • byggnaden tas emot efter buggfixning.
  • strax före utbyggnaden på produktionen.

Automation & Sanity Testing:

Med tanke på att Sanity Testing betraktas som en delmängd av regressionstestning, det här är testfall som kan automatiseras. Ett rekommenderat tillvägagångssätt är att utföra dessa testfall innan du kör hela regressionstestpaketet. Fördelen är att om det finns några fel i sanity testfall, då fel kan rapporteras förr snarare än senare.

regressionstestning

regressionstestning är verifieringen av ”buggfixar eller eventuella ändringar i kravet” och se till att de inte påverkar andra funktioner i applikationen. Regressionstestning är effektiv på automatisering och utförs vanligtvis efter att vissa ändringar har gjorts i programvarubyggnaden efter kravändringar eller buggfixar.

När sanity testning av den ändrade funktionaliteten är klar, alla påverkade funktioner i programmet kräver fullständig testning. Detta kallas regressionstestning.

När buggfixar görs i den befintliga programvaran måste vissa testscenarier utföras för att verifiera buggfixarna. Utöver dessa måste QA-teamet också kontrollera de drabbade områdena, baserat på kodändringarna. Vid regressionstestning måste alla dessa testscenarier utföras för att ta hand om relaterade funktioner.

När ska man utföra regressionstestning

  • efter kodändring enligt de nödvändiga ändringarna
  • efter att några nya funktioner har lagts till i applikationen
  • efter att några buggfixar har införlivats i build

Automation& regressionstestning:

Regressionstestfall är faktiskt de perfekta testfallen för automat. Vanligtvis, när en organisation startar automatisering, är det testfall som automatiseras först. Om regressionstestning är en aktivitet som tar mycket tid för dina testare och samma testfall upprepas flera gånger är det dags att du börjar tänka på automatisering också.

Om du letar efter ett verktyg som kan hjälpa dig att komma igång med din automatiseringsresa måste du också se till att du väljer rätt verktyg. Ett verktyg som också kan ge dig ROI på de ansträngningar som investerats. Vi har guiden som kan hjälpa dig där:

10 Points to Help You Choose the Right Test Automation Tool

Differences Between Smoke vs Sanity vs Regression Testing

Smoke Testing Sanity Testing Regression Testing
Performed on initial builds Performed on stable builds Performed on stable builds
To test the stability of new build för att testa stabiliteten hos ny funktionalitet eller kodändringar i befintlig build för att testa funktionaliteten för alla drabbade områden efter ny funktionalitet/kodändringar i befintlig build
täcker end to end grundläggande funktioner täcker vissa moduler, där kodändringar har gjorts täcker detaljerad testning riktad mot alla drabbade områden efter att nya funktioner har lagts till
exekveras av testare & ibland även av utvecklare exekveras av testare exekveras av testare, mestadels via automation
en del av grundläggande testning en del av regressionstestning regressionstestning är en super uppsättning rök-och sanitetstester
görs vanligtvis varje gång det finns en ny build planerad när det inte finns tillräckligt tid för djupgående testning vanligtvis utförs, när testare har tillräckligt med tid

nyckelpunkter

  • rök-och sanitetstestning hjälper QA-teamet att spara tid genom att snabbt testa för att se till om ett program fungerar korrekt eller inte. Det säkerställer också att produkten är berättigad till ytterligare testning. Medan regressionstestning hjälper till att förbättra förtroendet för programvarukvaliteten efter en viss förändring. Särskilt att kodändringarna inte påverkar relaterade områden.
  • Röktestning görs av både dev-teamet eller av QA-teamet och kan tas som en delmängd av rigorösa tester. Medan båda Sanity & regressionstestning görs endast av QA-teamet. Sanitetstestning kan också betraktas som en delmängd av acceptanstestning.
  • Röktestning utförs i det inledande skedet av SDLC, för att kontrollera kärnfunktionerna i en applikation. Medan Sanity & regressionstestning görs i slutskedet av SDLC, för att kontrollera huvudfunktionerna i en applikation.
  • enligt kravet på testning & tidstillgänglighet kan QA-teamet behöva utföra Sanity, rök & regressionstester på deras programvarubyggnad. I sådana fall utförs Röktester först, följt av Sanitetstestning& sedan baserat på tid tillgänglighet regressionstestning planeras.

i praktiken måste alla QA-team göra rök -, sanitets-och regressionstestning. Alla dessa testtyper har ett fördefinierat antal testfall som körs flera gånger. Detta repetitiva utförande gör dem också till en idealisk kandidat för testautomatisering. När du letar efter automatisering rekommenderas du att använda ett verktyg som ger dig ROI på automatisering från början. Testsigma är ett sådant verktyg.

Välj ett verktyg som låter dig automatisera från dag 1