Good Mood

utforska skillnaderna mellan Röktestning och Sanity Testing i detalj med exempel:

i den här handledningen kommer vi att lära oss vad som är Sanity Testing och Röktestning i mjukvarutestning. Vi kommer också att lära oss de viktigaste skillnaderna mellan Sanity och röktest med enkla exempel.

de flesta gånger blir vi förvirrade mellan betydelsen av Sanity-testning och Röktestning. Först och främst är dessa två testningar sätt ”olika” och utförs under olika stadier av en testcykel.,

Sanity Testing

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

därför skulle jag definiera,

”Sanity Testing som ett testutförande som görs för att röra varje implementering och dess inverkan men inte grundligt eller djupgående, det kan innehålla funktionell, UI, version etc. testning beroende på genomförandet och dess inverkan.”

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

Ah ja, jag slår vad om att du också måste ha mött denna situation minst en gång i din Mjukvarutestupplevelse. Tja, jag mötte det mycket eftersom mitt projekt(er) var mestadels smidiga och ibland blev vi ombedda att leverera det samma dag. Oj, hur kunde jag testa och släppa byggnaden inom en sträcka av timmar?

Jag brukade gå nötter ibland eftersom även om det var en liten funktionalitet kan implikationen vara enorm. Och som en glasyr på kakan, vägrar kunderna ibland helt enkelt att ge extra tid., Hur kan jag slutföra hela testningen om några timmar, verifiera alla funktioner, buggar och släppa det?

svaret på alla sådana problem var väldigt enkelt, dvs. inget annat än att använda Sanity Testing strategy.

När vi gör denna testning för en modul eller funktionalitet eller ett komplett system, väljs testfall för utförande så att de kommer att röra alla viktiga bitar och bitar av samma, dvs bred men Grunt testning.

ibland görs testningen till och med slumpmässigt utan testfall., Men kom ihåg, Sanity test bör göras endast när du kör kort tid, aldrig använda detta för dina vanliga utgåvor. Teoretiskt sett är denna testning en delmängd av regressionstestning.

min erfarenhet

av mina 8+ år av karriär inom mjukvarutestning, i 3 år arbetade jag i Agile methodology och det var den tid då jag mestadels använde ett sanity-test.

alla stora utgåvor planerades och utfö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 testfallen, köra, göra feldokumentationen, göra regressionen och följa hela processen.

därför är följande några av de viktigaste pekare som jag brukade följa under sådana situationer:

#1) sitta med chefen och dev-laget när de diskuterar genomförandet eftersom de måste arbeta snabbt och därför kan vi inte förvänta oss att de ska förklara 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 ibland vi helt enkelt inte inser konsekvenserna och om någon befintlig funktionalitet kommer att hämmas (i värsta fall).

# 2) när du är kort tid, när utvecklingsteamet arbetar med genomförandet, kan du notera testfall 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 testfallsverktyget.,

#3) Håll din testbädd redo enligt genomförandet och om du känner att det finns några röda flaggor som vissa specifika data skapande om en testbädd tar tid (och det är ett viktigt test för frisläppandet), sedan höja dessa flaggor omedelbart och informera din chef eller PO om vägspärren.

bara för att klienten vill asap betyder det inte att en QA kommer att släppa även om den är halvtestad.,

#4) gör ett avtal med ditt team och chef som på grund av tid crunch du bara kommer att kommunicera buggar till utvecklingsteamet och den formella processen att lägga till, märkning buggar för olika stadier i felsökningsverktyget kommer att göras senare för att spara tid.

#5) när utvecklingsteamet testar i slutet, försök att para ihop med dem (kallad dev-QA-parning) och göra en grundläggande runda på själva installationen, kommer detta att bidra till att undvika byggets fram och tillbaka om det grundläggande genomförandet misslyckas.,

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

#7) oavsett fel du hittar, notera dem alla och försök att rapportera dem tillsammans till utvecklarna istället för att rapportera individuellt eftersom det blir lätt för dem att arbeta med ett gäng.

#8) Om du har ett krav på den totala prestandatestning 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 sanity teststrategi – ”när du utarbetar e-postmeddelandet eller dokumentet, nämna alla testfall som du exekverade, fel hittades med en statusmarkör och om något lämnades otestad 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 dela min egen erfarenhet:

#1) Vi arbetade på en webbplats och det brukade popup-annonser baserat på sökorden. Annonsörerna brukade lägga budet för vissa sökord som hade en skärm utformad för samma. Standardbudvärdet som användes för att visas som $ 0.25, vilket budgivaren till och med kan ändra.

det fanns ytterligare en plats där detta standardbud användes för att visa upp och det kan också ändras till 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 brainstorming diskussion glömde vi (?) om den här andra skärmen eftersom den inte användes mycket för det ändamålet. Men medan jag testade när jag körde det grundläggande fallet med budet att vara $ 0.5 och kontrollerat slut till slut, fann jag att cronjob för samma misslyckades eftersom det på ett ställe var att hitta $0.25.

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

# 2) under samma projekt (som nämns ovan) blev vi ombedda att lägga till ett litet textfält för anteckningar/kommentarer för budgivning., Det var ett mycket enkelt genomförande och vi åtog oss att leverera det samma dag.

så som nämnts ovan testade jag alla affärsregler och använder Fall runt det och när jag gjorde några valideringstester fann jag att när jag skrev in en kombination av specialtecken som </> kraschade sidan.

vi tänkte över det och räknade ut att de faktiska budgivarna inte i något fall kommer att använda sådana kombinationer. Därför släppte vi det med en väl utarbetad anteckning om problemet., Klienten accepterade det som en bugg men kom överens med oss om att genomföra det senare eftersom det var en allvarlig bugg men inte en tidigare.

#3) nyligen arbetade jag på ett mobilappsprojekt, och vi hade ett krav på att uppdatera Leveranstiden som visas i appen enligt tidszonen. Det var inte bara att testas i appen utan även för webbtjänsten.

medan utvecklingsteamet arbetade med implementeringen skapade jag automationsskripten för webbtjänstetestningen och DB-skripten för att ändra tidszonen för leveransobjektet., Detta räddade mina ansträngningar och vi kunde uppnå bättre resultat inom en kort tid.

Sanity Testing Vs Regression Testing

ges nedan är några skillnader mellan de två:

strategi för testning av mobilappar

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

anledningen är att OS och webbläsarversionen för webb-eller skrivbordsprogram inte varierar mycket och speciellt skärmstorlekarna är standard. Men med mobilappar påverkar skärmstorleken, mobilnätet, 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 fel kan landa dig i stora problem. Testningen måste göras smart och med försiktighet också.

Följande är några tips som hjälper dig att utföra denna testning framgångsrikt på en ”mobilapp”:

#1) Först och främst analysera effekterna av OS-versionen på implementeringen med ditt team.

försök att hitta svar på frågor som, kommer beteendet att vara annorlunda i olika versioner? Kommer genomförandet att fungera på den lägsta version som stöds eller inte?, Kommer det att finnas prestandaproblem för genomförandet av versioner? Finns det någon specifik egenskap hos operativsystemet som kan påverka implementeringens beteende? osv.

#2) på ovanstående anteckning, analysera för telefonmodellerna också d. v. s. finns det några funktioner i telefonen som kommer att påverka genomförandet? Är genomförandet av beteendeförändring med GPS? Förändras implementeringsbeteendet med telefonens kamera? osv. Om du upptäcker att det inte finns någon inverkan, undvik att testa på olika telefonmodeller.,

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

#4) för att spara tid, undvik att testa på bra nätverk eftersom det är uppenbart att genomförandet kommer att fungera som förväntat på ett starkt nätverk. Jag rekommenderar att du börjar med testning på 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älttest om det inte bara är en UI-förändring.,

# 6) Om du måste testa för en matris av olika operativsystem och deras version, skulle jag föreslå att du gör det på ett smart sätt. Till exempel, välj den lägsta, medium och den senaste OS-versionen par för testning. Du kan nämna i utgivningsdokumentet att inte varje kombination testas.

#7) på en liknande linje, för UI implementation sanity test, använd små, medelstora och stora skärmstorlekar för att spara tid. Du kan också använda en simulator och emulator.,

försiktighetsåtgärder

Sanity test utförs när du kör kort tid och det är därför 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 uteblivna ganska vanliga.,

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

• aldrig acceptera en byggnad för testning tills du inte får ett skriftligt krav som delas av kunden. Det händer att klienter kommunicerar ä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 ge några grundläggande funktionalitetspoäng och acceptanskriterier.
• gör alltid grova anteckningar av dina testfall och buggar om du inte har tillräckligt med tid att skriva dem snyggt. Lämna aldrig dessa papperslösa., Om det finns lite tid, dela den med din ledning eller team så att om något saknas kan de peka ut det enkelt.
• Om du och ditt team har ont om tid, se till att buggarna är markerade i rätt skick i ett e-postmeddelande? Du kan maila hela listan med buggar till laget och göra devs markera dem på lämpligt sätt. Håll alltid bollen i den andras domstol.
• Om du har Automatiseringsramverk redo, använd det och undvik att göra ManualTesting, så på kortare tid kan du täcka mer.,
• Undvik scenariot med ”release in 1 hour” om du inte är 100% säker på att du kommer att kunna leverera.
• sist men inte minst, som nämnts ovan, utarbeta en detaljerad release e-post kommunicera vad som testas, vad som utelämnas, skäl, risker, vilka buggar är lösta, vad är ” Sen ” etc.

som QA bör du bedöma vad som är den viktigaste delen av genomförandet som måste testas och vilka delar som kan utelämnas eller grundläggande testas.,

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

Röktestning

Röktestning är inte uttömmande testning men det är en grupp av tester som utförs för att verifiera om de grundläggande funktionerna i den specifika byggnaden fungerar bra som förväntat eller inte. Detta är och bör alltid vara det första testet som ska göras 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 trasig.

i ljuset av detta, Hur kommer en QA att se till att de grundläggande funktionerna fungerar bra?

svaret på detta kommer att vara att utföra en röktest.

när testerna är markerade som röktest (i testsviten) passerar, accepteras byggnaden endast av QA för djupgående testning och/eller regression., Om någon av röktesterna misslyckas, avvisas byggnaden och utvecklingsteamet måste åtgärda problemet och släppa en ny byggnad för testning.

teoretiskt definieras Röktestet som ytnivåprovning för att intyga att den byggnad som utvecklingsgruppen tillhandahåller QA-teamet är redo för ytterligare testning. Denna testning utförs också av utvecklingsteamet innan du släpper byggnaden till QA-laget.

denna testning används normalt vid Integrationstestning, systemtestning och Godkännandenivåtestning. Behandla aldrig detta som ett substitut för den faktiska änden för att avsluta fullständig testning., Den består av både positiva och negativa tester beroende på bygggenomförandet.

exempel på Röktestning

denna testning används normalt för Integration, acceptans och systemtestning.

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

#1) acceptanstest

När en byggnad släpps till QA, bör röktest i form av en acceptanstest göras.,

i detta test är det första och viktigaste röktestet att verifiera implementeringens grundläggande förväntade funktionalitet. Så här bör du verifiera alla implementeringar för den specifika byggnaden.

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

• implementerade inloggningsfunktionen för att de registrerade drivrutinerna ska kunna logga in framgångsrikt.
• implementerade instrumentpanelsfunktionen 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 inga rutter finns för en viss dag.

i ovanstående byggnad, på acceptansnivå, innebär röktestet att verifiera att de grundläggande tre implementeringarna fungerar bra. Om någon av dessa tre är trasig, bör QA avvisa byggnaden.

#2) Integrationstestning

denna testning görs vanligtvis när de enskilda modulerna implementeras och testas., I Integrationstestnivån utförs denna testning för att se till att alla grundläggande integration och end to end-funktioner fungerar bra som förväntat.

det kan vara att integrera två moduler eller alla moduler tillsammans, varför röktestets komplexitet varierar 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 integreringen av ankomststatusuppdatering och återspeglar detsamma på stoppskärmen.,
• implementerade integrationen av complete pick up till leveransfunktionsmodulerna.

i denna byggnad kommer röktestet inte bara att verifiera dessa tre grundläggande implementeringar utan för den tredje implementeringen kommer några fall att verifiera för fullständig integration också. Det hjälper mycket att ta reda på de problem som introduceras i integration och de som gick obemärkt förbi utvecklingsteamet.

#3) systemtestning

som namnet själv antyder innehåller röktestningen för systemnivå tester för systemets viktigaste och vanligaste arbetsflöden., Detta görs först efter det att hela systemet är klart& testat, och denna testning för systemnivå kan kallas röktest före regressionstestning också.

innan regressionen av det kompletta systemet startas testas grundläggande end to end-funktioner som en del av röktestet. Röktestsviten för hela systemet består av testfall som slutanvändarna kommer att använda Mycket ofta.

detta görs vanligtvis med hjälp av automationsverktyg.,

betydelse i SCRUM Methodology

nuförtiden följer projekten knappast Vattenfallsmetoden i projektgenomförandet, mestadels följer alla projekt endast Agile och SCRUM. Jämfört med den traditionella vattenfallsmetoden har Röktestning höga hälsningar i SCRUM och Agile.

Jag arbetade i 4 år i SCRUM. Och som vi vet att i SCRUM är sprinterna av 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 takeaway på vikten av denna testning i SCRUM:

• av fjorton sprint tilldelas halvtid till QA men ibland är byggnaderna till QA försenade.
• i sprints är det bäst för laget att problemen rapporteras på ett tidigt stadium.
• varje berättelse har en uppsättning acceptanskriterier, varför testning av de första 2-3 acceptanskriterierna är lika med röktest av den funktionaliteten. Kunderna avvisar leveransen om ett enda kriterium misslyckas.,
• tänk vad som händer om det är 2 dagar som utvecklingsteamet levererade dig byggnaden och bara 3 dagar återstår för demo och du stöter på ett grundläggande funktionalitetsfel.
• i genomsnitt har en sprint berättelser som sträcker sig från 5-10, därför när byggnaden ges är det viktigt att se till att varje berättelse implementeras som förväntat innan man accepterar byggnaden i testning.
• när hela systemet ska testas och regredieras, är en sprint tillägnad 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 startas.

röktest Vs bygga acceptanstest

röktest är direkt relaterad till bygga acceptanstest (BAT).

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

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

Röktestcykel

följande flödesschema förklarar Röktestcykeln.

När en byggnad är utplacerad till en QA, följs grundcykeln att om röktestet passerar, accepteras byggnaden av QA-laget för ytterligare testning men om det misslyckas, avvisas byggnaden tills de rapporterade problemen är fasta.,

testcykel

vem ska utföra Röktestet?

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

Röktestning utförs idealiskt av QA-ledningen som bestämmer baserat på resultatet som för om man ska skicka byggnaden till laget för vidare testning eller avvisa den. Eller i avsaknad av ledningen kan QA själva också utföra denna testning.

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

därav enskilda QA: s utföra denna testning för de berättelser som de äger.

varför ska vi automatisera Röktester?

denna testning är det första testet som ska göras på en byggnad som släpptes av utvecklingsteamet(erna). Baserat på resultaten av denna testning görs ytterligare testning (eller byggnaden avvisas).,

det bästa sättet att göra denna testning är att använda ett automationsverktyg och schemalägga smoke suite att köra när en ny byggnad skapas. Du kanske tänker Varför ska jag ”automatisera röktestsviten”?

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

låt oss säga att du är en vecka bort från din release och av de totala 500 testfall, din rök test svit består av 80-90. Om du börjar utföra alla dessa 80-90 testfall manuellt, föreställ dig hur mycket tid du tar? 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 då helst, dessa kommer att köras i 2-3 timmar och du kommer att ha resultaten med dig direkt. Sparar det inte din dyrbara tid och ger dig resultaten om uppbyggnaden mycket mindre tid?

5 år tillbaka, jag testade en finansiell projektion app, som tog ingångar om din lön, besparingar, etc., och projicerade 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 detta projekt hade jag 800 testfall och 250 var röktestfall. Med hjälp av selen kan vi enkelt automatisera och få resultaten av dessa 250 testfall på 3-4 timmar. Det räddade 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 dess få nackdelar.

fördelar:

• lätt att utföra.
• minskar risken.,
• defekter identifieras i ett mycket tidigt skede.
• sparar ansträngningar, tid och pengar.
• körs snabbt om automatiserad.
• minst integrationsrisker och problem.
• förbättrar systemets övergripande kvalitet.

nackdelar:

• denna testning är inte lika med eller ett substitut för fullständig funktionell testning.
• även efter att röktestet har passerat kan du hitta showstopper-fel.,
• denna typ av testning är bäst lämpad om du kan automatisera annat mycket tid spenderas på att manuellt utföra testfallen, särskilt i storskaliga projekt med cirka 700-800 testfall.

Röktestning bör definitivt göras på 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, fastställande av frågor 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 funktionell testning av funktionalitet eller system (som helhet). Men innan det bör QA-laget vara mycket tydligt om vilka tester som ska göras som röktest. 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 automationsverktyg. Men det bästa och föredragna sättet är att använda automationsverktyg för att spara tid.,

skillnad mellan rök och Sanity Testing

de flesta gånger blir vi förvirrade mellan betydelsen av Sanity Testing och Röktestning. Först och främst är dessa två testningar sätt ”olika” och utförs under olika stadier av en testcykel.

Följande är en diagrammatisk representation av deras skillnader:

RÖKTESTNING

• denna testning har sitt ursprung i hårdvarutestningspraxis att slå på en ny maskinvara för första gången och betrakta den som en framgång om den inte brinner och röker. I mjukvaruindustrin är denna testning ett grunt och brett tillvägagångssätt där alla applikationsområden utan att komma in för djupt testas.,
• ett röktest är skript, antingen med hjälp av en skriftlig uppsättning tester eller ett automatiserat test
• ett röktest är utformat för att röra varje del av programmet på ett översiktligt sätt. Den är ytlig och bred.
• denna testning utförs för att säkerställa om de mest avgörande funktionerna i ett program fungerar, men inte stör med de finare detaljerna. (T.ex. byggverifiering).
• denna testning är en normal hälsokontroll till byggandet av ett program innan du tar det för att testa på djupet.,

SANITY TESTING

• ett sanity test är ett smalt regressionstest som fokuserar på ett eller några områden av funktionalitet. Sanity Test är vanligtvis smal och djup.
• detta test är vanligtvis unscripted.
• detta test används för att bestämma att en liten del av programmet fortfarande fungerar efter en mindre förändring.
• denna testning är snabb testning, den utförs när en snabb testning är tillräcklig för att bevisa att programmet fungerar enligt specifikationerna. Denna testnivå är en delmängd av regressionstestning.,
• detta är att kontrollera om kraven är uppfyllda eller inte, kontrollera alla funktioner bredd-först.