TESTPLAN i mjukvarutestning (exempel)

Testplan

A Testplan är ett detaljerat dokument som beskriver teststrategi, mål, schema, uppskattning, leveranser och resurser som krävs för att utföra tester av en programvaruprodukt. En testplan hjälper oss att fastställa den ansträngning som krävs för att validera kvaliteten på den applikation som testas. Testplanen fungerar som en ritning för att genomföra programvarutestningsaktiviteter som en definierad process, som noggrant övervakas och kontrolleras av testledaren.

Enligt ISTQB:s definition: ”Testplan är ett dokument som beskriver omfattning, tillvägagångssätt, resurser och schema för avsedda testaktiviteter.”

Låt oss börja med följande exempel/scenario på en testplan: I ett möte vill du diskutera testplanen med teammedlemmarna, men de är inte intresserade.

Vad ska du göra i ett sådant fall? Välj ditt svar enligt följande figur.

👉 Anmäl dig till gratis live-mjukvarutestningsprojekt

Vad är vikten av en testplan?

Att skapa ett testplandokument har flera fördelar.

• Hjälpa personer utanför testteamet, såsom utvecklare, affärschefer och kunder, förstå detaljerna i testet.
• Testplan Guider vårt tänkande. Det är som en regelbok som måste följas.
• Viktiga aspekter som testuppskattning, testomfattning, Teststrategi är dokumenterat i testplanen, så att den kan granskas av ledningsgruppen och återanvändas för andra projekt.

Typer av testplaner

Det finns tre huvudtyper av Testplaner inom mjukvarutestning.

1. Huvudtestplan: Ett övergripande dokument som beskriver den övergripande teststrategin, omfattningen, resurserna och schemat för alla testnivåer. Det fungerar som projektets huvudfärdplan.
2. Nivåspecifik testplan: Fokuserar på specifika testnivåer såsom enhets-, integrations-, system- eller acceptanstestning. Varje plan specificerar tillvägagångssättet, miljön och resultaten för den nivån.
3. Typspecifik testplan: Targets specialiserade testtyper som prestanda-, säkerhets-, användbarhets- eller automatiseringstestning. Den definierar verktyg, tekniker och kriterier som är unika för den testtypen.

Tillsammans säkerställer dessa testplaner omfattande täckning, anpassar testmål till projektmål och förbättrar samordningen mellan team för högre programvarukvalitet.

Hur man skriver en testplan

Du vet redan att göra en Testplan är den viktigaste uppgiften för TesthanteringsprocessFölj de sju stegen nedan för att skapa en testplan enligt IEEE 829

1. Analysera produkten
2. Designa teststrategin
3. Definiera testmålen
4. Definiera testkriterier
5. Resursplanering
6. Planera testmiljö
7. Schema & uppskattning
8. Bestäm testleveranser

Steg 1) Analysera produkten

Hur kan du testa en produkt utan någon information om det? Svaret är OmöjligtDu måste lära dig en produkt grundligt innan du testar det.

Produkten som testas är bankwebbplatsen Guru99. Du bör undersöka kunder och slutanvändare för att förstå deras behov och förväntningar på applikationen.

• Vem kommer att använda webbplatsen?
• Vad används det till?
• Hur kommer det att fungera?
• Vilken programvara/hårdvara använder produkten?

Du kan använda följande metod för att analysera webbplatsen.

Låt oss nu tillämpa ovanstående kunskap på en riktig produkt: Analysera bankwebbplatsen https://demo.guru99.com/V4.

Du borde ta en se sig om denna webbplats och även översyn produktdokumentation. Review av produktdokumentation hjälper dig att förstå alla funktioner på webbplatsen samt hur du använder den. Om du är otydlig om några saker, kan du intervjun kund, utvecklare, designer för att få mer information.

Steg 2) Utveckla teststrategi

Teststrategi är en kritiskt steg vid utformning av en testplan inom mjukvarutestning. Ett teststrategidokument är ett övergripande dokument som vanligtvis utvecklas av testledaren. Detta dokument definierar:

• Projektets testmål och medlen för att uppnå dem
• Bestämmer testning ansträngning och kostnader

Tillbaka till ditt projekt, du behöver utveckla en teststrategi för att testa den bankwebbplatsen. Du bör följa stegen nedan.

Steg 2.1) Definiera omfattning av testning

Innan någon testaktivitet påbörjas bör testningens omfattning vara känd. Du måste noga tänka igenom det.

• Komponenterna i systemet som ska testas (hårdvara, programvara, mellanprogramvara etc.) definieras som "inom omfattning"
• De komponenter i systemet som inte kommer att testas måste också tydligt definieras som "utanför räckvidden."

Att definiera omfattningen av ditt testprojekt är mycket viktigt för alla intressenter. En exakt omfattning hjälper dig.

• Ge alla förtroende och korrekt information om testerna du gör.
• Alla projektmedlemmar kommer att ha en klar förståelse för vad som testas och vad som inte testas.

Hur bestämmer du omfattningen av ditt projekt?

För att bestämma omfattningen måste du –

• Exakt kundkrav
• Projektbudget
• Produktspecifikation
• Färdigheter och talang hos ditt testlag

Nu bör den tydligt definiera vad som är "inom testningens omfattning" och "utanför testningens omfattning".

• Som mjukvarukravet specifikationer, projektet Guru99 Bank fokuserar bara på att testa alla funktioner och externt gränssnitt för webbplatsen Guru99 Bank (i omfattning testning)
• Icke-funktionell testning som t.ex stress, prestation or logisk databas kommer inte att testas. (ut ur omfattning)

Problemscenario

Kunden vill att du ska testa hans API. Men projektets budget tillåter inte det. Vad ska du göra i så fall?

I ett sådant fall måste du övertyga kunden om att Api-testning är extra arbete och kommer att förbruka betydande resurser. Ge honom data som stöder dina fakta. Säg att om API-testning ingår i omfattningen kommer budgeten att öka med XYZ-belopp.

Kunden godkänner, och följaktligen är de nya omfattningarna, artiklar som inte ingår i omfattningen,

• Artiklar som omfattas: funktions~~POS=TRUNC, Api-testning
• Objekt utanför omfattningen: Databastestning, hårdvara och andra externa gränssnitt

Steg 2.2) Identifiera testtyp

A Testtyp är ett standardtestförfarande som ger ett förväntat testresultat.

Varje testtyp är formulerad för att identifiera en specifik typ av produktfel. Men alla testtyper syftar till att uppnå ett gemensamt mål: "Tidig upptäckt av alla defekter innan produkten släpps till kunden”

Ocuco-landskapet vanligen använd Testtyperna beskrivs enligt följande i figuren

ikon massor av testtyper för att testa en mjukvaruprodukt. Ditt team kan inte lägga tillräckligt med ansträngning för att hantera alla typer av tester. Som testledare måste du ställa in prioritet av testtyperna

• Vilka testtyper ska vara fokuserade på för testning av webbapplikationer?
• Vilka testtyper ska vara ignoreras för att spara kostnader?

Steg 2.3) Dokumentera risker och problem

Risk är en framtid osäker händelse med en sannolikhet för förekomst och en potentiell för förlust. När risken faktiskt inträffar blir den 'utfärda'.

I artikeln Riskanalys och lösning, du har redan lärt dig om "risk"-analysen i detalj och identifierat potentiella risker i projektet.

I QA-testplanen kommer du att dokumentera dessa risker

Risk	Mitigation
Teammedlemmarna saknar de kunskaper som krävs för testning av webbplatser.	Planera a träningskurs att skickliga dina medlemmar
Projektschemat är för snävt; det är svårt att slutföra det här projektet i tid	uppsättning Testprioritet för var och en av testaktiviteterna.
Testchefen har dåliga ledaregenskaper	Plan ledarskapsträning för chefen
Brist på samarbete påverkar dina anställdas produktivitet negativt	Uppmuntra varje teammedlem i sin uppgift, och inspirera dem till större ansträngningar.
Fel budgetuppskattning och kostnadsöverskridanden	Upprätta omfattning innan arbetet påbörjas, ägna stor uppmärksamhet åt projektplaneringen och ständigt följa och mäta framstegen

Steg 2.4) Skapa testlogistik

I Testlogistik ska testchefen svara på följande frågor:

• Vem arbetar ska testa?
• När kommer testet att ske?

Vem ska testa?

Du kanske inte vet de exakta namnen på testarna som ska testa, men typ av testare kan definieras.

För att välja rätt medlem för en specifik uppgift måste du överväga om deras kompetens är kvalificerad för uppgiften eller inte, och även uppskatta projektets budget. Att välja fel medlem för uppgiften kan leda till att projektet slutar fungera. misslyckas or vara försenad.

En person med följande färdigheter är idealisk för att utföra mjukvarutestning:

• Förmåga att förstå kundens synvinkel
• Starkt lust för kvalitet
• Uppmärksamhet till detaljer
• bra samarbete

I ditt projekt är den medlem som kommer att ansvara för testkörningen ProvarenBaserat på projektets budget kan du välja en intern eller extern medlem som testare.

När kommer testet att ske?

Testaktiviteter ska matchas med tillhörande utvecklingsaktiviteter.

Du börjar testa när du har alla nödvändiga artiklar visas i följande figur.

Steg 3) Definiera testmål

Testmålet är det övergripande målet och uppnåendet av testkörningen. Målet med testningen är att hitta så många programvarufel som möjligt; säkerställa att programvaran som testas är buggfri före utsläpp.

För att definiera testmålen bör du utföra följande två steg

1. Lista alla programvarufunktioner (funktionalitet, prestanda, GUI…) som kan behöva testas.
2. Definiera mål eller Målet av testet baserat på ovanstående funktioner

Låt oss tillämpa dessa steg för att hitta testmålet för ditt Guru99 Bank-testprojekt

Du kan välja 'UPPFRI OCH NER' metod för att hitta webbplatsens funktioner som kan behöva testas. I den här metoden delar du upp applikationen som testas i komponenter och delkomponenter.

I föregående avsnitt har du redan analyserat kravspecifikationerna och gått igenom webbplatsen, så du kan skapa en Mind-Map för att hitta webbplatsens funktioner enligt följande:

Denna figur visar alla funktioner som Guru99-webbplatsen kan ha.

Baserat på ovanstående funktioner kan du definiera testmålet för projektet Guru99 enligt följande:

• Kontrollera om webbplatsen Guru99 funktionalitet(Konto, Insättning…) fungerar som förväntat utan några fel eller buggar i den verkliga affärsmiljön
• Kontrollera att webbplatsens externa gränssnitt, t.ex. UI, fungerar som förväntat och uppfyller kundens behov
• Verifiera användbarhet av webbplatsen. Är dessa funktioner praktiska för användaren eller inte?

Steg 4) Definiera testkriterier

Testkriterier är en standard eller regel som en testprocedur eller ett testbedömningsresultat kan baseras på. Det finns två typer av testkriterier enligt följande:

Suspensionskriterier

Ange de kritiska avstängningskriterierna för ett test. Om suspensionskriterierna uppfylls under testningen kommer den aktiva testcykeln att vara suspenderades tills kriterierna är löst.

Exempel på testplan: Om dina teammedlemmar rapporterar att 40% av testfall misslyckades bör du uppskjuta testa tills utvecklingsteamet fixar alla misslyckade fall.

Utgångskriterier

Den specificerar kriterierna som betecknar a framgångsrik slutförandet av en testfas. Utgångskriterierna är de målinriktade resultaten av testet och är nödvändiga innan man går vidare till nästa utvecklingsfas. Exempel: 95% av alla kritiska testfall måste klara.

Vissa metoder för att definiera exitkriterier är genom att ange ett mål körhastighet och passeringsgrad.

• Löphastigheten är förhållandet mellan antal körda testfall och/totalt antal testfall i testspecifikationen. Till exempel har testspecifikationen totalt 120 TC:er, men testaren körde bara 100 TC:er, så körningsfrekvensen är 100/120 = 0.83 (83 %)
• Genomströmningsprocenten är förhållandet mellan antal godkända testfall / antal utförda testfallTill exempel, av de ovanstående 100 exekverade TC:erna, finns det 80 TC:er som godkänts, så godkännandefrekvensen är 80/100 = 0.8 (80%)

Dessa data kan hämtas i Test Metric-dokument.

• Körning kursen är obligatorisk 100% om inte ett tydligt skäl ges.
• Pass priset är beroende av projektets omfattning, men uppnå en hög andel godkända är ett mål.

Exempel på testplan:Ditt team har redan gjort testkörningarna. De rapporterar testresultatet till dig och de vill att du ska bekräfta Utgångskriterier.

I ovanstående fall är körhastigheten obligatorisk och är 100%, men testteamet slutförde bara 90 % av testfallen. Det betyder att körningsfrekvensen inte är uppfylld, så bekräfta INTE avslutningskriterierna.

Steg 5) Resursplanering

En resursplan är en detaljerad sammanfattning av alla typer av resurser som krävs för att slutföra en projektuppgift. Resurser kan vara mänskliga resurser, utrustning och material som behövs för att slutföra ett projekt.

Resursplanering är en viktig faktor i testplaneringen eftersom den hjälper till med bestämmande d antal av resurser (anställda, utrustning…) som ska användas för projektet. Därför kan testledaren göra rätt tidsplan och uppskattning för projektet.

Det här avsnittet representerar de rekommenderade resurserna för ditt projekt.

Mänsklig resurs

Följande tabell representerar olika medlemmar i ditt projektteam

Nej.	Medlem	Uppgifter
1.	Test Manager	hantera hela projektet Definiera projekt riktningar Skaffa lämpliga resurser
2.	Testare	Identifiera och beskriva lämpliga testtekniker/verktyg/automationsarkitektur Verifiera och utvärdera testmetoden Utförande testerna, log resultat, och rapport defekterna. Testaren kan vara internt anlitade eller outsourcade medlemmar, baserat på projektets budget. För den uppgift som kräver låg skicklighet, jag rekommenderar att du väljer utlagd medlemmar till spara projektkostnad.
3.	Utvecklare i test	Implementera testfallen, testprogrammet, testsviten etc.
4.	Testadministratör	Bygger upp och säkerställer Testmiljö och tillgångar är förvaltade och hållna Supporttestare att använda testmiljön för testkörning
5.	SQA medlemmar	Ta ansvar för kvalitetssäkringen. Kontrollera om testprocessen uppfyller de angivna kraven

Systemresurs

För att testa en webbapplikation bör du planera resurserna enligt följande:

Nej.	Resurser	Descriptjoner
1.	server	Installera webbapplikationen som testas. Detta inkluderar en separat webbserver, databasserver och applikationsserver, om tillämpligt.
2.	Testverktyg	Testverktyget ska automatisera testningen, simulera användaroperationen och generera testresultaten. Det finns massor av testverktyg du kan använda för det här projektet, till exempel Selenium, QTP, etc.
3.	nätverks	Du behöver ett nätverk, inklusive LAN och internet, för att simulera den verkliga affärs- och användarmiljön
4.	Dator	Den dator som användare ofta använder för att ansluta till webbservern

Steg 6) Planera testmiljö

Vad är testmiljön

En testmiljö är en uppsättning av programvara och hårdvara som testteamet ska köra testfall på. Testmiljön består av en verkliga affärer och användare miljö, såväl som fysiska miljöer, såsom en server och en frontend-miljö.

Hur man konfigurerar testmiljön

Tillbaka till ditt projekt, hur sätter du upp en testmiljö för denna bankwebbplats?

För att slutföra denna uppgift behöver du starkt samarbete mellan testteamet och utvecklingsteamet.

Du bör ställa några frågor till utvecklaren för att förstå webbapplikationen som testas klartHär är några rekommenderade frågor. Självklart kan du ställa de andra frågorna om du behöver.

• Vad är det maximala antalet användaranslutningar som den här webbplatsen kan hantera samtidigt?
• Vilka är hårdvaru-/programvarukraven för att installera den här webbplatsen?
• Behöver användarens dator några särskilda inställningar för att surfa på webbplatsen?

Följande figur beskriver testmiljön för bankwebbplatsen https://demo.guru99.com/V4

Steg 7) Schema och uppskattning

I artikeln Testuppskattning, du har redan använt några tekniker för att uppskatta arbetsinsatsen för att slutföra projektet. Nu bör du inkludera den uppskattningen såväl som tidsplanen i testplaneringen.

I testuppskattningsfasen, anta att du delar upp hela projektet i mindre uppgifter och lägger till uppskattningen för varje uppgift enligt följande

uppgift	Medlemmar	Uppskatta ansträngning
Skapa testspecifikationen	Testdesigner	170 mantimmar
Utför testkörning	Testare, testadministratör	80 mantimmar
Testrapport rapport~~POS=HEADCOMP	Testare	10 mantimmar
Provleverans		20 mantimmar
Totalt		280 mantimmar

Sedan skapar du tidtabellen för att slutföra dessa uppgifter.

Att skapa ett schema är en vanlig term inom projektledning. Genom att skapa ett gediget schema i testplaneringen kan testledaren använda det som ett verktyg för att övervaka projektets framsteg och kontrollera kostnadsöverskridanden.

För att skapa projektets schema behöver testledaren flera typer av input enligt följande:

• Deadline för anställd och projektArbetsdagar, projektets deadline och resurstillgänglighet är de faktorer som påverkar schemat
• ProjektuppskattningBaserat på uppskattningen vet testledaren hur lång tid det tar att slutföra projektet. Så hen kan göra en lämplig projektplan.
• ProjektriskAtt förstå risken hjälper testledaren att lägga till tillräckligt med extra tid i projektschemat för att hantera riskerna.

Låt oss öva med ett exempel:

Anta att chefen vill slutföra projektet Guru99 in ett månad, och du har redan uppskattat arbetsinsatsen för varje uppgift i Testuppskattning. Du kan skapa schemat enligt följande

Steg 8) Testa leveranser

Testleveranser är en lista över alla dokument, verktyg och andra komponenter som måste utvecklas och underhållas för att stödja testarbetet.

Det finns olika testresultat i varje fas av livscykel för mjukvaruutveckling.

Testleveranser tillhandahålls innan testfasen.

• Dokument för testplaner.
• Dokument för testfall
• Testdesignspecifikationer.

Testleveranser tillhandahålls under testet

• Testa skript
• Simulatorer.
• Testdata
• Testa spårbarhetsmatrix
• Felloggar och exekveringsloggar.

Testleveranser tillhandahålls efter testcykeln är över.

• Testresultat/rapporter
• Felanmälan
• Riktlinjer för installation/testprocedurer
• Release anteckningar

Vanliga utmaningar i testplanering (och deras lösningar)

Effektiv testplanering möter ofta praktiska hinder. Att inse dessa utmaningar och tillämpa proaktiva lösningar säkerställer smidigare utförande och högre programvarukvalitet.

1. Oklara krav
   Utmaning: Tvetydiga eller förändrade projektkrav leder till ofullständig testtäckning.
   Lösning: Genomför kravgenomgångar och upprätthåll en spårbarhetsmatris för levnadskrav.
2. Begränsade resurser
   Utmaning: Otillräckliga verktyg, tid eller skickliga testare påverkar testkvaliteten.
   Lösning: Prioritera kritiska testfall och utnyttja automatisering för repetitiva uppgifter.
3. Orealistiska deadlines
   Utmaning: Snabba scheman minskar tiden för korrekt testdesign och -utförande.
   Lösning: Använd uppskattningstekniker och kommunicera risker tidigt till intressenter.
4. Dålig kommunikation
   Utmaning: Felaktig samordning mellan team orsakar förseningar och omarbete.
   Lösning: Implementera regelbundna synkroniserade möten och delade dashboards för transparens.
5. Otillräcklig riskhantering
   Utmaning: Att ignorera potentiella risker kan spåra ur projektets tidslinjer.
   Lösning: Identifiera risker tidigt, för en risklogg och planera strategier för att minska riskerna.

Vanliga frågor: