difference between test plan
Lär dig vad som är skillnaden mellan testplan, teststrategi, testfall, testskript, testscenario och testförhållande med exempel:
Programvarutestning innehåller flera grundläggande såväl som viktiga begrepp som varje programvarutestare bör vara medveten om.
Denna artikel kommer att förklara de olika begreppen i Software Testing tillsammans med deras jämförelse.
Testplan vs Teststrategi, Testfall vs Testmanus, Testscenario vs Testförhållande och Testförfarande vs Test Suite förklaras i detalj för din enkla förståelse.
=> Klicka här för en fullständig handledningsserie för testplan
Ovanstående fråga från Sasi C. är den vanligaste frågan i vår Programvarutestningsklass och jag säger alltid till våra deltagare att vi med erfarenheten knappt märker dessa ord och att de blir en del av vårt ordförråd.
Men ofta förvirring kring dessa och i den här artikeln försöker jag definiera några vanliga termer.
Olika begrepp för testning av programvara
Nedan listas de olika begreppen för testning av programvara tillsammans med deras jämförelse.
Låt oss börja!!
Vad du kommer att lära dig:
- Skillnaden mellan testplan och teststrategi
- Skillnaden mellan testfall och testskript
- Skillnaden mellan testscenario och testförhållande
- Skillnaden mellan testförfarande och testsvit
- Slutsats
Skillnaden mellan testplan och teststrategi
Teststrategi och testplan är två viktiga dokument i testets livscykel för alla projekt. Här försöker vi ge dig en djupgående kunskap om teststrategi och testplandokument.
Testplan
En testplan kan definieras som ett dokument som definierar omfattningen, målet och metoden för att testa programvaran. Testplanen är en term och en leverans.
Testplanen är ett dokument som listar alla aktiviteter i ett QA-projekt, schemalägger dem, definierar projektets omfattning, roller och ansvarsområden, risker, inträdes- och utgångskriterier, testmål och allt annat du kan tänka dig.
Testplanen är som jag vill kalla ett ”superdokument” som listar allt som finns att veta och behöver. Snälla du kolla den här länken för mer information och ett exempel.
Testplanen kommer att utformas utifrån kraven. När du tilldelar testingenjörerna arbete av någon anledning ersätts en av testarna av en annan. Här uppdateras testplanen.
Teststrategin beskriver testmetoden och allt annat som omger den. Det skiljer sig från testplanen, i den meningen att en teststrategi bara är en delmängd av testplanen. Det är ett hardcore testdokument som i viss mån är generiskt och statiskt. Det finns också ett argument om på vilka nivåer teststrategi eller plan används - men jag ser verkligen ingen krånglig skillnad.
Exempel: Testplanen ger information om vem som ska testa vid vilken tidpunkt. Till exempel, Modul 1 kommer att testas av “X tester”. Om testaren Y av någon anledning ersätter X måste testplanen uppdateras.
Testplan Dokument
Testplan är ett dokument som ger fullständig information om testuppgifter relaterade till ett programvaruprojekt. Den innehåller detaljer som testets omfattning, testtyper, mål, testmetodik, testinsats, risker och oförutsedda utsläppskriterier, testleveranser etc. Det håller reda på möjliga tester som kommer att köras på systemet efter kodning.
Testplanen är uppenbarligen inställd på att förändras. Inledningsvis kommer ett utkast till testplan att utvecklas baserat på projektets tydlighet vid den tiden. Denna ursprungliga plan kommer att ändras när projektet fortskrider. Testlagschef eller testledare kan utarbeta testplandokumentet. Den beskriver specifikationerna och kan komma att ändras baserat på densamma.
Vad man ska testa, när man ska testa, vem som ska testa och hur man testar kommer att definieras i testplanen. Testplan sorterar ut en lista med problem, beroenden och de underliggande riskerna.
Typer av testplan
Testplaner kan vara av olika slag baserat på teststadiet. Inledningsvis kommer det att finnas en mastertestplan för hela projektgenomförandet. Separata testplaner kan skapas för specifika testtyper som systemtestning, testning av systemintegration, testning av användaraccept etc.
Ett annat tillvägagångssätt är att ha separata testplaner för funktionell och icke-funktionell testning. I denna metodprestanda kommer testningen att ha en separat testplan.
Innehållet i testplanens dokument ( IEEE-829 testplanstruktur )
bästa gratis DVD Ripper för Mac
Det är svårt att rita ett tydligt format för testplanen. Testplanformatet kan variera beroende på vilket projekt som finns. IEEE har definierat en standard för testplaner som beskrivs som IEEE-829 testplanstruktur.
Nedan hittar du IEEE-rekommendationer för ett standardinnehåll för testplanen:
- Testplanidentifierare
- Introduktion
- Testföremål
- Problem med programvarurisk
- Funktioner som ska testas
- Funktioner som inte ska testas
- Närma sig
- Kriterier för godkänd / ej godkänd artikel (eller) Kriterier för godkännande
- Avstängningskriterier och återupptagningskrav
- Testa leveranser
- Testa uppgifter
- Miljökrav
- Personal- och utbildningsbehov
- Ansvar
- Schema
- Godkännanden
Föreslagen läsning => Testplan Tutorial - En perfekt guide
Teststrategi
Teststrategi är en uppsättning riktlinjer som förklarar testdesignen och bestämmer hur testning måste göras.
Exempel: En teststrategi innehåller detaljer som ”Enskilda moduler ska testas av testteamets medlemmar”. I det här fallet spelar ingen roll vem som testar det - så det är generiskt och förändringen i teammedlemmen behöver inte uppdateras, vilket håller den statisk.
Teststrategidokument
Syftet med teststrategin är att definiera testmetoden, vilka typer av test, testmiljöer och verktyg som ska användas för testning och detaljer på hög nivå om hur teststrategin kommer att anpassas till andra processer. Teststrategidokumentet är avsett att vara ett levande dokument och kommer att uppdateras ** när vi får mer tydlighet om krav, SLA-parametrar, testmiljö och bygghanteringsmetod etc.
Teststrategi är avsedd för hela projektgruppen som består av projektsponsorer, små och medelstora företag, applikations- / integrationsutveckling, systemintegrationspartners, datakonverteringsteam, bygga / släpp ledningsgrupper som tekniska leads, arkitekturledningar och distributions- och infrastrukturteam.
** Vissa hävdar att teststrategi en gång definierad aldrig ska uppdateras. I de flesta testprojekt uppdateras det vanligtvis när projektet fortskrider.
Nedan följer de viktiga avsnitten som ett teststrategidokument bör ha:
# 1) Projektöversikt
Det här avsnittet kan börja med att ge en översikt över organisationen följt av en kort beskrivning av projektet. Det kan innehålla detaljer nedan
- Vad var behovet av projektet?
- Vilka mål kommer projektet att uppnå?
Tabell över akronymer: Det är bättre att inkludera en tabell med akronymer som dokumentläsaren kan komma på när man hänvisar till dokumentet.
# 2) Krav Räckvidd
Kravets omfattning kan inkludera applikationsomfattning och funktionellt omfång
Tillämpningsområde definierar systemet som testas och påverkan på systemet på grund av ny eller ändrad funktionalitet. Relaterade system kan också definieras.
| Systemet | Effekt (ny eller ändrad funktionalitet) | Relaterat system |
|---|---|---|
| Den beskriver hur man testar, när man testar, vem som ska testa och vad man ska testa. | Den beskriver vilken typ av teknik som ska följas och vilken modul som ska testas. | |
| System A | Nya förbättringar och buggfixar | • System B • System C |
Funktionellt omfång definierar inverkan på olika moduler inom systemet. Här kommer varje relaterat system med avseende på funktionalitet att förklaras.
| Systemet | Modul | Funktionalitet | Relaterat system |
|---|---|---|---|
| System C | Modul 1 | Funktionalitet 1 | System B |
| Funktionalitet 2 | System C |
# 3) Testnivå på hög nivå
Testplan är ett separat dokument. I teststrategin kan en högnivå testplan inkluderas. En testplan på hög nivå kan innehålla testmål och testomfång. Testomfånget bör definiera både i omfattning och utanför omfattningsaktiviteter.
# 4) Testmetod
Detta avsnitt beskriver testmetoden som kommer att följas under testets livscykel.
Enligt ovanstående diagram kommer testning att utföras i två faser, dvs. teststrategi & planering och testutförande. Teststrategi & planeringsfas kommer att vara en gång för ett övergripande program medan testgenomförandefaser upprepas för varje cykel i det övergripande programmet. Ovanstående diagram visar olika steg och leveranser (utfall) i varje fas av exekveringsmetoden.
Testmetoden bör inkludera nedanstående underavsnitt
a) Testschema: Förklara den föreslagna projekttidslinjen i detta underavsnitt
b) Funktionstestmetod: Med hjälp av detta underavsnitt får du en översikt över varje fas och respektive in- och utgångskriterier. Olika testfaser är enhetstestning, systemtestning, systemintegrationstestning, användaracceptansprovning och slut-till-slut-testning.
c) Testa nyckelindikatorer:
- Prioritering av testfall: Definiera prioriteringsmetoden för testfall så att i fall av tidsbegränsningar kan högprioritetsscenarier utföras av testgruppen. Det bör finnas en överenskommelse mellan projektets intressenter om de möjliga riskerna med att inte genomföra alla planerade scenarier.
- Defektprioritering: Defektprioriteringsstrategi är nästa ämne att täcka här. Definiera prioritetsnivå och ge beskrivningen till varje nivå som kritisk, hög, medium osv. Också
- Defekt Turnaround Time: Defektomsättningstid definieras som tiden mellan när defekten först uppstod och när defekten är fixad och kommer för en ny test. Snabb vändning säkerställer snabb testning och efterlevnad av projektets tidslinje. Definiera vändningstiden för varje defektprioritetsnivå.
| Prioritetsnivå | Defekt Turnaround Time |
|---|---|
| 1 - Kritisk | Respons tid: 2 timmar eller mindre Fix Ready for Migration: 1 arbetsdag eller mindre |
# 5) Testtäckning
Detta avsnitt beskriver de processer som QA-teamet kommer att följa för att optimera täckningen av affärs- / funktionskrav i testscenarier och testfall. Kravspårbarhetsmatris: (RTM) kan användas för att spåra alla krav med respektive testscenarier och testfall.
# 6) Testmiljö
Definiera olika tillgängliga QA-miljöer. Nämn vilka tester som kommer att göras i vilken miljö och av vem. Skapa en miljöbackup-plan för att ta hand om nödsituationer. Tillgång till varje miljö bör regleras och kallas med tydlighet.
Testverktyg som ska användas kan också nämnas i detta avsnitt.
| Aktivitet | Verktyg | Anmärkningar |
|---|---|---|
| Testhantering | HP ALM | Nämn anledningen till att du använder detta verktyg |
| Felhantering | JIRA | Nämn anledningen till att du använder detta verktyg |
# 7) QA-leveranser och mätvärden
Lista upp alla QA-leveranser
| S. nr | Levereras |
|---|---|
| ett | Teststrategidokument |
| två | Krav Spårbarhetsmatris |
| 3 | ST-testmanus |
| 4 | Testöversiktsrapport |
| 5 | Lista över scenario som är kvalificerad för automatisering |
Lista upp alla QA-mätvärden
| # | Metrisk namn | Metrisk definition | Metrisk formel | Metrisk måttenhet | Rapporter där mätvärdena ska användas |
|---|---|---|---|---|---|
| ett | Krav Täckningsvärden (RCM) | QA: s täckning av kraven | Andelen antal testade krav till # identifierade krav | % | Veckovis QA-statusrapport, Testöversiktsrapport |
| två | Test täckning | Täckningen av utfört testfall | Andel antal utförda testfall / antal planerade testfall | % | Daglig utföranderapport, Veckovis QA-statusrapport, Testöversiktsrapport |
# 8) Defekthantering
Definiera en defekthanteringsstrategi tydligt genom att skapa ett arbetsflöde för defekter, metoder för spårning av defekter och process för defektprovning. Nämn defektansvar för varje testares roller. Periodisk defektanalys och grundorsaksanalys kommer att förbättra den övergripande kvaliteten på testningen
# 9) Kommunikationshantering
Ställ in riktlinjer för statusrapporter, statusmöten och offshore-kommunikation.
# 10) Antaganden, risker och beroende
Beskriv antaganden som projektet bygger på. Dessa kan inkludera timing, resurser och systemfunktioner. Beskriv eventuella beroenden som andra projekt, tillgängligheten av tillfälliga resurser, andra tidsfrister som kan påverka projektet
# 11) Bilaga
Inkludera saker som roller och ansvar, arbetstidszon och referenser i det här avsnittet
Vidare läsning=> Guide för att skriva ett bra teststrategidokument .
Testplan mot teststrategi
| TESTPLAN | TESTSTRATEGI |
|---|---|
| Den härrör från specifikation för programvarukrav (SRS). | Det härrör från dokumentet Business Requirement (BRS). |
| Den förbereds av testledaren eller chefen. | Den utvecklas av projektledaren eller affärsanalytikern. |
| Testplan-id, funktioner som ska testas, testtekniker, testuppgifter, funktioner som passerar eller misslyckas, testleveranser, ansvar och schema etc. är komponenterna i testplanen. | Mål och omfattning, dokumentationsformat, testprocesser, teamrapporteringsstruktur, kundkommunikationsstrategi etc. är komponenterna i teststrategin. |
| Om det finns en ny funktion eller en förändring i kravet som hänt uppdateras testplandokumentet. | Teststrategin upprätthåller standarderna medan dokumentet förbereds. Det kallas också som statiskt dokument. |
| Vi kan förbereda testplanen individuellt. | I mindre projekt finns teststrategi ofta som en del av en testplan. |
| Vi kan utarbeta en testplan på projektnivå. | Vi kan använda teststrategi vid flera projekt. |
| Vi kan beskriva specifikationerna med hjälp av en testplan. | Teststrategin beskriver de allmänna metoderna. |
| Testplanen kommer att ändras under projektets gång. | Teststrategi ändras vanligtvis inte när den är godkänd. |
| Testplanen skrivs efter kravavloggning. | Teststrategi görs före testplanen. |
| Testplaner kan vara av olika slag. Det kommer att finnas en mastertestplan och en separat testplan för olika typer av tester som systemtestplan, prestandatestplan etc. | Det kommer bara att finnas ett teststrategidokument för ett projekt. |
| Testplanen ska vara tydlig och kortfattad. | Teststrategi ger övergripande vägledning för projektet. |
Skillnaden mellan dessa två dokument är subtil. En teststrategi är ett statiskt dokument på hög nivå om projektet. Å andra sidan kommer testplanen att specificera vad som ska testas, när ska testas och hur man testar.
Skillnaden mellan testfall och testskript
Enligt min mening kan dessa två termer användas omväxlande. Ja, jag säger att det inte finns någon skillnad. Testfallet är en sekvens av steg som hjälper oss att utföra ett visst test på applikationen. Testskriptet är också samma sak.
Nu finns det en tankegång att ett testfall är en term som används i den manuella testmiljön och testskript används i en automatiseringsmiljö. Detta är delvis sant på grund av testarnas komfortnivå i respektive fält och även på hur verktygen hänvisar till testerna (vissa samtalstestmanus och andra kallar dem för att testa fall).
Så i själva verket är testskript och testfall båda steg som ska utföras på en applikation för att validera dess funktionalitet antingen manuellt eller genom automatisering.
Vidare läsning=> Hur man skriver effektiva testfall? och Exempel på mall för testfall .
| TESTFALL | TESTSKRIFT |
|---|---|
| Det är basformuläret för att testa en ansökan i sekvens. | När vi har utvecklat kommer skriptet att köras flera gånger tills kravet ändras. |
| Det är steg för steg förfarande som används för att testa en ansökan | Det är en uppsättning instruktioner för att testa en applikation automatiskt. |
| Termen Testfall används i den manuella testmiljön. | Termen Test Script används i en testmiljö för automatisering. |
| Det görs manuellt. | Det görs med skriptformat. |
| Den är utvecklad i form av mallar. | Det är utvecklat i form av skript. |
| Testfallsmallen inkluderar testdräkt-ID, testdata, testförfarande, faktiska resultat, förväntade resultat etc. | I Test Scrip kan vi inte använda olika kommandon för att utveckla skript. |
| Används för att testa en applikation. | Den används också för att testa en applikation. |
| Exempel: Vi måste verifiera inloggningsknappen i en applikation, Stegen inkluderar: a) Starta applikationen. b) Kontrollera om inloggningsknappen visas eller inte. | Exempel: Vi vill klicka på en bildknapp i ett program. Manuset innehåller: a) Klicka på Bildknappen. |
Skillnaden mellan testscenario och testförhållande
Testscenario: Det är ett sätt att definiera alla möjliga sätt att testa en applikation. Det är ett enda uttalande för att täcka alla möjliga sätt att testa en ansökan.
Testvillkor: Testvillkor är specifikationen som en testare måste följa för att testa en applikation.
Detta är en pekare med en rad som testare skapar som ett första övergångssteg in i testdesignfasen. Detta är mestadels en definition av ”Vad” vi ska testa med avseende på en viss funktion. Vanligtvis matas testscenarier in för skapande av testfall.
I smidiga projekt är testscenarier de enda resultaten av testdesignen och inga testfall skrivs efter dessa. Ett testscenario kan resultera i flera tester.
Exempel på testscenarier:
- Validera om ett nytt land kan läggas till av administratören
- Validera om ett befintligt land kan raderas av administratören
- Validera om ett befintligt land kan uppdateras
Testförhållandena är å andra sidan mer specifika. Det kan grovt definieras som målet / målet för ett visst test.
Exempel på testvillkor: I exemplet ovan, om vi skulle testa scenariot 1, kan vi testa följande villkor:
- Ange landets namn som 'Indien' (giltigt) och kontrollera om landet har lagts till
- Ange en blank och kontrollera om landet blir tillagt.
- I båda fallen beskrivs de specifika uppgifterna och målet för testet är mycket mer exakt.
Vidare läsning=> 180+ exempel på testscenarier för testning av webb- och skrivbordsapplikationer.
| TESTSCENARIO | TESTVILLKOR |
|---|---|
| Det här är en rad uttalanden för att förklara vad vi ska testa. | Testvillkor beskriver huvudmålet att testa en applikation. |
| Det är en process för att testa en ansökan på alla möjliga sätt. | Testvillkor är att de statiska reglerna ska följas för att testa en ansökan. |
| Testscenarier är en input för att skapa testfall. | Det ger huvudmålet att testa en ansökan. |
| Testscenariot täcker alla möjliga fall för att testa en ansökan. | Testvillkor är mycket specifikt. |
| Det minskar komplexiteten. | Det gör ett system buggfritt. |
| Testscenariot kan vara en enda eller en grupp testfall. | Det är målet med testfall. |
| Genom att skriva scenarier blir det lätt att förstå funktionerna i en applikation. | Testvillkor är mycket specifikt. |
| Exempel på testscenarier: # 1) Validera om ett nytt land kan läggas till av administratören. # 2) Validera om ett befintligt land kan raderas av administratören. # 3) Validera om ett befintligt land kan uppdateras. | Exempel på testvillkor: # 1) Ange landets namn som 'Indien' och kontrollera om landet har lagts till. # 2) Lämna tomma fält och kontrollera om landet blir tillagt. |
Skillnaden mellan testförfarande och testsvit
Testförfarandet är en kombination av testfall baserade på en viss logisk anledning, som att utföra en end-to-end-situation eller något därtill. Ordningen i vilken testfallet ska köras är fast.
Test procedur: Det är inget annat än testets livscykel. Det finns tio steg i testets livscykel.
Dom är:
- Insatsuppskattning
- Projektinitiering
- Systemstudie
- Testplan
- Designtestfall
- Testa automatisering
- Utför testfall
- Rapportera fel
- Regressionstestning
- Analys och sammanfattningsrapport
Till exempel , om jag skulle testa sändningen av ett e-postmeddelande från Gmail.com, skulle ordningen på testfall som jag skulle kombinera för att bilda ett testförfarande vara:
- Testet för att kontrollera inloggningen
- Testet för att skriva ett e-postmeddelande
- Testet för att bifoga en / flera bilagor
- Formatera e-postmeddelandet på önskat sätt med hjälp av olika alternativ
- Lägga till kontakter eller e-postadresser i fälten Till, BCC, CC
- Skicka ett e-postmeddelande och se till att det visas i avsnittet 'Skickad e-post'
Alla testfall ovan är grupperade för att uppnå ett visst mål i slutet av dem. Testförfaranden har också några testfall kombinerade när som helst.
Testpaketet är å andra sidan listan över alla testfall som måste utföras som en del av en testcykel eller en regressionsfas etc. Det finns ingen logisk gruppering baserad på funktionalitet. Ordningen i vilken de bestående testfallen utförs kan eller inte vara viktig.
Test svit: Test Suite är en behållare som har en uppsättning tester som hjälper testarna att köra och rapportera testkörningsstatus. Det kan ta vilken som helst av de tre tillstånden, dvs. aktiv, pågår och slutförd.
Exempel på Test Suite : Om en applikations nuvarande version är 2.0. Den tidigare versionen 1.0 kan ha haft 1000 testfall för att testa den helt. För version 2 finns 500 testfall för att bara testa den nya funktionaliteten som läggs till i den nya versionen.
Så nuvarande testpaket skulle vara 1000 + 500 testfall som inkluderar både regression och den nya funktionaliteten. Sviten är också en kombination, men vi försöker inte uppnå en målfunktion.
Testsviter kan innehålla 100- eller till och med 1000-tal testfall.
| TEST PROCEDUR | TEST SVIT |
|---|---|
| Skapandet av testprocedurer baseras på testflödet från slut till slut. | Testsviter skapas baserat på cykeln eller baserat på omfattningen. |
| Det är en kombination av testfall för att testa en ansökan. | Det är en grupp testfall för att testa en ansökan. |
| Det är en logisk gruppering baserad på funktionaliteten. | Det finns ingen logisk gruppering baserat på funktionaliteten. |
| Testförfaranden är produkter som kan levereras i programvaruutvecklingsprocessen. | Det utförs som en del av testcykeln eller regressionen. |
| Körningsordningen är fast. | Ordningsföljden kanske inte är viktig. |
| Testförfarandet innehåller testfall från slut till slut. | Testpaket innehåller alla nya funktioner och regressionstestfall. |
| Testprocedurer är kodade på ett nytt språk som heter TPL (Test Procedure language). | Testpaketet innehåller manuella testfall eller automatiseringsskript. |
Slutsats
Programvarutestningskoncept spelar en viktig roll i programvarutestningens livscykel.
En tydlig förståelse av de ovan diskuterade begreppen tillsammans med deras jämförelse är mycket viktigt för varje programvarutestare att utföra testprocessen effektivt.
Vanligtvis är artiklar som dessa utmärkta utgångspunkter för djupare diskussioner. Så snälla bidra med dina tankar, överenskommelser, meningsskiljaktigheter och allt annat i kommentarerna nedan. Vi ser fram emot din feedback.
Vi välkomnar också dina frågor om programvarutestning i allmänhet eller något som har med din testkarriär att göra. Vi kommer att ta itu med dessa mer detaljerat i våra kommande inlägg i samma serie.
Glad läsning!!
=> Besök här för en komplett testplan-handledningsserie
PREV-handledning | NÄSTA självstudie
Rekommenderad läsning
- Testplan Tutorial: En guide för att skriva ett testdokument från programvara från grunden
- Hur man skriver teststrategidokument (med exempel på teststrategimall)
- Hur du förbereder dig för testfallshantering (Produktivitetstips)
- Vad är testscenario: testscenarimall med exempel
- Skillnaden mellan prestandatestplan och prestandateststrategi
- Hur man skriver testfall: Den ultimata guiden med exempel
- Exempel på programvara Testplanmall med format och innehåll
- Testscenario mot testfall: Vad är skillnaden mellan dessa?