Vad är skillnaden mellan Retesting och regressionstestning:
Älskar du inte alla artiklar med Jämför och kontrasttema? Jag vet att jag gör det. Det är ett så bra sätt att bjuda in tankar, kommentarer och kanske till och med stark oenighet.
dagens ämne är Retesting Vs Regression testning.
=> Klicka Här För Den Fullständiga Regressionstestserien.
låt oss börja med Omtestning:
Retesting
Retest betyder att testa igen. Anledningen spelar ingen roll. När du upprepar ett test testar du igen. Du kan testa Aktuell version funktionalitet. Eller en buggfix, tidigare version funktionalitet, ett testfall du just sprang, etc.
om du fortfarande tänker-varför – då är följande några anledningar som är lika bra som alla:
- du körde ett test igår och stötte på en defekt. Du vill bekräfta stegen och defektens Reproducerbarhet. Så, du testar igen.
- du körde ett test. Din uppmärksamhet var inte på den (kanske ringde din telefon, eller du pratade med en kollega etc.). Du vill kontrollera en gång till, så du testar igen.
jag är säker på att du får det.
Retesting är när du upprepar ett test av någon anledning. Det är en av de termer som håller fast vid dess definition.
Regressionstest
programvara utvecklas. Det kommer att finnas nya versioner över befintliga. Det staplas på nya funktioner, tillägg etc. Men med tiden kan detta leda till instabilitet i ansökan.
Föreställ dig att du gör ett blocktorn genom att lägga till ett block över det andra. Du tar dig inte tid att förstärka eller stärka basen. Det dröjer inte länge innan tornet kraschar, eller hur?
precis som det måste du testa programvarans bas för styrka och stabilitet.
för att göra det måste vi testa programvaran igen. Det är det enda sättet.
Rekommenderad läsning => Vad är regressionstestning? Verktyg och bästa praxis
Regression är en form av Retest. Specifikationerna för ”varför” och ” när ” är det som skiljer det från det förra.
1) När testar vi igen? När programvara genomgår en förändring
2) Varför testar vi igen? För att säkerställa att de nya tilläggen/ändringarna inte har gjort funktionen före arbetet instabil. Regression är vanligt och rekommenderas när:
- en ny version blir tillgänglig. (Regress alla eller åtminstone den viktiga av de äldre versionsfunktionerna)
- Bugfix
punkt att notera: uttömmande regressionstestning är omöjligt men önskvärt.
därför gör regressionsanalys innan du hoppar rakt in i testningen. Detta steg innebär att bestämma hur mycket regression jag ska göra för min ansökan.
vad beror graden av regression på?
- förändringens Natur
- förhållande/påverkan av ändringen på det aktuella systemet/funktionen
- tillgänglig tid och resurser
Hur kan testare bestämma omfattningen av regression?
1) genom erfarenhet och förtrogenhet med ansökan
2) Diskutera med utvecklarna
3) den plats där ändringen har gjorts. Exempelvis: om det finns på hemsidan behöver det mer uppmärksamhet än om det var på en av de mindre åtkomliga sidorna.
beroende på de faktorer som spelas kan ett Testlag gå till något av följande:
- Enhetsregression
- partiell Regression
- Full Regression
Enhetsregression innebär att du testar om den ändrade modulen/området för applikationen.
partiell regression innebär att du testar den ändrade modulen igen. Plus inkluderar de som interagerar med det.
Full regression är att du testar hela applikationen oavsett platsen för ändringen.
det beror på situationen (tid & resurstillgänglighet), förändringens allvar (dess inverkan), utvecklarens ingångar etc. Du kommer att bli mer effektiv när du väljer rätt uppsättning tester vs. alla tester.
regressionsanalys är den viktigaste framgångsfaktorn. Det behöver smart arbete snarare än hårt arbete.
missuppfattningar om regressionstestning
det finns många missuppfattningar om regressionstestning:
#1) Regression görs alltid via automatisering: Nej. Regression görs också manuellt. Vi har en hel artikel om detta => Hur utförs regressionstestning? Kan det göras manuellt?
Observera att regression är en perfekt kandidat för automatisering. Omfattningen av upprepning är tidskrävande och kan leda till tristess. Viktig validering kan också missa. Automation är ett pålitligt, snabbt och effektivt alternativ.
Läs också = > automatiska utmaningar för regressionstestning
#2) Regression är aldrig fullständig: Sant. Men inte helt.
vad jag menar är att ett uttömmande regressionstest kan vara omöjligt. Men uttömmande regressionstestning kan också vara onödigt.
låt oss säga att du ändrade en felstavning på hemsidan. Denna fix är mindre. Det är också isolerat från de andra applikationsområdena. Så, en enkel retesting av funktionen skulle göra. Inget behov av att regressera den tidigare funktionaliteten runt hemsidan.
# 3) Det är onödigt när du har en crunch för tiden: inte sant. Inte tillräckligt med regression leder till brist på förtroende för produkten. Du kommer aldrig att veta vad du kan förvänta dig av dess reaktion på olika slutanvändarscenarier.
#4) det körs varje enskilt testfall i den tidigare versionen: återigen är det inte rätt sätt att välja varje testfall. Strategisk plockning av testfall är nyckeln. Förstå förändringen och välj passande testfall.
OK, det är Retesting och Regressionstest i detalj.
nu, jämförelsen.
Retesting Vs regressionstestning
Vad är detsamma om dem?
- de är båda repetitionsbaserade
- validering och Black box – testtekniker
- Automation eller manuella testfall blir båda testade eller regresserade
- ”man måste verifiera eller utvisa sina tvivel och omvandla dem till säkerheten om ja eller nej-Thomas Carlyle”. Båda gör det här.
Vad är annorlunda med dem?
- Retesting är tillämplig för alla test nuvarande eller tidigare version funktionalitet riktade. Regression är tidigare version funktionalitet centrerad.
- Omtestning är inte beroende av tillämplig förändring. Regression är förändringsorienterad.
slutligen, för att träffa detta koncept hem:
låt oss säga att du har ett testfall XYZ som resulterade i en defekt med ID 120. Denna defekt fixas i nästa utgåva. Du skulle testa XYZ testfall och regressera funktionaliteten runt den. Regressionen är att se till att allt fungerar intakt efter 120-talets fix. Testet är att bestämma defektens fix.
så det är varken det ena eller det andra, utan kombinationen av regression och omtestning som bildar den dynamiska duon.
nu är det över till dig. Håller du med de definitioner och analyser som ges här?
om författaren: den här artikeln är skriven av STH-teammedlem Swati S.