Testplan
En testplan är ett detaljerat dokument som beskriver teststrategi, mål, schema, uppskattning, leveranser och resurser som krävs för att testa en programvaruprodukt. Testplan hjälper oss att bestämma de ansträngningar som krävs för att validera kvaliteten på applikationen som testas. Testplanen fungerar som en ritning för att genomföra programvarutestningsaktiviteter som en definierad process, som noggrant övervakas och kontrolleras av testhanteraren.
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 testplan exempel / scenario: I ett möte vill du diskutera testplanen med teammedlemmarna, men de är inte intresserade -.
I så fall, vad ska du göra? Välj ditt svar enligt följande bild
A) Jag är chef gör allt som sagt
B) OK, låt mig förklara varför vi behöver en testplan
felaktig
Som testchef måste du förklara dem vikten av testplan snarare än att tvinga teamet att göra vad du vill. Korrekt
som testchef måste du förklara dem vikten av testplan snarare än att tvinga laget att göra vad du vill.
Vad är betydelsen av testplan?
Att göra testplandokument har flera fördelar
- Hjälp människor utanför testteamet som utvecklare, affärschefer, kunder att förstå detaljerna i testningen.
- Testplan styr vårt tänkande. Det är som en regelbok som måste följas.
- Viktiga aspekter som testuppskattning, testomfång, teststrategi dokumenteras i testplan, så den kan granskas av ledningsgruppen och återanvändas för andra projekt.
Hur man skriver en testplan
Du vet redan att att göra en testplan är den viktigaste uppgiften för testhanteringsprocessen. Följ de sju stegen nedan för att skapa en testplan enligt IEEE 829
- Analysera produkten
- Designa teststrategin
- Definiera testmålen
- Definiera testkriterier
- Resursplanering
- Planera testmiljö
- Schema & uppskattning
- Bestäm testleveranser
Steg 1) Analysera produkten
Hur kan du testa en produkt utan någon information om den? Svaret är omöjligt. Du måste lära dig en produkt noggrant innan du testar den.
Produkten som testas är Guru99-bankwebbplats. Du bör undersöka kunder och slutanvändare för att känna till deras behov och förväntningar från applikationen
- Vem kommer att använda webbplatsen?
- Vad används det till?
- Hur kommer det att fungera?
- Vad är programvara / hårdvara som produkten använder?
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 http://demo.guru99.com/V4.
Du bör titta runt på denna webbplats och även granska produktdokumentationen. Granskning av produktdokumentation hjälper dig att förstå alla funktionerna på webbplatsen och hur du använder den. Om du är osäker på några föremål kan du intervjua kund, utvecklare, designer för att få mer information.
Steg 2) Utveckla teststrategi
Teststrategi är ett kritiskt steg för att göra en testplan i programvarutestning. Ett teststrategidokument är ett dokument på hög nivå som vanligtvis utvecklas av Test Manager. Detta dokument definierar:
- Projektets testmål och medel för att uppnå dem
- Bestämmer testa ansträngning och kostnader
Tillbaka till ditt projekt måste du utveckla teststrategi för att testa den bankwebbplatsen. Följ stegen nedan
Steg 2.1) Definiera testets omfattning
Innan någon testaktivitet påbörjas bör testets omfattning vara känd. Du måste tänka hårt om det.
- Komponenterna i systemet som ska testas (hårdvara, programvara, mellanprogramvara etc.) definieras som " i omfång "
- Komponenterna i systemet som inte kommer att testas måste också definieras tydligt 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 en självförtroende och exakt information om testningen du gör
- Alla projektmedlemmar kommer att ha en klar förståelse för vad som testas och vad som inte är
Hur bestämmer du omfattningen för ditt projekt?
För att bestämma omfattningen måste du -
- Exakt kundkrav
- Projektbudget
- Produktspecifikation
- Färdigheter och talang hos ditt testteam
Nu bör tydligt definiera testets "in scope" och "out of scope".
- Som programvarukravet specificerar fokuserar projektet Guru99 Bank bara på att testa alla funktioner och externa gränssnitt på webbplatsen Guru99 Bank ( i omfattningstestning )
- Icke-funktionella tester som stress , prestanda eller logisk databas testas för närvarande inte. ( utom räckvidd)
Problemscenario
Kunden vill att du ska testa hans API. Men projektbudgeten tillåter inte det. I så fall vad ska du göra?
I så fall måste du övertyga kunden om att Api Testing är extra arbete och kommer att förbruka betydande resurser. Ge honom data som stöder dina fakta. Berätta för honom om Api Testing ingår i omfattningen kommer budgeten att öka med XYZ-beloppet.
Kunden godkänner och följaktligen är de nya tillämpningsområdena utom räckvidd
- Artiklar inom ramen: Funktionell testning, Api-testning
- Utanför räckviddsposter: Databastestning, hårdvara och andra externa gränssnitt
Steg 2.2) Identifiera testtyp
En 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"
De vanligaste testtyperna beskrivs som följande bild
Det finns massor av testtyper för testning av programvara. Ditt team kan inte ha tillräckligt med ansträngningar för att hantera alla typer av tester. Som Test Manager, måste du ställa in prioritet av testtyper
- Vilka testtyper bör fokuseras för testning av webbapplikationer?
- Vilka testtyper ska ignoreras för att spara kostnader?
Vilka testtyper ska du fokusera i det här fallet?
Välj allt som gäller A) Enhetstestning B) API-testning C) Integrationstestning D) Systemtestning E) Installera / avinstallera testning F) Agil test Vi väljer bara B) API-testning C) Integrationstestning D) Systemtestning för Guru99-projekt
Steg 2.3) Dokumentera risker och problem
Risk är framtidens osäkra händelse med sannolikhet för händelse och potential för förlust. När risken faktiskt inträffar blir det " problemet".
I artikeln Riskanalys och lösning har du redan lärt dig om riskanalysen i detalj och identifierat potentiella risker i projektet.
I QA-testplanen kommer du att dokumentera dessa risker
| Risk | Mitigation |
|---|---|
| Teammedlemmen saknar de kunskaper som krävs för att testa webbplatsen. | Planera utbildningskurs för att färdigställa dina medlemmar |
| Projektplanen är för stram; det är svårt att slutföra detta projekt i tid | Ställ in testprioritet för var och en av testaktiviteterna. |
| Test Manager har dålig ledarskicklighet | Planera ledarskapsutbildning för chef |
| Brist på samarbete påverkar dina anställdas produktivitet negativt | Uppmuntra varje lagmedlem i hans uppgift och inspirera dem till större ansträngningar. |
| Fel budgetuppskattning och kostnadsöverskridande | Fastställ omfattningen innan du påbörjar arbetet, ägna stor uppmärksamhet åt projektplanering och spåra och mäta framstegen ständigt |
Steg 2.4) Skapa testlogistik
I testlogistiken bör testchefen svara på följande frågor:
- Vem ska testa?
- När kommer testet att ske?
Vem ska testa?
Du kanske inte vet exakta namn på testaren som ska testa, men typen av testare kan definieras.
För att välja rätt medlem för angiven uppgift måste du överväga om hans skicklighet är kvalificerad för uppgiften eller inte, också uppskatta projektbudgeten. Om du väljer fel medlem för uppgiften kan projektet misslyckas eller försenas .
Personen med följande färdigheter är mest idealisk för att utföra programvarutestning:
- Förmåga att förstå kundernas synvinkel
- Stark önskan om kvalitet
- Uppmärksamhet på detaljer
- Bra samarbete
I ditt projekt är den medlem som tar ansvaret för testutförandet testaren. Basera på projektbudgeten, du kan välja in-source eller outsourca medlem som testare.
När kommer testet att ske?
Testaktiviteter måste matchas med tillhörande utvecklingsaktiviteter.
Du kommer att börja testa när du har alla nödvändiga artiklar som visas i följande bild
Steg 3) Definiera testmål
Testmål är det övergripande målet och uppnåendet av testutförandet. Syftet med testningen är att hitta så många programvarufel som möjligt; se till att programvaran som testas är felfri före release.
För att definiera testmålen bör du göra två följande steg
- Lista alla programfunktioner (funktionalitet, prestanda, GUI ...) som kan behöva testas.
- Definiera testets mål eller mål baserat på ovanstående funktioner
Låt oss använda dessa steg för att hitta testmålet för ditt Guru99 Bank-testprojekt
Du kan välja ' TOP-DOWN' -metoden för att hitta webbplatsens funktioner som kan behöva testas. I den här metoden bryter du ner applikationen som testas till komponent och underkomponent .
I föregående ämne har du redan analyserat kravspecifikationerna och gått igenom webbplatsen så att du kan skapa en Mind-Map för att hitta webbplatsens funktioner som följer
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 att webbplatsens Guru99- funktionalitet (konto, insättning ...) fungerar som förväntat utan några fel eller fel i verklig affärsmiljö
- Kontrollera att webbplatsens externa gränssnitt som UI fungerar som förväntat och uppfyller kundens behov
- Verifiera webbplatsens användbarhet . Är dessa funktioner praktiska för användaren eller inte?
Steg 4) Definiera testkriterier
Testkriterier är en standard eller regel som ett testförfarande eller testbedömning kan baseras på. Det finns två typer av testkriterier som följer
Suspensionskriterier
Ange de kritiska suspensionskriterierna för ett test. Om suspensionskriterierna är uppfyllda under testningen kommer den aktiva testcykeln att avbrytas tills kriterierna har lösts .
Testplan Exempel: Om dina teammedlemmar rapporterar att det finns 40% av testfallet misslyckades, bör du avbryta testningen tills utvecklingsteamet åtgärdar alla misslyckade fall.
Utgångskriterier
Den specificerar kriterierna som betecknar en lyckad slutförande av en testfas. Utgångskriterierna är de riktade resultaten av testet och är nödvändiga innan du går vidare till nästa utvecklingsfas. Exempel: 95% av alla kritiska testfall måste klara.
Några metoder för att definiera exitkriterier är genom att ange en riktad körhastighet och pass-rate .
- Körhastighet är förhållandet mellan antal utförda testfall / totala testfall av testspecifikation. Exempelvis har testspecifikationen totalt 120 TCs, men testaren utförde bara 100 TCs, så körningshastigheten är 100/120 = 0,83 (83%)
- Godkännandegrad är förhållandet mellan antalet godkända testfall / utförda testfall . Till exempel, i över 100 TC: er som körs, finns det 80 TC: er som passerade, så passeringsgraden är 80/100 = 0,8 (80%)
Dessa data kan hämtas i testmetriska dokument.
- Körhastigheten är obligatorisk att vara 100% om inte ett tydligt skäl anges.
- Pass kurs är beroende av projektets omfattning, men att uppnå hög genomströmningen är ett mål.
Testplan Exempel: Ditt team har redan gjort testkörningarna. De rapporterar testresultatet till dig och de vill att du ska bekräfta utgångskriterierna.
I ovanstående fall är körhastigheten obligatorisk 100%, men testteamet slutförde bara 90% av testfallet. Det betyder att körhastigheten inte är nöjd, så bekräfta INTE utgångskriterierna
Steg 5) Resursplanering
Resursplan är en detaljerad sammanfattning av alla typer av resurser som krävs för att slutföra projektuppgiften. Resurserna kan vara mänskliga, utrustning och material som behövs för att slutföra ett projekt
Den resursplanering är viktig faktor för testplanering eftersom hjälper att bestämma det antal resurser (anställd, utrustning ...) som ska användas för projektet. Därför kan Test Manager göra rätt schema och uppskattning för projektet.
Detta avsnitt representerar de rekommenderade resurserna för ditt projekt.
Mänskliga resurser
Följande tabell representerar olika medlemmar i ditt projektteam
|
Nej. |
Medlem |
Uppgifter |
|---|---|---|
|
1. |
Testchef |
Hantera hela projektet Definiera projekt riktningar Skaffa lämpliga resurser |
|
2. |
Testare |
Identifiera och beskriva lämpliga testtekniker / verktyg / automatiseringsarkitektur Verifiera och bedöma testmetoden Utför testerna, logga resultat, rapportera bristerna. Testaren kan vara inhämtade eller uthyrda medlemmar, baserat på projektets budget För den uppgift som krävde låg skicklighet rekommenderar jag att du väljer outsourcade medlemmar för att spara projektkostnader. |
|
3. |
Utvecklare i test |
Implementera testfall, testprogram, testsvit etc. |
|
4. |
Testadministratör |
Byggs upp och säkerställer att testmiljö och tillgångar hanteras och underhålls Support Tester för att använda testmiljön för testkörning |
|
5. |
SQA-medlemmar |
Ta ansvar för kvalitetssäkring Kontrollera om testprocessen uppfyller specifika krav |
Systemresurs
För testning, en webbapplikation, bör du planera resurserna enligt följande tabeller:
|
Nej. |
Resurser |
Beskrivningar |
|---|---|---|
|
1. |
Server |
Installera webbapplikationen som testas Detta inkluderar en separat webbserver, databasserver och applikationsserver om tillämpligt |
|
2. |
Testverktyg |
Testverktyget är att automatisera testningen, simulera användaroperationen, generera testresultaten Det finns massor av testverktyg du kan använda för detta projekt, såsom Selen, QTP ... etc. |
|
3. |
Nätverk |
Du behöver ett nätverk med LAN och internet för att simulera den verkliga affärs- och användarmiljön |
|
4. |
Dator |
Den dator som användarna ofta använder för att ansluta webbservern |
Steg 6) Planera testmiljö
Vad är testmiljön?
En testmiljö är en installation av programvara och hårdvara som testteamet kommer att genomföra testfall. Testmiljön består av verklig affärs- och användarmiljö , samt fysiska miljöer, såsom server, frontend running-miljö.
Så här ställer du in testmiljön
Tillbaka till ditt projekt, hur ställer du in testmiljö för denna bankwebbplats?
För att slutföra denna uppgift behöver du ett starkt samarbete mellan Test Team och Development Team
Du bör ställa utvecklarna några frågor för att förstå webbapplikationen som testas tydligt . Här är några rekommenderade frågor. Naturligtvis kan du ställa de andra frågorna om du behöver.
- Vad är den maximala användaranslutningen som denna webbplats kan hantera samtidigt?
- Vad är maskinvaru- / programvarukrav för att installera den här webbplatsen?
- Behöver användarens dator någon speciell inställning för att surfa på webbplatsen?
Följande bild beskriver testmiljön på bankwebbplatsen www.demo.guru99.com/V4
Steg 7) Schema & uppskattning
I artikeln Testuppskattning har du redan använt några tekniker för att uppskatta ansträngningarna för att slutföra projektet. Nu bör du inkludera den uppskattningen samt schemat för testplaneringen
Anta att du delar upp hela projektet i små uppgifter i testuppskattningsfasen och lägger till uppskattningen för varje uppgift enligt nedan
|
Uppgift |
Medlemmar |
Uppskatta ansträngning |
|---|---|---|
|
Skapa testspecifikationen |
Testdesigner |
170 arbetstimmar |
|
Utför testkörning |
Testare, testadministratör |
80 arbetstimmar |
|
Testrapport |
Testare |
10 man-timme |
|
Testleverans |
20 arbetstimmar |
|
|
Total |
280 arbetstimmar |
Sedan skapar du schemat för att slutföra dessa uppgifter.
Att göra schema är en vanlig term inom projektledning. Genom att skapa ett gediget schema i testplaneringen kan testhanteraren använda det som verktyg för att övervaka projektförloppet, kontrollera kostnadsöverskridanden.
För att skapa projektschemat behöver Testhanteraren flera typer av inmatningar enligt nedan:
- Tidsfrist för anställd och projekt : Arbetsdagarna, deadline för projektet, tillgången på resurser är de faktorer som påverkar schemat
- Projektuppskattning : Baserat på uppskattningen vet testchefen hur lång tid det tar att slutföra projektet. Så han kan göra ett lämpligt projektschema
- Projektrisk : Att förstå risken hjälper Testchef att lägga till tillräckligt med extra tid i projektplanen för att hantera riskerna
Låt oss träna med ett exempel:
Antag att chefen vill slutföra projektet Guru99 på en månad, du har redan uppskattat ansträngningen för varje uppgift i Test Estimation. Du kan skapa schemat enligt nedan
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 testinsatsen.
Det finns olika testleveranser i varje fas av programvaruutvecklingens livscykel.
Testleveranser tillhandahålls före testfasen.
- Testplaner dokument.
- Testfallshandlingar
- Testdesignspecifikationer.
Testleveranser tillhandahålls under testningen
- Testa skript
- Simulatorer.
- Testdata
- Testa spårbarhetsmatris
- Felloggar och exekveringsloggar.
Testleveranser tillhandahålls efter att testcyklerna är över.
- Testresultat / rapporter
- Felrapport
- Riktlinjer för installation / testförfaranden
- Släpp anteckningar
Resurser
Ladda ner ett exempel på en testplanmall
Ladda ner provsystemets testplan för webbplatsen Guru99 Bank