Rökprovning mot sanitetstest: Skillnad med exempel

smoke testing vs sanity testing

Utforska skillnaderna mellan rökprovning och sanitetsprovning i detalj med exempel:

I den här handledningen lär vi oss vad som är Sanity Testing och Smoke Testing in Software Testing. Vi kommer också att lära oss de viktigaste skillnaderna mellan Sanity och Smoke testing med enkla exempel.

De flesta gånger blir vi förvirrade mellan innebörden av Sanity Testing och Smoke Testing. Först och främst är dessa två testningar vägen ” annorlunda ”Och utförs under olika steg i en testcykel.

Vad du kommer att lära dig:

• Sanity Testing
• Min erfarenhet
• Sanity Testing Vs Regression Testing
• Strategi för mobilapptestning
• Säkerhetsåtgärder
• Rökprovning
• Exempel på rökprovning
  • # 1) Godkännande testning
  • # 2) Integrationstestning
  • # 3) Systemtestning
• Betydelse i SCRUM-metodik
• Rökprov mot byggtestningstest
• Röktestcykel
• Vem ska utföra rökprovet?
• Varför ska vi automatisera rökprov?
• Fördelar och nackdelar
• Skillnaden mellan rök och sanitetstest
  • RÖKTESTNING
  • SANITY TESTING
• Rekommenderad läsning

Sanity Testing

Sanity Testing görs när vi som QA inte har tillräckligt med tid för att köra alla testfall, vare sig det är Funktionell testning , UI, OS eller Browser Testing.

Därför skulle jag definiera,

'Sanity Testing som ett testkörning som görs för att beröra varje implementering och dess inverkan men inte noggrant eller djupgående. Det kan inkludera funktionstestning, användargränssnitt, version osv. Beroende på implementering och dess inverkan.'

Kommer vi inte alla i en situation när vi måste logga ut om en dag eller två men byggnaden för testning fortfarande inte släpps?

hur man öppnar dat-filen i pdf

Ah ja, jag slår vad om att du också måste ha mött den här situationen minst en gång i din programvarutestning. Jag stod inför det mycket för att mina projekt var mest smidiga och ibland ombads vi att leverera det samma dag. Oj, hur kunde jag testa och släppa byggnaden inom några timmar?

Jag brukade bli nötter ibland för att även om det var en liten funktionalitet, kunde implikationen vara enorm. Och som en pricken över i, vägrar kunder ibland helt enkelt att ge extra tid. Hur kunde jag slutföra hela testet på några timmar, verifiera alla funktioner, Fel och släppa det?

Svaret på alla sådana problem var väldigt enkelt, dvs ingenting annat än att använda Sanity Testing-strategi.

När vi testar en modul eller funktion eller ett komplett system, Testa fall för utförande väljs så att de kommer att röra vid alla viktiga bitar och bitar av samma dvs breda men grunda testning.

Ibland görs testningen till och med slumpmässigt utan testfall. Men kom ihåg, Förnuftstest bör endast göras när du har kort tid, använd aldrig detta för dina vanliga utgåvor. Teoretiskt är denna testning en delmängd av Regressionstestning .

Min erfarenhet

Under mina 8+ års karriär inom Software Testing arbetade jag i 3 år Agil metod y och det var då jag mest använde ett sanity test.

Alla stora utgåvor planerades och genomfördes på ett systematiskt sätt men ibland ombads små utgåvor att levereras så snart som möjligt. Vi fick inte mycket tid att dokumentera testfallet, exekvera, göra feldokumentationen, göra regressionen och följa hela processen.

Följaktligen är några av de viktigaste tipsen som jag brukade följa under sådana situationer:

# 1) Sitt med chefen och dev-teamet när de diskuterar implementeringen eftersom de måste arbeta snabbt och därför kan vi inte förvänta oss att de förklarar oss separat.

Detta skulle också hjälpa dig att få en uppfattning om vad de ska genomföra, vilket område kommer det att påverka etc., detta är en mycket viktig sak att göra eftersom vi ibland helt enkelt inte inser konsekvenserna och om någon befintlig funktionalitet kommer att hämmas (i värsta fall).

#två) Eftersom du har kort tid, när utvecklingsgruppen arbetar med implementeringen, kan du notera testfallet ungefär i verktyg som Evernote etc. Men se till att du skriver dem någonstans så att du kan lägga till dem senare till testfallet.

# 3) Håll din testbädd redo enligt implementeringen och om du känner att det finns några röda flaggor som någon specifik dataskapande om en testbädd tar tid (och det är ett viktigt test för släppet), höj sedan flaggorna omedelbart och informera din chef eller PO om spärren.

Bara för att klienten vill så fort betyder det inte att en QA kommer att släppas även om den är halvtestad.

# 4) Gör en överenskommelse med ditt team och chef om att du på grund av tidsbesvär endast kommer att kommunicera buggarna till utvecklingsteamet och den formella processen att lägga till, markera buggarna för olika steg i bugspårningsverktyget kommer att göras senare för att spara tid .

# 5) När utvecklingsteamet testar i slutet, försök att para ihop dem (kallas dev-QA-parning) och gör en grundläggande omgång i själva installationen, detta kommer att hjälpa till att undvika fram och tillbaka om byggnaden misslyckas .

# 6) Nu när du har byggt testar du först affärsreglerna och alla användningsfall. Du kan behålla tester som en validering av ett fält, navigering etc. för senare.

# 7) Oavsett fel du hittar, anteckna dem alla och försök att rapportera dem tillsammans till utvecklarna snarare än att rapportera individuellt eftersom det blir lätt för dem att arbeta på en massa.

# 8) Om du har ett krav på övergripande Prestandatester eller stress- eller belastningstestning, se till att du har en ordentlig automatiseringsram för samma. Eftersom det är nästan omöjligt att manuellt testa dessa med ett sanity test.

# 9) Detta är den viktigaste delen, och faktiskt det sista steget i din förnuftsteststrategi - “När du utarbetar släppmeddelandet eller dokumentet, nämn alla testfall som du utförde, buggarna hittades med en statusmarkör och om något var kvar okontrollerat nämna det med skälen ' Försök att skriva en skarp historia om din testning som kommer att förmedla alla om vad som har testats, verifierats och vad som inte har varit.

Jag följde detta religiöst när jag använde denna testning.

Låt mig berätta om min egen erfarenhet:

# 1) Vi arbetade på en webbplats och det brukade dyka upp annonser baserat på nyckelorden. Annonsörerna brukade lägga bud för vissa nyckelord som hade en skärm utformad för samma. Standardbudvärdet visades tidigare som $ 0,25, vilket budgivaren till och med kunde ändra.

Det fanns ytterligare ett ställe där detta standardbud brukade visas och det kunde också ändras till ett annat värde. Klienten kom med en begäran om att ändra standardvärdet från $ 0,25 till $ 0,5 men han nämnde bara den uppenbara skärmen.

Under vår brainstormingsdiskussion glömde vi (?) Den här andra skärmen eftersom den inte användes mycket för det ändamålet. Men när jag testade när jag körde det grundläggande fallet om att budet var $ 0,5 och kontrolleras från början till slut, fann jag att cronjobben för detsamma misslyckades eftersom det på ett ställe var att hitta $ 0,25.

Jag rapporterade detta till mitt team och vi gjorde ändringen och levererade den framgångsrikt samma dag själv.

#två) Under samma projekt (nämnts ovan) ombads vi att lägga till ett litet textfält för anteckningar / kommentarer för budgivning. Det var en mycket enkel implementering och vi åtagit oss att leverera samma dag.

Så som nämnts ovan testade jag alla affärsregler och använde fall runt det och när jag gjorde några valideringstester fann jag att när jag skrev in en kombination av specialtecken som att sidan kraschade.

Vi tänkte över det och tänkte att de faktiska anbudsgivarna i alla fall inte kommer att använda sådana kombinationer. Därför släppte vi den med en väl utformad anteckning om frågan. Klienten accepterade det som ett fel men gick med på att implementera det senare eftersom det var ett allvarligt fel men inte ett tidigare.

# 3) Nyligen arbetade jag med ett mobilappsprojekt, och vi hade ett krav på att uppdatera leveranstid som visas i appen enligt tidszonen. Det var inte bara att testa i appen utan också för webbtjänsten.

Medan utvecklingsgruppen arbetade med implementeringen skapade jag automatiseringsskript för webbtjänsttestning och DB-skript för att ändra tidszonen för leveransvaran. Detta räddade mina ansträngningar och vi kunde uppnå bättre resultat inom kort tid.

Sanity Testing Vs Regression Testing

Nedan följer några skillnader mellan de två:

Strategi för mobilapptestning

Du måste undra varför jag nämner specifikt om mobilappar här?

Anledningen är att OS och webbläsarversion för webb- eller stationära appar inte varierar mycket och särskilt skärmstorlekarna är standard. Men med mobilappar påverkar skärmstorleken, mobilnätverket, OS-versionerna etc stabiliteten, utseendet och kort sagt framgången för din mobilapp.

Därför blir en strategiformulering kritisk när du utför denna testning på en mobilapp eftersom ett misslyckande kan leda till stora problem. Testningen måste göras smart och med försiktighet också.

Nedan följer några tips som hjälper dig att utföra denna testning framgångsrikt i en 'mobilapp':

# 1) Först och främst, analysera OS-versionens inverkan på implementeringen med ditt team.

Försök hitta svar på frågor som, kommer beteendet att vara annorlunda mellan olika versioner? Fungerar implementeringen på den lägsta versionen som stöds eller inte? Kommer det att finnas prestandafrågor för implementering av versioner? Finns det något specifikt inslag i operativsystemet som kan påverka genomförandets beteende? etc.

#två) På ovanstående anmärkning, analysera för telefonmodeller också dvs finns det några funktioner i telefonen som kommer att påverka implementeringen? Är implementeringen av beteendeförändring med GPS? Ändras implementeringsbeteendet med telefonens kamera? etc. Om du upptäcker att det inte påverkas, undvik att testa på olika telefonmodeller.

# 3) Om det inte finns några användargränssnittsändringar för implementeringen rekommenderar jag att du håller UI-testningen på minst prioritet, du kan informera teamet (om du vill) att UI inte kommer att testas.

# 4) För att spara tid, undvik att testa på bra nätverk eftersom det är uppenbart att implementeringen kommer att fungera som förväntat på ett starkt nätverk. Jag rekommenderar att du börjar testa i ett 4G- eller 3G-nätverk.

# 5) Denna testning ska göras på kortare tid men se till att du gör minst ett fältprov såvida det inte bara är en ändring av användargränssnittet.

# 6) Om du måste testa en matris med olika operativsystem och deras version, föreslår jag att du gör det på ett smart sätt. Välj till exempel de lägsta, medelstora och senaste OS-versionen för testning. Du kan nämna i släppdokumentet att inte alla kombinationer testas.

# 7) På en liknande linje, för UI-implementering, kan du använda små, medelstora och stora skärmstorlekar för att spara tid. Du kan också använda en simulator och emulator.

Säkerhetsåtgärder

Sanity Testing utförs när du har kort tid och därför är det inte möjligt för dig att köra varje testfall och viktigast av allt får du inte tillräckligt med tid för att planera din testning. För att undvika skulden spel är det bättre att vidta försiktighetsåtgärder.

I sådana fall är brist på skriftlig kommunikation, testdokumentation och missningar ganska vanliga.

För att säkerställa att du inte blir offer för detta, se till att:

• Acceptera aldrig en version för testning förrän du inte får ett skriftligt krav som delas av klienten. Det händer att klienter kommunicerar förändringar eller nya implementeringar muntligt eller i chatt eller en enkel 1 liner i ett e-postmeddelande och förväntar oss att vi behandlar det som ett krav. Tvinga din klient att tillhandahålla några grundläggande funktionalitetspoäng och acceptanskriterier.
• Gör alltid grova anteckningar om dina testfall och buggar om du inte har tillräckligt med tid för att skriva dem snyggt. Lämna aldrig dessa papperslösa. Om det är lite tid, dela den med din ledare eller ditt team så att om något saknas kan de enkelt påpeka det.
• Om du och ditt team har kort tid, se till att buggarna är markerade i lämpligt tillstånd i ett e-postmeddelande? Du kan skicka den fullständiga listan med buggar till teamet och få utvecklarna att markera dem på rätt sätt. Håll alltid bollen i den andras domstol.
• Om du har Automationsramverk redo, använd det och undvik att göra Manuell testning , på så sätt på kortare tid kan du täcka mer.
• Undvik scenariot 'släpp om 1 timme' om du inte är 100% säker på att du kommer att kunna leverera.
• Sist men inte minst, som nämnts ovan, utarbeta ett detaljerat släppmeddelande som meddelar vad som testas, vad som är utelämnat, skäl, risker, vilka buggar som löses, vad som är 'Latered' etc.

Som en kvalitetsbedömning bör du bedöma vad som är den viktigaste delen av implementeringen som behöver testas och vilka delar som kan utelämnas eller grundtestas.

regex_match c ++

Planera en strategi om hur du vill göra på kort tid och du kommer att kunna uppnå det bästa inom den angivna tidsramen.

Rökprovning

Röktestning är inte uttömmande testning, men det är en grupp tester som utförs för att verifiera om de grundläggande funktionerna för den specifika byggnaden fungerar som förväntat eller inte. Detta är och bör alltid vara det första testet som görs på någon ”ny” byggnad.

När utvecklingsteamet släpper en byggnad till QA för testning är det uppenbarligen inte möjligt att testa hela byggnaden och verifiera omedelbart om någon av implementeringarna har fel eller om någon av arbetsfunktionerna är trasiga.

Mot bakgrund av detta, hur kommer en kvalitetssäkring att se till att de grundläggande funktionerna fungerar bra?

Svaret på detta blir att utföra en Rökprovning .

När testerna är markerade som rökprov (i testpaketet) godkänns först byggnaden av QA för djupgående tester och / eller regression. Om någon av röktesterna misslyckas avvisas byggnaden och utvecklingsteamet måste åtgärda problemet och släppa en ny version för testning.

Teoretiskt definieras rökprovet som testning på ytnivå för att intyga att byggnaden som tillhandahålls av utvecklingsteamet till QA-teamet är redo för ytterligare testning. Denna testning utförs också av utvecklingsteamet innan byggnaden släpps till QA-teamet.

Denna testning används vanligtvis vid integrationstestning, systemtestning och acceptansnivåtestning. Behandla aldrig detta som en ersättning för det faktiska slutet för att avsluta fullständig testning . Den består av både positiva och negativa tester beroende på byggimplementeringen.

Exempel på rökprovning

Denna testning används normalt för integration, acceptans och Systemtestning .

Under min karriär som QA accepterade jag alltid en byggnad först efter att jag hade utfört ett rökprov. Så, låt oss förstå vad som är ett röktest ur alla dessa tre testperspektiv, med några exempel.

# 1) Godkännande testning

När en byggnad släpps till QA, ska rökprov i form av en Acceptantestning borde vara klart.

I det här testet är det första och viktigaste rökprovet att verifiera den grundläggande förväntade funktionaliteten i implementeringen. Så här bör du verifiera alla implementeringar för just den versionen.

Låt oss ta följande exempel som implementeringar gjorda i en byggnad för att förstå rökprov för dem:

• Implementerade inloggningsfunktionen så att de registrerade drivrutinerna kunde logga in framgångsrikt.
• Implementerade instrumentpanelfunktionen för att visa de rutter som en förare ska utföra idag.
• Implementerade funktionaliteten för att visa ett lämpligt meddelande om det inte finns några rutter för en viss dag.

I ovanstående version, på acceptansnivån, innebär rökprovet att verifiera att de tre grundläggande implementeringarna fungerar bra. Om någon av dessa tre är trasig ska QA avvisa byggnaden.

# 2) Integrationstestning

Denna testning görs vanligtvis när de enskilda modulerna implementeras och testas. I Integrationstestning nivå utförs denna testning för att säkerställa att alla grundläggande integrationer och funktionerna från slut till slut fungerar som förväntat.

Det kan vara integrationen av två moduler eller alla moduler tillsammans, följaktligen kommer rökprovets komplexitet att variera beroende på integrationsnivån.

Låt oss överväga följande exempel på integrationsimplementering för denna testning:

• Implementerade integrationen av rutt- och stoppmoduler.
• Implementerade integrationen av ankomststatusuppdatering och återspeglar detsamma på stoppskärmen.
• Implementerade integrationen av kompletta moduler för leveransfunktion.

I den här versionen kommer röktestet inte bara att verifiera dessa tre grundläggande implementeringar utan för den tredje implementeringen kommer några fall också att verifieras för fullständig integration. Det hjälper mycket att ta reda på de frågor som introduceras i integrationen och de som gick obemärkt av utvecklingsteamet.

# 3) Systemtestning

Som namnet själv antyder inkluderar rökprovningen för systemnivå test för de viktigaste och mest använda arbetsflödena i systemet. Detta görs först efter att hela systemet är klart och testat, och denna testning för systemnivå kan också kallas rökprovning före regressionstest.

Innan regressionen av hela systemet startas testas de grundläggande funktionerna från slut till slut som en del av rökprovet. Röktestpaketet för hela systemet består av slut-till-slut-fall som slutanvändarna kommer att använda mycket ofta.

Detta görs vanligtvis med hjälp av automatiseringsverktyg.

Betydelse i SCRUM-metodik

Numera följer projekten knappast Waterfall-metoden i projektimplementeringen, mestadels följer alla projekten Agile och KLUNGA endast. Jämfört med den traditionella vattenfallsmetoden har Smoke Testing höga hälsningar i SCRUM och Agile.

Jag arbetade 4 år i SCRUM . Och som vi vet att i SCRUM har sprintarna kortare varaktighet och därför är det av yttersta vikt att göra denna testning, så att de misslyckade byggnaderna omedelbart kan rapporteras till utvecklingsteamet och fixas också.

Följande är några hämtmat om vikten av denna testning i SCRUM:

• Från sprinten var fjorton dagar tilldelas halvtid QA men ibland försenas byggnaderna till QA.
• I sprints är det bäst för teamet att problemen rapporteras i ett tidigt skede.
• Varje berättelse har en uppsättning acceptanskriterier, varför testning av de första 2-3 acceptanskriterierna är lika med rökprovning av den funktionen. Kunder avvisar leveransen om ett enda kriterium inte fungerar.
• Föreställ dig vad som kommer att hända om det är två dagar som utvecklingsteamet levererade dig byggnaden och bara 3 dagar återstår för demo och du stöter på ett grundläggande funktionsfel.
• I genomsnitt har en sprint berättelser som sträcker sig från 5-10. Därför är det viktigt att se till att varje berättelse implementeras som förväntat innan man accepterar att bygga testet.
• När hela systemet ska testas och regresseras tillägnas en sprint till aktiviteten. Två veckor kanske lite mindre för att testa hela systemet, därför är det mycket viktigt att verifiera de mest grundläggande funktionerna innan regressionen påbörjas.

Rökprov mot byggtestningstest

Rökprovning är direkt relaterad till Build Acceptance Testing (BAT).

I BAT gör vi samma test - för att verifiera om build inte har misslyckats och att systemet fungerar bra eller inte. Ibland händer det att när en build skapas, introduceras vissa problem och när den levereras fungerar inte build för QA.

Jag skulle säga att BAT är en del av en rökkontroll, för om systemet misslyckas, hur kan du som QA acceptera byggnaden för testning? Inte bara funktionerna, själva systemet måste fungera innan QA: s fortsätter med djupgående testning.

Röktestcykel

Följande flödesschema förklarar Smoke Testing Cycle.

När en byggnad har distribuerats till en QA är den grundläggande cykeln som följs att om rökprovet godkänns accepteras byggnaden av QA-teamet för ytterligare testning, men om den misslyckas avvisas byggnaden tills de rapporterade problemen har åtgärdats.

Testcykel

Vem ska utföra rökprovet?

Inte hela teamet är inblandat i denna typ av testning för att undvika slöseri med tid för alla QA: er.

Smoke Testing utförs idealiskt av QA-ledaren som bestämmer utifrån resultatet om huruvida de ska skicka byggnaden till teamet för vidare testning eller avvisa det. Eller i avsaknad av ledningen kan QA: erna själva också utföra denna testning.

Ibland, när projektet är i stor skala, kan en grupp QA också utföra denna testning för att kontrollera om det finns utställare. Men det är inte så i fallet med SCRUM eftersom SCRUM är en platt struktur utan Leads eller Managers och varje testare har sitt eget ansvar gentemot sina berättelser.

Därför utför enskilda kvalitetsbedömningar denna testning för de berättelser de äger.

Varför ska vi automatisera rökprov?

Denna testning är det första testet som görs på en version som utvecklats av utvecklingsteamet. Baserat på resultaten av denna testning görs ytterligare testning (eller build avvisas).

Det bästa sättet att göra denna testning är att använda ett automatiseringsverktyg och schemalägga att röksviten ska köras när en ny version skapas. Du kanske tänker på varför ska jag “Automatisera rökprovningen”?

Låt oss titta på följande fall:

Låt oss säga att du är en vecka kvar från ditt släpp och av de totalt 500 testfallen består din rökprovsvit av 80-90. Om du börjar köra alla dessa 80-90 testfall manuellt, föreställ dig hur mycket tid du kommer att ta? Jag tror 4-5 dagar (minimum).

Men om du använder automatisering och skapar skript för att köra alla dessa 80-90 testfall, kommer de helst att köras på 2-3 timmar och du kommer att få resultaten med dig direkt. Sparade det inte din dyrbara tid och gav dig resultaten om inbyggnaden mycket mindre tid?

För fem år sedan testade jag en app för finansiell projektion, som tog insatser om din lön, sparande etc. och beräknade dina skatter, besparingar, vinster beroende på de finansiella reglerna. Tillsammans med detta hade vi anpassning för länder som är beroende av landet och dess skatteregler som används för att ändra (i koden).

För det här projektet hade jag 800 testfall och 250 rökfall. Med användning av selen kunde vi enkelt automatisera och få resultaten av dessa 250 testfall på 3-4 timmar. Det sparade inte bara vår tid utan visade oss ASAP om showstoppers.

Därför, om det inte är omöjligt att automatisera, ta hjälp av automatisering för denna testning.

Fördelar och nackdelar

Låt oss först ta en titt på fördelarna eftersom det har mycket att erbjuda jämfört med de få nackdelarna.

Fördelar:

• Lätt att utföra.
• Minskar risken.
• Fel identifierades i ett mycket tidigt skede.
• Sparar ansträngningar, tid och pengar.
• Körs snabbt om det är automatiserat.
• Minst integrationsrisker och problem.
• Förbättrar systemets övergripande kvalitet.

Nackdelar:

• Denna testning är inte lika med eller ersätter fullständig funktionell testning.
• Även efter att röktestet passerat kan du hitta showstopper-buggar.
• Denna typ av testning är bäst lämplig om du kan automatisera annat mycket tid ägnas åt manuell utförande av testfall, särskilt i storskaliga projekt som har cirka 700-800 testfall.

Rökprovning bör definitivt göras i varje byggnad eftersom det påpekar de stora misslyckandena och showstopparna i ett mycket tidigt skede. Detta gäller inte bara nya funktioner utan även integrering av moduler, fixering av problem och improvisation. Det är en mycket enkel process att utföra och få rätt resultat.

Denna testning kan behandlas som ingångspunkt för fullständig funktionstestning av funktionalitet eller system (som helhet). Men innan det, QA-teamet bör vara mycket tydligt om vilka tester som ska göras som rökprov . Denna testning kan minimera ansträngningarna, spara tid och förbättra systemets kvalitet. Det har en mycket viktig plats i sprints eftersom tiden i sprints är mindre.

Denna testning kan göras både manuellt och även med hjälp av automatiseringsverktyg. Men det bästa och bästa sättet är att använda automatiseringsverktyg för att spara tid.

Skillnaden mellan rök och sanitetstest

De flesta gånger blir vi förvirrade mellan innebörden av Sanity Testing och Smoke Testing. Först och främst är dessa två testningar vägen ” annorlunda ”Och utförs under olika stadier av en testcykel.

Följande är en schematisk framställning av deras skillnader:

RÖKTESTNING

• Denna testning har sitt ursprung i hårdvara testa praxis att sätta på en ny maskinvara för första gången och betrakta den som en framgång om den inte tar eld och röker. I programvaruindustrin är denna testning ett grunt och brett tillvägagångssätt där alla applikationsområden testas utan att hamna för djupt.
• Ett röktest är skriptat, antingen med hjälp av en skriftlig uppsättning tester eller ett automatiskt test
• Ett rökprov är utformat för att beröra varje del av applikationen på ett kortfattat sätt. Det är grunt och brett.
• Denna testning utförs för att säkerställa om de viktigaste funktionerna i ett program fungerar, men inte bry sig om de finare detaljerna. (Så som byggverifiering).
• Denna testning är en normal hälsokontroll för att bygga en applikation innan den testas för att testa djupet.

SANITY TESTING

• Ett förnuftstest är ett smalt regressionstest som fokuserar på ett eller några funktionsområden. Sanity Testing är vanligtvis smal och djup.
• Detta test är vanligtvis oskriptat.
• Detta test används för att fastställa att en liten del av applikationen fortfarande fungerar efter en mindre förändring.
• Denna testning är kortvarig testning, den utförs när en kortvarig testning är tillräcklig för att bevisa att applikationen fungerar enligt specifikationerna. Denna testnivå är en delmängd av regressionstestning.
• Detta är för att verifiera om kraven uppfylls eller inte, kontrollera alla funktioner bredvid först.

Hoppas att du är tydlig om skillnaderna mellan dessa två stora och viktiga programvarutestningstyper. Dela gärna dina tankar i kommentarfältet nedan !!

Rekommenderad läsning

• Bästa verktyg för testning av programvara 2021 (QA Test Automation Tools)
• Skillnad mellan Desktop, Client Server Testing och Web Testing
• Funktionell testning mot icke-funktionell testning
• Testing Primer eBook Download
• Alpha Testing och Beta Testing (En komplett guide)
• Handbok för testbarhet med praktiska exempel
• Typer av programvarutestning: Olika testtyper med detaljer
• Funktionell testning mot prestandatestning: Bör det göras samtidigt?