test plan tutorial guide write software test plan document from scratch
En ultimativ guide til software testplan dokument:
Denne vejledning forklarer alt om softwaretestplandokument og guider dig med måderne til, hvordan du skriver / opretter en detaljeret softwaretestplan fra bunden sammen med forskelle mellem testplanlægning og testudførelse.
Live Project QA træningsdag 3 - Efter at have introduceret vores læsere til vores live applikation gratis online Software Testing Training , fik vi at vide hvordan man gennemgår SRS og skriver testscenarier . Og nu er det det rigtige tidspunkt at dykke dybere ned i den vigtigste del af softwaretestens livscyklus - dvs. Testplanlægning .
Liste over ALLE vejledninger i denne serie:
Testplanlægningsdokument:
Tutorial # 1: Sådan skriver du et testplandokument (Denne vejledning)
Tutorial # 2: Simpelt indhold til skabelon til testplan
Tutorial # 3: Eksempel på softwaretestplan
Tutorial # 4: Forskel mellem testplan og teststrategi
Tutorial # 5: Sådan skriver du teststrategidokument
Tip til planlægning af test:
Tutorial # 6: Risikostyring under testplanlægning
Tutorial # 7: Hvad skal jeg gøre, når der ikke er nok tid til at teste
Tutorial # 8: Sådan planlægges og styres testprojekter effektivt
Testplanlægning på forskellige stadier af STLC:
Tutorial # 9: Planlægning af regressionstest
Tutorial # 10: UAT testplan
Tutorial # 11: Accept testplan
Test automatiseringsplanlægning:
Tutorial # 12: Automatiseringstestplan
Vejledning nr. 13: ERP-applikationstestplanlægning
Tutorial # 14: HP ALM-testplanlægning
Tutorial # 15: Mindmap-testplanlægning
Tutorial # 16: JMeter Testplan og WorkBench
Hvad du lærer:
top videospilvirksomheder at arbejde for
Oprettelse af testplan - Den vigtigste testfase
Denne informative vejledning forklarer dig de måder og procedurer, der er involveret i at skrive et testplandokument.
I slutningen af denne vejledning har vi delt en 19-siders omfattende testplan dokument som blev oprettet specifikt til live-projektet OrangeHRM, som vi bruger til dette gratis QA træningsserie
Hvad er en testplan?
Testplan er et dynamisk dokument . Succesen med et testprojekt afhænger af et velskrevet testplandokument, der til enhver tid er aktuelt. Testplan er mere eller mindre som en plan for, hvordan testaktiviteten kører at finde sted i et projekt.
Nedenfor er et par tip til en testplan:
# 1) Testplan er et dokument, der fungerer som referencepunkt og kun er baseret på, at test udføres inden for QA-teamet.
#to) Det er også et dokument, som vi deler med forretningsanalytikere, projektledere, Dev-teamet og de andre teams. Dette hjælper med at forbedre niveauet af gennemsigtighed i QA-teamets arbejde over for de eksterne teams.
# 3) Det er dokumenteret af QA manager / QA lead baseret på input fra QA teammedlemmer.
# 4) Testplanlægning tildeles typisk 1/3rdaf den tid, der tager for hele QA-engagementet. Den anden 1/3rder til testdesign, og resten er til testudførelse.
# 5) Denne plan er ikke statisk og opdateres efter behov.
# 6) Jo mere detaljeret og omfattende planen er, jo mere vellykket bliver testaktiviteten.
STLC-proces
Vi er nu halvvejs inde i vores live projektserie. Lad os derfor tage et skridt tilbage fra applikationen og se på Software Testing Life Cycle (STLC) processen.
STLC kan groft opdeles i 3 dele:
- Testplanlægning
- Test design
- Testudførelse
I vores tidligere tutorial lærte vi at vide, at vi i et praktisk QA-projekt startede med SRS-gennemgang og testscenarioskrivning - hvilket faktisk er 2. trin i STLC-processen. Testdesignet involverer detaljerne om, hvad man skal teste, og hvordan man tester.
Hvorfor er vi ikke startet med testplanlægning?
Planlægning er faktisk den først og fremmest aktivitet, der sker i ethvert testprojekt.
Testplanlægning i SDLC-faser
| SDLC-fase | Test planlægningsaktivitet |
|---|---|
| Tidsplaner> | Test scenarieforberedelse |
| Igangsætte | Ideelt set bør QA-team involvere sig, mens projektets omfang er samlet fra kunden / klienten i form af forretningskrav. Men i den virkelige verden er det ikke tilfældet. Fra et praktisk synspunkt er inddragelsen af QA-teamet NIL. I slutningen af denne fase afsluttes BRD, og der oprettes en grundlæggende projektplan. |
| Definere | SRS oprettes fra BRD. Testplanens oprindelige kladde oprettes. På dette tidspunkt, da QA-teamet ikke er færdig med SRS-gennemgangen, er omfanget af test ikke klart. Så TP i denne fase vil kun indeholde oplysninger om, hvornår test skal ske, projektinformation og teaminformation (hvis vi har det). |
| Design | SRS-gennemgangen gennemføres, og testomfanget identificeres. Vi har meget mere information om, hvad vi skal teste, og et godt skøn over, hvor mange testsager vi kan få osv. Der oprettes en anden version af testplanen, der indeholder alle disse oplysninger. |
Fra ovenstående tabel er det meget klart, at en testplan ikke kun er et dokument, som du kan oprette på én gang og bruge den fra da af.
Komponenter i et plandokument
| Varer i en testplanskabelon | Hvad indeholder de? |
|---|---|
| Omfang => | Testscenarier / testmål, der valideres. |
| Uden for anvendelsesområdet => | Forbedret klarhed om, hvad vi ikke skal dække |
| Antagelser => | Alle de betingelser, der er nødvendige for, at vi kan fortsætte med succes |
| Testdokumentation - test tilfælde / testdata / opsætningsmiljø | |
| Testudførelse | |
| Testcyklus - hvor mange cykler | |
| Start- og slutdato for cyklusser | |
| Roller og ansvar => | Teammedlemmer er anført |
| Hvem skal gøre hvad | |
| modulsejere er angivet og deres kontaktoplysninger | |
| Leverancer => | Hvilke dokumenter (testartefakter) vil producere på hvilke tidsrammer? |
| Hvad kan man forvente af hvert dokument? | |
| Miljø => | Hvilke miljøkrav findes der? |
| Hvem har ansvaret? | |
| Hvad skal jeg gøre i tilfælde af problemer? | |
| Værktøjer => | For eksempel JIRA til sporing af fejl |
| Log på | |
| Hvordan bruges JIRA? | |
| Fejlhåndtering => | Hvem skal vi rapportere om manglerne til? |
| Hvordan skal vi rapportere? | |
| Hvad forventes - giver vi screenshot? | |
| Risici og risikostyring => | Risici er angivet |
| Risici analyseres sandsynligheden for, og virkningen dokumenteres | |
| Risikoreducerende planer udarbejdes | |
| Udgangskriterier => | Hvornår skal man stoppe med at teste? |
Da al den ovennævnte information er den mest kritiske for dagligt arbejde med et QA-projekt , er det vigtigt at holde plandokumentet opdateret nu og da.
Eksempel på testplandokument til et live projekt
Et eksempel på et testplan skabelondokument oprettes til vores “ ORANGEHRM VERSION 3.0 - MIN INFO-MODUL ” Projekt og vedhæftet nedenfor. Se det venligst. Yderligere kommentarer er tilføjet til dokumentet i rødt for at forklare sektionerne.
Denne testplan er for både funktionelle såvel som UAT-faser. Det forklarer også teststyringsprocessen ved hjælp af HP ALM-værktøjet.
Download testplaneksempel:
Doc-format => Klik her for at downloade testplanen i Doc-format dette er den, vi oprettede til OragngeHRM live-projektet, og vi bruger dette også til vores softwaretest crash-kursus.
PDF-format => Klik her for at downloade testplanen i pdf-filformat .
Arbejdsarkfiler (.xls), der er henvist til i ovenstående doc / pdf-versioner => Download XLS-filer henvist i ovenstående testplan
Ovenstående skabelon er meget omfattende og også en detaljeret. Derfor bedes du læse det grundigt for de bedste resultater.
Da planen også oprettes og forklares godt, lad os gå videre til næste fase i både SDLC og STLC.
SDLC's kode:
Mens resten af projektet brugte sin tid på TDD-oprettelse, har vi QA'er identificeret testområdet (testscenarier) og oprettet det første pålidelige testplanudkast. Den næste fase af SDLC er at kontrollere, hvornår kodningen opstår.
Udviklere er det primære fokuspunkt for hele teamet i denne fase. QA-team forkæler også den mest vigtige opgave, som ikke er andet end “Oprettelse af testsager” .
Hvis testscenarierne var “Hvad skal man teste”, så behandler testsagerne “Hvordan man tester”. Oprettelse af testsager er en overvejende del af testdesignfasen af STLC. Input til oprettelse af testsagen er testscenarierne og SRS-dokumentet.
For testere som os, Test tilfælde er den rigtige aftale - det er de ting, vi bruger det meste af vores tid på. Vi opretter dem, gennemgår dem, udfører dem, vedligeholder dem, automatiserer dem - og godt, du får billedet. Uanset hvor erfaren vi er, og hvilken rolle vi spiller i et projekt - vi vil stadig arbejde med testsagerne.
Testplanlægning mod udførelse af test
Planlægning af softwaretest forbeholder sig et langt bedre anvendelsesområde sammenligneligt i STLC-fase . Leveringen af kvalitetssoftware sikres af testteamet. Og hvad der skal gøres i test, afgøres faktisk i testplanlægningsfasen.
Dette afsnit giver et komplet overblik og inkluderer illustrationer om vigtigheden af testplanlægning og udførelsesfase . Efter at have læst dette vil du forstå den vigtige betydning af planlægningsfasen sammenlignet med udførelsesfasen med mere live eksempler og casestudier til illustrationer .
Testplanlægning
Nedenfor er nogle vigtige ting, der skal bemærkes under planlægningen:
Planlægning af en test er det centrale vigtige afsnit i testcyklussen. Resultatet af testfasen bestemmes af kvaliteten og omfanget af den planlægning, der er udført til testningen.
Planlægning af testen sker normalt i udviklingsfasen for at spare tid for udførelse af test efter gensidig aftale fra alle involverede parter.
Nogle vigtige fakta, der skal bemærkes, inkluderer:
- Planlægning skal startes parallelt med udvikling, forudsat at kravene er frosset.
- Alle interessenter som designere, udviklere, klienter og testere skal involveres, mens de færdiggør planen.
- Planlægning kan ikke udarbejdes for et ubekræftet eller ikke godkendt forretningsbehov.
- Lignende testplaner vil blive anvendt på de nye krav, som virksomheden vil have.
Eksempel 1
Udviklingsteamet arbejder på en software XYZ efter at have fået et par krav fra klienterne. Testteamet har næsten startet deres forberedelse til testdefinerings- eller planlægningsfasen. Testplanlægning skal designes til at imødekomme de oprindelige krav, som klienterne citerer. Dette er gjort af testteamet.
Ingen af de andre interessenter var involveret i denne fase, og planlægningen er blevet frosset.
Udviklingsteamet har nu foretaget nogle ændringer i forretningsstrømmen for at løse et par problemer i deres arbejde med kundens godkendelse. Nu er softwaren kommet til testteamet til en test. Med testplanen i henhold til den gamle forretningsstrøm har testteamet startet deres testrunde. Dette påvirkede testleverancerne med mange forsinkelser, da den ændrede forretningsstrøm ikke blev delt med testteamet.
Observation fra eksempel 1:
tilføje elementer til en array-java
Der er visse observationer fra ovenstående eksempel.
De er:
- At forstå den nye forretningsstrøm forbrugte meget tid.
- Forsinkelser i projektleverancer.
- Omarbejde om planlægning og de andre opgaver i fasen.
Alle disse observationer skal konverteres til væsentlige behov for en effektiv test, der kan leveres.
Hovedkomponenter i planlægningsfasen
Nedenfor er de vigtigste komponenter, der er involveret i planlægningsfasen.
- Teststrategi: Dette er et af de vigtigste afsnit, der kan forklare den strategi, der vil blive brugt under testning.
- Testdækning: Dette er i det væsentlige påkrævet, og det foretager kortlægning af overensstemmelse af forretningsbehovene og testcases, så man kan sikre, om hele softwaren er testet eller ej.
- Testcyklusser og varighed: Dette kan blive meget kritisk afhængigt af udviklingsrunder og deres tid til at gennemføre hver runde.
- Bestået / ikke bestået kriterier: Det er meget krævet, hvor kriterierne for bestået og ikke bestået er defineret. Et par gange vil dette også blive defineret af klienterne.
- Forretningsmæssige og tekniske krav: Behovet for at have softwaren og de formål, de tjener, vil blive klart defineret sammen med forklaringerne på lavt niveau.
Begrænsninger
Der er få ting, der faktisk kan kontrollere softwaretestfasen, især planlægningsfasen.
Følgende er så få områder:
- Funktioner, der skal og ikke skal testes: Dette vil tydeligt påpege, hvad der skal testes, og hvad der ikke bør være.
- Suspensionskriterier og genoptagelseskrav: Dette er beslutningstager på den udviklede software og kriterierne defineret for at suspendere testen eller genoptage testen.
- Ansvar: En tester har flere ansvar for at sikre problemer, fejl og mangler i softwaren, der testes. Derudover skal fejlene valideres med udviklerne, for at de kan rette.
- Risici og uforudsete udgifter: Risici forbundet med testningen bør nævnes tydeligt, og ordentlige beredskaber i løbet af tiden skal defineres meget klart.
Casestudie nr. 1
gratis video converter software til Windows 10
Udviklingsteamet fra Eksempel 1 planlægger at frigive softwaren XYZ i 2 faser. Fase 1 har mange funktioner, der skal testes, og få, der ikke testes. Igen er softwaren frigivet til test uden at holde testteamet informeret om de funktioner, der endnu ikke er udviklet.
Nu starter testteamet sin udførelse baseret på de testplaner, de allerede har udarbejdet. De kommer med et stort antal bugs. Og efter validering fra udviklingsteamet bliver de fleste ugyldige.
Bemærkninger fra ovenstående casestudie:
- Udviklingsteam til frigivelse af softwaren til testteamet med release notes og kravsdækningsnoter (release notes).
- Funktioner, der skal testes og ikke testes, skal tages med i beregningen baseret på den frigivne software inden test.
- Suspension og genoptagelseskriterier for testen skal defineres korrekt.
- Risiko og beredskabsplaner for utilgængelighed af softwaren skal afbildes perfekt.
Læs også=> Sådan håndteres risici under testplanlægningsfasen
Testudførelsesplan
Udførelsen af testsager er et af trinene i STLC-fasen. Dette skal udføres i overensstemmelse med de planer, der blev udarbejdet tidligere. Derfor dominerer planlægning altid hele testfasen. Nedenfor er et eksempel, hvor testteamet bliver påvirket af ændringerne i testplanerne.
Eksempel 2
Test af software A blev startet baseret på plan 1 udarbejdet af teamet. Senere på grund af forretningsbehovet og ændringerne måtte testplanen gennemgå nogle ændringer. Dette har igen tvunget til at ændre testsagerne eller udførelsen.
Bemærkninger:
- Testplanen bestemmer udførelsen af testsagen.
- Udførelsesdelen varierer efter planen.
- Så længe planen og kravene er gyldige, er testcases også gyldige.
Måder at overvinde problemer under udførelse
Testere vil oftere støde på forskellige scenarier, mens de udfører testudførelsen. Dette er når testerne bliver nødt til at forstå og kende måderne til at løse problemet eller i det mindste finde en løsning på problemet.
Eksempel 3
Under testkassens udførelse af software B støder testteamet på flere problemer. Få af dem er showpropper. De kræver, at udviklere hjælper dem med at løse problemet. Dette er sket flere gange, og resultatet af det er en forsinkelse i test af leverancer.
Bemærkninger:
- Der er en afhængighed for at overvinde miljøproblemer og problemer.
- En korrekt forståelse af miljøet er påkrævet for testere.
- Ofte forekommende og kendte problemer skal dokumenteres for at overvinde dem i fremtiden.
Versionskontrol og styring
Versionskontrol og styring af testplaner og testcases er virkelig vigtige for at fremvise de rettidige leverancer. Dette bliver mere betydningsfuldt og gøres ofte ved hjælp af et versionskontrolværktøj.
Et versionskontrolværktøj hjælper dem ikke kun med at kontrollere testplanerne, men hjælper også med fejlhåndtering. Når der er testprojekter med flere cyklusser og udgivelser, kan disse værktøjer virkelig hjælpe meget med at nedbringe metrics til understøttelse af testleverancer.
Læs også=> Risikostyring i testudførelsesfasen
Forskellen mellem testplanlægning og testudførelse
Følgende er et par vigtige områder, der vil påpege, hvordan planlægning adskiller sig fra testudførelsesfasen.
| Sammenligningsområde | Testplanlægning | Testudførelse |
|---|---|---|
| Leverbar positionering | Testplan vil blive betragtet som en vigtig leverance til testaktiviteten. Dette gøres som det første trin i testprocessen. | Dette kommer som et sidste bænkmedlem i testfasen. Efter udførelse deles defekter / bugs-status sammen med testsagens eksekveringsstatus som en af testresultaterne |
| Ansvarlig person | Testlederen vil forberede testplanen og vil dele med alle interessenterne til deres gennemgang. | Dette gøres normalt ved at teste, idet de forberedte testsager er godkendt og underskrevet. |
| Primære fokus | Testplanens fokusområder er, hvordan testen skal udføres, hvad der skal overvejes, og hvad man ikke skal, miljø, der kan bruges, testplaner osv. | Testudførelsen fokuserer primært på udførelsen af de testsager, der skal testes på softwaren. |
| Tilbagevendende eller iterativ tilstand | Dette er en engangsaktivitet. Når det er sagt, kræves det måske eller måske ikke ændringer for de fremtidige udgivelser af softwaren. | Der er 3 dele på dette område, når vi taler om iteration. 1. Funktionstest. 2. Regressionstest. 3. Gentest. |
| Indgange | Input til oprettelse af en testplan er virkelig påkrævet og leveres af forretningsanalytikere, arkitekt, klienter osv., | Test case-dokumentet er det vigtigste input. |
| Periode, hvor den kan startes | Det skal startes sammen med udviklingscyklussen for effektivt resultat og for at spare tid. Men der er få modeller som vandfaldsmodel, hvor testprincippet først starter, når udviklingsfasen er afsluttet. | Udførelse skal startes strengt efter udviklingen af softwaren er udført. |
| Lukningsperiode | Testplanen har ingen sådan lukkeperiode. Generelt gives der et afmelding fra alle interesserede parter til softwaren. | Udførelse for en bestemt frigivelse eller cyklus vil blive betragtet som afsluttet, når alle testsagerne er blevet udført mod softwaren. |
| Brug af værktøjer | Der vil ikke være mange værktøjer, da planlægningsaktiviteten vil være mere til diskussion og dokumentation. For at holde styr på eventuelle ændringer i planen bruger testadministratorerne normalt ethvert versionskontrolværktøj som VSS eller noget andet. | Det afhænger af udførelsesmetoden. I tilfælde af manual vil intet værktøj blive brugt til udførelse. Men til at logge fejlene og styre, vil nogle værktøjer blive brugt. I tilfælde af automatiseringstest udføres udførelsen ved hjælp af værktøjer som QTP, SELENIUM osv. |
| Virkninger på leverancerne | Dette vil påvirke alle testfaser på en større måde | Dette vil påvirke den efterfølgende cyklus eller frigivelse, der skal testes. |
Ovenstående illustrationer kan have forklaret bedre i forhold til vigtigheden af testplanlægningsaktiviteter end testudførelsen. På nogle måder er udførelsesfasen en slags delmængde af testplanen.
Baseret på teststrategien, tilgangen og de andre ting har testplanen større sandsynlighed for at blive ændret for at give plads til ændringerne. Det er en bestemt ting, at udførelse af test afhænger af testsagerne. Testcases er baseret på planerne. Derfor vil ændringer i planer sikre ændringer i testsagerne.
Men omvendt behøver ændringer i testsager ikke obligatorisk at lede efter ændringer. Dette er en af hovedårsagerne til, at planlægningen følger med i forhold til testudførelsesfasen.
Vores kommende tutorial forklarer dig mere om, hvordan du opretter testcases? Hvad er de? Og hvordan vi kan få dem til at fungere for os sammen med de forskellige andre aspekter relateret til testsagerne.
NÆSTE vejledning=> QA træningsdag-4: Skrivning af testcases fra SRS-dokument
Er du ekspert i at skrive et testplandokument? Så er dette det rigtige sted at dele dine værdifulde tip til forbedring for de kommende testere. Du er velkommen til at udtrykke dine tanker med os i kommentarfeltet nedenfor !!
Anbefalet læsning
- Eksempel på software-testplanskabelon med format og indhold
- Dokumentationsvejledning til softwaretest (hvorfor det er vigtigt)
- QA-softwaretestressourcer og downloads
- Eksempel på testplandokument (eksempel på testplan med detaljer om hvert felt)
- Testudførelse i softwaretest: Præcis proces og plan med eksempel
- Sådan skriver du teststrategidokument (med prøve teststrategiskabelon)
- Skrivning af testsager fra SRS-dokument (DOWNLOAD Live Project-prøveeksempler)
- Softwaretestkursusplan - Online kursus detaljeret træningsplan