validation testing ultimate guide
Utforska vikten av valideringstestning:
Vad du kommer att lära dig:
- Vad är valideringstestning?
- Skillnaden mellan verifiering och validering
- Stadier involverade
- Provvalideringstestfall eller protokoll
- Slutsats
- Rekommenderad läsning
Vad är valideringstestning?
Valideringstestning är processen för att säkerställa om den testade och utvecklade programvaran uppfyller kundens / användarens behov. Affärslivets logik eller scenarier måste testas i detalj. Alla kritiska funktioner i en applikation måste testas här.
Som testare är det alltid viktigt att veta hur man verifierar den affärslogik eller de scenarier som du får. En sådan metod som hjälper i detalj utvärdering av funktionerna är valideringsprocessen.
När du blir ombedd att utföra ett valideringstest krävs det ett stort ansvar eftersom du behöver testa alla kritiska affärsbehov baserat på användarnas behov. Det bör inte ens vara en enda miss på de krav som användaren ställer. Därför är en stor kunskap om valideringstest mycket viktig.
Som testare måste du utvärdera om testkörningsresultaten överensstämmer med det som nämns i kravdokumentet. Eventuella avvikelser bör rapporteras omedelbart och den avvikelsen kallas därför ett fel.
Verktyg som HP Quality Center, Selen, Appium, etc. används för att utföra valideringstest och vi kan lagra testresultaten där. En riktig testplan, testkörning, defektrapporter, rapporter och mätvärden är de viktigaste resultaten som ska skickas in.
Ur ett företagsperspektiv utförs valideringstestet i enkla steg med följande steg:
- Du samlar in företagskraven för valideringstest från slutanvändaren.
- Förbered affärsplanen och skicka den för godkännande till de involverade platserna / intressenterna.
- Efter godkännande av planen börjar du skriva nödvändiga testfall och skicka dem för godkännande.
- När du väl är godkänd börjar du slutföra testningen med den nödvändiga programvaran, miljön och skicka leveranserna enligt kundens begäran.
- Efter godkännande av leveranserna utförs UAT-test av klienten.
- Därefter går programvaran till produktion.
vad är en deque c ++
Låt oss nu utforska mer om validering i detalj.
Skillnaden mellan verifiering och validering
Låt oss förstå dessa med ett exempel på ett enkelt sätt.
Exempel:
Kundkrav:
Den föreslagna injektionen bör inte väga över 2 cm.
Verifieringstest:
- Kontrollera om injektionen är den injektion som inte väger över 2 cm genom att använda checklista, granskning och design.
Valideringstest:
- Kontrollera om injektionen inte väger över 2 cm genom att använda manuell eller automatiseringstestning.
- Du måste kontrollera alla möjliga scenarier med avseende på injektionsvikten med någon lämplig testmetod (funktionella och icke-funktionella metoder).
- Kontrollera om mätningar är mindre än 2 cm och över 2 cm.
Verifiering | Godkännande |
---|---|
Processen kontrollerar bara design, kod och program. | Den ska utvärdera hela produkten inklusive koden. |
Recensioner, genomgångar, inspektioner och skrivbordskontroll involverade. | Funktionella och icke-funktionella testmetoder är inblandade. En djupgående kontroll av produkten görs. |
Den kontrollerar programvaran med specifikation. | Den kontrollerar om programvaran uppfyller användarens behov. |
Stadier involverade
- Designkvalifikation: Detta inkluderar att skapa testplanen utifrån företagets krav. Alla specifikationer måste nämnas tydligt.
- Installationskvalifikation: Detta inkluderar programvaruinstallation baserat på kraven.
- Operativ kvalifikation: Detta inkluderar testfasen baserad på specifikationen för användarkrav.
Detta kan inkludera Funktionstest:
-
- Enhetstestning - Svart låda, Vit låda, Grå låda.
- Integrationstest - Uppifrån och ner, Nedifrån och upp, Big bang.
- Systemtestning - Förnuft, rök och regressionstestning.
- Prestationskvalificering: UAT (test av användaracceptans) - Alfa- och betatestning.
- Produktion
Designkvalifikation
Designkvalificering innebär helt enkelt att du måste förbereda designen av programvaran så att den uppfyller användarspecifikationerna. I första hand måste du få URS-dokument (User Requirements Specification) från klienten för att fortsätta med designen.
Teststrategi:
Detta dokument utgör basen för att utarbeta testplanen. Det bereds vanligtvis av teamledaren eller projektledaren. Den beskriver hur vi ska gå vidare för att testa och uppnå det önskade målet.
För att införliva alla procedurer bör en ordentlig plan utformas och godkännas av intressenterna. Så låt oss veta komponenterna i testplanen.
I några få projekt kan testplan och teststrategi införlivas som ett enda dokument. Separata strategidokument utarbetas också för ett komplext projekt (mestadels inom automatiseringsteknik).
Komponenter i valideringstestplanen:
- Beskrivning av projektet
- Förstå kraven
- Testomfång
- Testnivåer och testschema
- Kör skapande av plan
- Hårdvaruprogramvara och personalbehov
- Roller och ansvar
- Antagande och beroenden
- Risker och begränsning
- Rapport och mätvärden
Beskrivning av projektet: Här måste du belysa all beskrivning av applikationen som du har fått för testning. Den bör innehålla alla funktionerna i appen.
Förstå kraven: När du får USR måste du nämna de förstådda kraven från din sida. Du kan också ta upp förtydliganden om någon. Detta står som bas- eller testkriterium för testning.
Testomfång: Omfattningen måste innehålla modulerna i detalj tillsammans med funktionerna på hög nivå. Du måste berätta för klienten vilka krav du täcker i din testning.
Ur ett affärsperspektiv kan valideringstest bli ombedd att utföra de kritiska kraven i en applikation. Det betyder helt enkelt att du säger vad som kommer att täckas och vad inte .
Testnivåer och testschema: Du måste nämna hur många testomgångar som måste genomföras. Den totala ansträngningen för testprojektet uppskattas med hjälp av standarduppskattningstekniker som TCP-uppskattning (Test Case Point) etc.
Som namnet antyder testschema beskriver hur testningen kommer att genomföras. Det bör också säga hur och när godkännandet och granskningarna kommer att genomföras.
Exempel:
Projektet av en webbsida övervägs.
Testnivåerna inkluderar:
Nivå 1: Rökprovning
Nivå 2: Enhetstestning
Nivå 3: Integrationstestning
Nivå 3: Systemtestning
Nivå 3: Godkännande testning
Testschema:
- Planera inlämning - Dag 1
- Design av testfall - Dag 2
- Dry run och bug fixing - Dag 4
- Recension- Dag 5
- Formell körning - Dag 6
- Leveranser skickade för godkännande - Dag 8
- Rapporter - Dag 10
Kör skapande av plan: Körplanen markerar antalet körningar som krävs för testning. Varje körning du utför på platsen kommer att noteras av teamet på plats.
Till exempel, när du använder HP Quick Test Professional-verktyg för körning visas antalet körningar på fliken Kör i testplanen.
Hårdvaruprogramvara och personalbehov:
- Hårdvaru- och mjukvarukrav som enheter, webbläsarversioner, IOS, testverktyg som krävs för projektet.
- Med bemanning menas att utse de personer som krävs för testning. Du kan nämna teamantalet här.
- Om du behöver några extra testmedlemmar kan du begära på plats beroende på testomfånget. Helt enkelt när antalet testfall ökar, innebär det att du behöver fler teammedlemmar för att utföra dem.
Roller och ansvar: Detta innebär att tilldela uppgifter till relaterade roller som ansvarar för att genomföra de olika testnivåerna.
Till exempel,
En app måste testas av ett team bestående av fyra medlemmar för att utföra fyra valideringsprotokoll och du kan delegera ansvaret enligt följande:
- Testledning: Design av testplan
- Teammedlem 1: Utformning och utförande av protokoll 1,2.
- Teammedlem 2: Utformning och utförande av protokoll 3,4.
- Lagmedlem: Utarbetande av rapporter, granskning och mätvärden.
Antagande och beroende: Detta innebär att de antaganden som gjorts under design och beroenden som identifierats för testning kommer att inkluderas här.
Risker och begränsning: Risker relaterade till testplaneringen, såsom tillgänglighet för önskade miljöer, byggnad osv. Tillsammans med planer för begränsning och beredskap.
Rapport och mätvärden: Faktorer som användes för testning och rapporter till intressenterna måste nämnas här.
Ett exempel på en mobilapp ges nedan:
Installationskvalifikation
- Installationskvalificeringen innehåller detaljer som vilka och hur många testmiljöer som skulle användas, vilken åtkomstnivå som krävs för testarna i varje miljö tillsammans med de testdata som krävs. Det kan inkludera webbläsarkompatibilitet, verktyg som krävs för körning, enheter som krävs för testning etc. Systemet som utvecklas bör installeras i enlighet med användarkraven.
- Testdata kan krävas för att testa vissa applikationer och det måste ges av rätt person. Det är en viktig förutsättning.
- Vissa applikationer kan kräva en databas. Vi måste hålla alla data som krävs för testning redo i en databas för att validera specifikationerna.
Till exempel, En ny app säger att 'abc' måste testas i mobil (Android 4.3.1) och webbläsare (Chrome 54), i ett sådant fall måste vi hålla reda på följande:
- Kontrollera om rätt behörighet ges för att kontrollera webbplatsen för appen “abc”.
- Se om enheterna som används för att testa appen som mobil (android / ios), webbläsare-Chrome, Internet Explorer med nödvändig version är tillgängliga.
- Kontrollera om de är installerade korrekt med de angivna versionerna (t.ex. Chrome 54, Android version 4.3.1).
- Se till att appen är tillgänglig i både webbläsaren och mobilen.
Operativ kvalifikation
Operativ kvalifikation säkerställer att varje modul och delmodul som är utformad för applikationen under test fungerar som den förväntas i önskad miljö.
En valideringstestning utförs i allmänhet i följande hierarki.
Funktionell testning spelar en viktig roll i valideringstestning. Det betyder helt enkelt att du måste validera programmets funktionalitet med varje nämnt kritiskt krav. Detta banar väg för att kartlägga kraven som nämns i dokumentet Funktionsspecifikation och säkerställa att produkten uppfyller alla nämnda krav.
Funktionstestning och dess typer
Som namnet antyder, funktionstestning testar funktionerna, dvs vad programvaran måste göra. Programvarans funktioner definieras i kravspecifikationsdokumentet.
Låt oss ta en snabb titt på dess typer.
# 1) Enhetstestning:
Enhetstestning testar de enskilda enheterna / modulerna / komponenterna / metoderna i det givna systemet. Fältvalidering, layoutkontroll, design etc. testas med olika ingångar efter kodning. Varje rad i koden ska valideras till de enskilda enhetens testfall.
vad du ser är vad du får webbbyggare
Enhetstestning görs av utvecklarna själva. Kostnaden för att fixa buggar är mindre här jämfört med andra testnivåer.
Exempel:
Att utvärdera en slinga av koden för en funktion säger att könsval är ett exempel på enhetstestning.
# 2) Black Box-testning:
Att testa en applikations beteende för de önskade funktionerna mot kraven utan att fokusera de interna detaljerna i systemet kallas Black Box-testning. Det utförs vanligtvis av ett oberoende testteam eller slutanvändarna av applikationen.
Applikationen testas med relevanta ingångar och testas för att validera om systemet beter sig som önskat. Detta kan användas för att testa både funktionella såväl som icke-funktionella krav.
# 3) White Box Testing:
Vitlåda testning är inget annat än en detaljerad kontroll av programkoden efter kod. Hela tillämpningen av applikationen beror på koden skriven, därför är det nödvändigt att testa koden mycket noggrant. Du måste kontrollera varje enhet och dess integration som en hel modul steg för steg.
En testare med programmeringskunskap är ett måstekriterium här. Detta visar tydligt om det finns någon avvikelse i programmets arbetsflöde. Det är användbart för både utvecklare och testare.
# 4) Grå låda testning:
Test av grå låda är en kombination av både vitlåda och svartlåda. Delvis kunskap om strukturen eller koden för den enhet som ska testas är känd här.
Integrationstestning och dess typer
De enskilda komponenterna i programvaran som redan testats i enhetstester integreras och testas tillsammans för att testa deras funktioner som helhet för att säkerställa dataflöde över modulerna.
Detta görs av utvecklarna själva eller av ett oberoende testteam. Detta kan göras efter att två eller flera enheter har testats.
Uppifrån och ner strategi:
I detta tillvägagångssätt testas toppenheterna först och sedan testas de lägre nivåerna en efter en stegvis. Teststubbar som kan användas krävs för att simulera de enheter på lägre nivå som kanske inte är tillgängliga under de inledande faserna.
Nedifrån och upp-tillvägagångssätt:
I detta tillvägagångssätt testas först de nedre enheterna, integreras och sedan testas enheterna på högre nivå. Teststubbar som kan användas krävs för att simulera de enheter på högre nivå som kanske inte är tillgängliga under de inledande faserna.
Systemtestning och dess typer
Testning av hela systemet / programvaran kallas systemtestning. Systemet testas helt mot funktionskravspecifikationerna. Systemtestning görs mot både funktionella och icke-funktionella krav. Black box-testning föredras i allmänhet för denna typ av testning.
# 1) Rökprovning:
När byggarna testar inledningsvis måste vi testa byggnaden noggrant. Detta kallas rökprovning. Vi måste ange om byggnaden kan testas vidare eller inte.
För att utföra validering behöver du en korrekt byggnad. Därför görs rökprovning först av testteamet. Arbetsflödet för den testade applikationen bör testas antingen med testfallet eller utan det. Testfall som täcker hela flödet är till hjälp för denna testning.
# 2) Sanity Testing:
Vid sanity-testning testas huvudfunktionerna för modulerna i applikationen som testas. Vid testning av en webbplats som har tre flikar, dvs profilskapande, utbildning, inloggning etc. i IRCTC måste huvudfunktionerna för alla dessa flikar kontrolleras utan att gå djupare.
Menyerna, undermenyerna, flikarna måste testas i alla moduler. Det är en delmängd av regressionstestning eftersom testning endast görs av huvudflödet och inte på djupet.
# 3) Regressionstest:
För varje release av projektet kan utvecklingsteamet införa vissa förändringar. Validering om de nya ändringarna som har införts inte har påverkat systemets arbetsflöde kallas regressionstestning. Endast vissa testfall som rör de nya kraven måste testas här.
Prestationskvalifikation
UAT (Test av användaracceptans):
Detta är den sista testfasen som görs för att säkerställa att systemet beter sig som krävs motsvarande de angivna kraven. Detta görs av klienten. När klienten certifierar och rensar systemtest kan produkten gå för distribution.
Alfa- och betatestning:
Alfatestning görs av utvecklarna på applikationen innan de släpps på webbplatsen för programvaruutveckling. Det involverar testning av svarta och vita lådor. Betatestning görs på kundsidan efter att produkten har utvecklats och distribuerats.
Provvalideringstestfall eller protokoll
Med min erfarenhet har jag skrivit detta protokoll för Gmail-inloggning.
Fördjupad kontroll av inloggningsfunktionen som omfattas är vad validering egentligen är. Men jag vill nämna att stilen på meningspelare som används kan helt skilja sig åt och beror på kundens krav.
oracle plsql intervjufrågor för erfarna
=> Ladda ner provvalideringsprovfall: Gmail-inloggningstestfall
Slutsats
Validering handlar om att analysera en produkts funktionalitet i detalj. Som valideringstestare måste du alltid komma ihåg att rapportera avvikelserna då och då för att uppnå optimala resultat i testningen.
Varje testfall som skrivs ska vara skarpt, koncist och förståeligt även för den vanliga mannen. Valideringstester bör säkerställa att rätt produkt utvecklas mot de angivna kraven.
Som en guide för valideringstestning har jag täckt processen associerad med validering.
Konstruktionskvalificering som innefattar valideringsplan, installationskvalificering som talar om maskinvaru-programvaruinstallationen, en operativ kvalifikation som involverar hela systemtestningen, prestandakvalificering som involverar testning av användaracceptans som ger tillstånd för produktion.
Hoppas att den här artikeln skulle ha berikat din kunskap om begreppet valideringstest !!
Rekommenderad läsning
- Bästa verktyg för testning av programvara 2021 (QA Test Automation Tools)
- Alfatestning och betatestning (En komplett guide)
- Viktiga skillnader mellan Black Box Testing och White Box Testing
- Funktionell testning mot icke-funktionell testning
- Testing Primer eBook Download
- Byggverifieringstestning (BVT-testning) Komplett guide
- Vad är systemtestning - En ultimat nybörjarguide
- Testguide för webbapplikationssäkerhet