test plan tutorial guide write software test plan document from scratch
En ultimat guide till dokument för programtestplan:
Denna handledning kommer att förklara för dig allt om Software Test Plan Document och vägleda dig om hur du skriver / skapar en detaljerad Software Testing-plan från grunden tillsammans med skillnader mellan testplanering och testutförande.
Live Project QA Training Day 3 - Efter att ha introducerat våra läsare till vår live-applikation gratis utbildning i programvarutestning online , vi fick veta hur man granskar SRS och skriver testscenarier . Och nu är det rätt tid att dyka djupare in i den viktigaste delen av programvarutestningens livscykel - dvs. Testplanering .
Lista över ALLA handledningarna i denna serie:
Testplaneringsdokument:
Handledning nr 1: Hur man skriver ett testplandokument (Denna handledning)
Handledning nr 2: Enkelt innehåll i testplanmallen
Självstudie 3: Exempel på programvarutestplan
Självstudie 4: Skillnad mellan testplan och teststrategi
Handledning nr 5: Hur man skriver teststrategidokument
Tips för testplanering:
vad är den bästa e-postleverantören
Självstudie nr 6: Riskhantering under testplanering
Handledning nr 7: Vad man ska göra när det inte finns tillräckligt med tid att testa
Självstudie 8: Hur man planerar och hanterar testprojekt effektivt
Testplanering vid olika stadier av STLC:
Handledning nr 9: Planering av regressionstest
Handledning nr 10: UAT-testplan
Handledning nr 11: Godkännandeprovplan
Testa automatiseringsplanering:
Handledning nr 12: Automation Test Plan
Handledning nr 13: ERP Application Test Planning
Handledning nr 14: HP ALM-testplanering
Handledning nr 15: Mindmap Testplanering
Handledning nr 16: JMeter Testplan och WorkBench
Vad du kommer att lära dig:
Testplanering - Den viktigaste testfasen
Denna informativa handledning kommer att förklara för dig hur och hur du skriver ett testplandokument.
I slutet av denna handledning har vi delat en 19-sidigt omfattande testplandokument som specifikt skapades för live-projektet OrangeHRM, som vi använder för detta gratis QA-träningsserie
Vad är en testplan?
Testplan är ett dynamiskt dokument . Framgången med ett testprojekt beror på ett välskrivet testplandokument som alltid är aktuellt. Testplanen är mer eller mindre som en plan för hur testaktiviteten går att ske i ett projekt.
Nedan följer några tips på en testplan:
# 1) Testplan är ett dokument som fungerar som referenspunkt och endast baseras på att testning utförs inom QA-teamet.
#två) Det är också ett dokument som vi delar med affärsanalytiker, projektledare, Dev-team och andra team. Detta bidrar till att öka nivån på öppenhet i QA-teamets arbete gentemot de externa grupperna.
# 3) Det dokumenteras av QA-chefen / QA-ledningen baserat på ingångarna från QA-teammedlemmarna.
# 4) Testplanering tilldelas vanligtvis 1/3rdav den tid som tar för hela QA-uppdraget. Den andra 1/3rdär för testdesign och resten är för testutförande.
# 5) Denna plan är inte statisk och uppdateras på begäran.
# 6) Ju mer detaljerad och omfattande planen är, desto mer framgångsrik blir testaktiviteten.
STLC-process
Vi är nu halvvägs in i vår live-projektserie. Låt oss därför ta ett steg tillbaka från applikationen och titta på STLC-processen (Software Testing Life Cycle).
STLC kan grovt delas in i 3 delar:
- Testplanering
- Testdesign
- Testutförande
I vår tidigare handledning lärde vi oss att i ett praktiskt QA-projekt började vi med SRS-granskning och testscenarioskrivning - vilket faktiskt är det andra steget i STLC-processen. Testdesignen innehåller detaljerna om vad man ska testa och hur man testar.
Varför har vi inte börjat med testplanering?
Planering är verkligen den första och främsta aktiviteten som händer i något testprojekt.
Testplanering i SDLC-faser
| SDLC-fas | Testa planeringsaktivitet |
|---|---|
| Scheman => | Test Scenario prep |
| Inleda | Helst bör QA-teamet engagera sig medan projektets omfattning samlas in från kunden / klienten i form av affärsbehov. Men i den verkliga världen är det inte så. Ur praktisk synvinkel är QA-teamets medverkan NIL. I slutet av denna fas slutförs BRD och en grundläggande projektplan skapas. |
| Definiera | SRS skapas från BRD. Testplanens ursprungliga utkast skapas. Eftersom QA-teamet inte är färdigt med SRS-granskningen, är testområdet inte klart. Så TP kommer i den här fasen endast att innehålla information om när testning ska ske, projektinformation och teaminformation (om vi har den). |
| Design | SRS-granskningen genomförs och testomfånget identifieras. Vi har mycket mer information om vad vi ska testa och en bra uppskattning av hur många testfall vi kan få etc. En andra version av testplanen skapas som innehåller all denna information. |
Från ovanstående tabell är det mycket tydligt att en testplan inte bara är ett dokument som du kan skapa på en gång och använda den från och med då.
Komponenter i ett plandokument
| Objekt i en testplanmall | Vad innehåller de? |
|---|---|
| Omfattning => | Testscenarier / testmål som kommer att valideras. |
| Utanför räckvidden => | Förbättrad tydlighet om vad vi inte ska täcka |
| Antaganden => | Alla villkor som måste vara sanna för att vi ska kunna fortsätta framgångsrikt |
| Testdokumentation - testfall / testdata / inställningsmiljö | |
| Testutförande | |
| Testcykel - hur många cyklar | |
| Start- och slutdatum för cykler | |
| Roller och ansvar => | Teammedlemmar listas |
| Vem ska göra vad | |
| modulägare listas och deras kontaktinformation | |
| Leveranser => | Vilka dokument (testartefakter) kommer att produceras vid vilka tidsramar? |
| Vad kan förväntas av varje dokument? | |
| Miljö => | Vilken typ av miljökrav finns? |
| Vem kommer att vara ansvarig? | |
| Vad ska man göra vid problem? | |
| Verktyg => | Till exempel JIRA för buggspårning |
| Logga in | |
| Hur använder jag JIRA? | |
| Defekthantering => | Vem ska vi rapportera bristerna till? |
| Hur ska vi rapportera? | |
| Vad förväntas - ger vi skärmdump? | |
| Risker och riskhantering => | Risker listas |
| Risker analyseras sannolikheten och påverkan dokumenteras | |
| Riskreducerande planer utarbetas | |
| Utgångskriterier => | När ska jag sluta testa? |
Eftersom all ovanstående information är den mest kritiska för dagligt arbete med ett QA-projekt är det viktigt att hålla plandokumentet uppdaterat då och då.
Exempel på testplandokument för ett liveprojekt
Ett exempel på ett testplanmalldokument skapas för vår “ ORANGEHRM VERSION 3.0 - MY INFO MODUL ” Projekt och bifogas nedan. Ta en titt på det. Ytterligare kommentarer har lagts till dokumentet i rött för att förklara avsnitten.
Denna testplan är för både funktionella och UAT-faser. Det förklarar också testhanteringsprocessen med HP ALM-verktyget.
Ladda ner testplanprov:
Doc-format => Klicka här för att ladda ner testplanen i Doc-format det här är det som vi skapade för OragngeHRM live-projektet och vi använder det också för vår kraschkurs för Software Testing.
PDF-format => Klicka här för att ladda ner testplanen i pdf-format .
Arbetsarkfiler (.xls) som avses i ovanstående doc / pdf-versioner => Ladda ner XLS-filer hänvisade i ovanstående testplan
Ovanstående mall är mycket omfattande och detaljerad också. Vänligen läs den noggrant för bästa resultat.
hur man lägger till ett element i en array-Java
Eftersom planen skapas och förklaras också, låt oss gå vidare till nästa fas i både SDLC och STLC.
SDLC: s kod:
Medan resten av projektet spenderade sin tid på att skapa TDD, har vi QA identifierat testomfånget (testscenarier) och skapat det första pålitliga testplanutkastet. Nästa fas av SDLC är att kontrollera när kodningen sker.
Utvecklare är den primära fokuspunkten för hela teamet i denna fas. QA-teamet njuter också av den viktigaste uppgiften som inte är annat än “Skapa testfall” .
Om testscenarierna var “What to test”, handlar testfallet om ”How to test”. Skapande av testfall är en övervägande del av testdesignfasen av STLC. Ingången för skapandet av testfall är testscenarierna och SRS-dokumentet.
För testare som oss, Testfall är den verkliga affären - det är de saker som vi tillbringar större delen av vår tid. Vi skapar dem, granskar dem, utför dem, underhåller dem, automatiserar dem - och väl, du får bilden. Oavsett hur erfaren vi är och vilken roll vi spelar i ett projekt - vi skulle fortfarande arbeta med testfallet.
Testplanering mot testutförande
Planering av programvarutest förbehåller sig en mycket bättre omfattning jämfört med STLC-fas . Leverans av kvalitetsprogramvara säkerställs av testteamet. Och vad som måste göras vid testning bestäms faktiskt i testplaneringsfasen.
Detta avsnitt ger en fullständig översikt och innehåller illustrationer om vikten av testplanering och utförande fas . Efter att ha läst detta kommer du att förstå betydelsen av planeringsfasen jämfört med genomförandefasen med mer live exempel och fallstudier för illustrationer .
Testplanering
Nedan följer vissa viktiga saker att notera under planeringen:
Att planera ett test är det viktigaste avsnittet i testcykeln. Resultatet av testfasen kommer att bestämmas av kvaliteten och omfattningen av planeringen som har gjorts för testningen.
Planering av testet sker vanligtvis under utvecklingsfasen för att spara ledtiden för testgenomförande efter ömsesidig överenskommelse från alla inblandade parter.
Några viktiga fakta att notera är:
- Planeringen måste startas parallellt med utvecklingen, förutsatt att kraven har frusits.
- Alla intressenter som designers, utvecklare, kunder och testare måste vara involverade när de slutför planen.
- Planering kan inte utarbetas för ett obekräftat eller något icke godkänt affärsbehov.
- Liknande testplaner kommer att tillämpas på de nya krav som verksamheten kommer att kräva.
Exempel 1
Utvecklingsteamet arbetar med en programvara XYZ efter att ha fått några krav från klienterna. Testteamet har nästan börjat sin förberedelse inför testdefinierings- eller planeringsfasen. Testplanering måste utformas för att tillgodose de initiala krav som citeras av kunderna. Detta har gjorts av testteamet.
Ingen av de andra intressenterna var inblandade under denna fas och planeringen har fryst.
Utvecklingsteamet har nu gjort några förändringar i affärsflödet för att ta itu med några problem i sitt arbete med kundens godkännande. Nu har programvaran kommit till testteamet för ett test. Med testplanen enligt det gamla affärsflödet har testteamet startat sin testrunda. Detta påverkade testleveranserna med många förseningar eftersom det modifierade affärsflödet inte delades med testteamet.
Observation från exempel 1:
Det finns vissa observationer från exemplet ovan.
Dom är:
- Att förstå det nya affärsflödet tog mycket tid.
- Förseningar i projektleveranser.
- Omarbetning av planering och andra uppgifter i fasen.
Alla dessa observationer måste omvandlas till väsentliga behov för en effektiv testning.
Viktiga komponenter i planeringsfasen
Nedan följer de viktigaste komponenterna som är involverade i planeringsfasen.
- Teststrategi: Detta är en av de viktigaste avsnitten som kan förklara strategin som kommer att användas under testningen.
- Testtäckning: Detta krävs i huvudsak och det kommer att göra överensstämmelsekartläggning av affärsbehov och testfall så att man kan säkerställa om hela programvaran har testats eller inte.
- Testcykler och varaktigheter: Detta kan bli mycket kritiskt beroende på utvecklingsomgångarna och deras tid för att slutföra varje omgång.
- Godkända / underkända kriterier: Det krävs i hög grad en där godkännandekriterierna definieras. Några gånger kommer detta också att definieras av klienterna.
- Affärs- och tekniska krav: Behovet av att ha programvaran och de syften de tjänar kommer att definieras tydligt tillsammans med förklaringarna på låg nivå.
Begränsningar
Det finns få saker som faktiskt kan kontrollera programvarutestningsfasen, särskilt planeringsfasen.
Följande är så få områden:
- Funktioner som ska testas och inte testas: Detta kommer tydligt att påpeka vad som måste testas och vad som inte bör vara.
- Avstängningskriterier och återupptagningskrav: Detta är beslutsfattaren för den programvara som utvecklats och kriterierna definierade för att avbryta testningen eller återuppta testningen.
- Ansvar: En testare har flera ansvarsområden för att säkerställa problem, fel och defekter i programvaran som testas. Dessutom måste buggarna valideras med utvecklarna för att de ska kunna fixa.
- Risker och oförutsedda förhållanden: Risker associerade under testningen bör tydligt nämnas och korrekta händelser under tiden måste definieras mycket tydligt.
Fallstudie nr 1
hur man skriver ut en matris i omvänd ordning java
Utvecklingsteamet från Exempel 1 planerar att släppa programvaran XYZ i två faser. Fas 1 har många funktioner som ska testas och få som inte ska testas. Återigen har programvaran släppts för att testa utan att testteamet informeras om de funktioner som ännu inte har utvecklats.
Nu startar testteamet sitt utförande baserat på testplanerna som de redan har utarbetat. De kommer med ett stort antal buggar. Och efter validering från utvecklingsteamet blir de flesta ogiltiga.
Iakttagelser från ovanstående fallstudie:
- Utvecklingsteam för att släppa programvaran till testteamet med release-anmärkningar och kravstäckningsanmärkningar (release notes)
- Funktioner som ska testas och inte testas måste tas med utifrån den släppta programvaran innan test.
- Suspension och återupptagningskriterier för testningen måste definieras korrekt.
- Risk och beredskapsplaner för programvarans otillgänglighet måste avbildas perfekt.
Läs också=> Hur man hanterar risker under testplaneringsfasen
Testutförandeplan
Genomförandet av testfall är ett av stegen i STLC-fasen. Detta måste utföras i enlighet med de planer som utarbetats tidigare. Därför fortsätter planeringen alltid att dominera hela testfasen. Nedan följer ett exempel där testteamet påverkas av förändringarna i testplanerna.
Exempel 2
Testning av programvaran A startades baserat på plan 1 utarbetad av teamet. Senare, på grund av affärsbehovet och ändringarna, måste testplanen genomgå vissa förändringar. Detta har i sin tur tvingat testfallet eller utförandet att ändras.
Observationer:
- Testplanen bestämmer utförandet av testfallet.
- Körningsdelen varierar enligt planen.
- Så länge planen och kraven är giltiga är testfallet också giltiga.
Sätt att övervinna problem under utförandet
Testare kommer oftare att stöta på olika scenarier medan de utför testkörningen. Det är då testarna måste förstå och känna till sätten att lösa problemet eller åtminstone hitta en lösning på problemet.
Exempel # 3
Under genomförandet av testfallet av programvara B stöter testteamet på flera problem. Få av dem är showproppar. De kräver att utvecklare hjälper dem att lösa problemet. Detta har hänt flera gånger och resultatet av det är en försening i att testa leveranserna.
Observationer:
- Det finns ett beroende för att övervinna miljöproblem och miljöfrågor.
- En korrekt förståelse för miljön krävs för testare.
- Ofta förekommande och kända problem måste dokumenteras för att komma över dem i framtiden.
Versionskontroll och hantering
Versionskontroll och hantering av testplaner och testfall är väldigt viktiga för att visa upp leveranser i rätt tid. Detta blir mer viktigt och görs ofta med hjälp av ett versionskontrollverktyg.
Ett verktyg för versionskontroll hjälper dem inte bara att kontrollera testplanerna utan hjälper också till att hantera fel. När det finns testprojekt med flera cykler och utgåvor kan dessa verktyg verkligen hjälpa till med att få ner mätvärdena för att stödja testleveranserna.
Läs också=> Riskhantering vid testutförandefas
Skillnaden mellan testplanering och testutförande
Följande är några viktiga områden som pekar på hur planering kommer att skilja sig från testgenomförandefasen.
| Jämförelseområde | Testplanering | Testutförande |
|---|---|---|
| Levererbar positionering | Testplanen kommer att betraktas som en viktig leverans för testaktiviteten. Detta kommer att göras som det första steget i testprocessen. | Detta kommer som en sista bänkmedlem i testfasen. Efter utförande delas defekter / felstatus tillsammans med testfallets genomförandestatus som en av testleveranserna |
| Ansvarig person | Testchefen kommer att förbereda testplanen och kommer att dela med sig till alla intressenter för sin granskning. | Detta görs normalt genom att testa med tanke på att de förberedda testfallet har godkänts och undertecknats. |
| Huvudfokus | Testplanens fokusområden är hur testningen ska genomföras, vad som ska beaktas och vad man inte ska, miljö som kan användas, testscheman etc. | Testkörningen fokuserar främst på utförandet av testfallet som ska testas på programvaran. |
| Återkommande eller iterativt läge | Detta är en engångsaktivitet. Med detta sagt kan det behöva modifieringar eller inte för framtida versioner av programvaran. | Det finns tre delar inom detta område när vi pratar om iteration. 1. Funktionell testning. 2. Regressionstest. 3. Omprövning. |
| Ingångar | Ingångarna för att skapa en testplan krävs verkligen och ska tillhandahållas av affärsanalytiker, arkitekt, kunder etc., | Testfallsdokumentet är den viktigaste inmatningen. |
| Period då den kan startas | Det måste startas tillsammans med utvecklingscykeln för effektivt resultat och för att spara tid. Men det finns få modeller som vattenfallsmodell där i testfasen startar först efter att utvecklingsfasen har slutförts. | Exekvering måste startas strikt efter att utvecklingen av programvaran har gjorts. |
| Stängningsperiod | Testplanen har ingen sådan avslutningsperiod. Vanligtvis kommer en avregistrering från alla intresserade parter för programvaran att tillhandahållas. | Utförande för en specifik release eller cykel anses vara avslutad när alla testfall har utförts mot programvaran. |
| Verktygsanvändning | Det kommer inte att användas många verktyg eftersom planeringsaktiviteten kommer att vara mer av diskussion och dokumentation. För att hålla reda på alla ändringar i planen använder testcheferna normalt alla versionskontrollverktyg som VSS eller något annat. | Det beror på exekveringssättet. Vid manual kommer inget verktyg att användas för körning. Men för att logga defekterna och hantera kommer vissa verktyg att användas. Vid automatiseringstestning kommer körningen att ske med hjälp av verktyg som QTP, SELENIUM etc. |
| Effekter på leveranserna | Detta kommer att påverka alla testfaser på ett större sätt | Detta kommer att påverka den efterföljande cykeln eller release som ska testas. |
Ovanstående illustrationer kan ha förklarat i bättre form över vikten av testplaneringsaktiviteter än för testgenomförande. På något sätt är genomförandefasen en slags delmängd av testplanen.
Baserat på teststrategin, tillvägagångssättet och de andra sakerna har testplanen högre sannolikhet att bli modifierad för att ge utrymme för förändringarna. Det är en bestämd sak att utförandet av test beror på testfallet. Testfall baseras på planerna. Därför kommer planförändringar att säkerställa förändringar i testfallet.
Omvänt behöver ändringar i testfall inte obligatoriskt leta efter förändringar. Detta är en av de främsta anledningarna till att planeringen håller jämna steg med testgenomförandefasen.
Vår kommande handledning kommer att förklara för dig mer om hur du skapar testfall? Vad är dem? Och hur vi kan få dem att fungera för oss tillsammans med olika andra aspekter relaterade till testfallet.
NÄSTA självstudie=> QA Training Day-4: Skriva testfall från SRS-dokument
Är du expert på att skriva ett testplandokument? Då är det här rätt plats att dela dina värdefulla tips för förbättringar för de kommande testarna. Uttryck gärna med oss i kommentarfältet nedan !!
Rekommenderad läsning
- Exempel på programvara Testplanmall med format och innehåll
- Dokumentationsguide för programvarutestning (varför det är viktigt)
- QA-programvarutestningsresurser och nedladdningar
- Exempel på testplandokument (Exempel på testplan med information om varje fält)
- Testkörning vid programvarutestning: Exakt process och plan med exempel
- Hur man skriver teststrategidokument (med exempel på teststrategimall)
- Skriva testfall från SRS-dokument (DOWNLOAD Live Project Exempel på testfall)
- Kursplan för programvarutestning - Detaljerad träningsplan för online-kurs