TESTPLAN i softwaretestning (eksempel)

Testplan

A Testplan er et detaljeret dokument, der beskriver teststrategien, målsætningerne, tidsplanen, estimatet, leverancerne og de ressourcer, der kræves for at udføre test af et softwareprodukt. En testplan hjælper os med at bestemme den indsats, der er nødvendig for at validere kvaliteten af ​​den applikation, der testes. Testplanen fungerer som en skabelon til at udføre softwaretestaktiviteter som en defineret proces, der overvåges og kontrolleres nøje af testlederen.

I henhold til ISTQB-definitionen er "en testplan et dokument, der beskriver omfanget, tilgangen, ressourcerne og tidsplanen for de planlagte testaktiviteter."

Lad os starte med følgende eksempel/scenarie på en testplan: I et møde vil du gerne diskutere testplanen med teammedlemmerne, men de er ikke interesserede.

Hvad vil du gøre i så fald? Vælg dit svar som vist i følgende figur.

👉 Tilmeld dig et gratis live softwaretestprojekt

Hvad er vigtigheden af ​​en testplan?

Der er flere fordele ved at lave et testplandokument.

• Hjælp folk uden for testteamet, såsom udviklere, forretningsledere og kunder, forstå detaljerne i testen.
• Testplan guider vores tankegang. Det er ligesom en regelbog, som skal følges.
• Vigtige aspekter som testestimering, testomfang, Test strategi er dokumenteret i testplanen, så den kan gennemgås af ledelsesteamet og genbruges til andre projekter.

Typer af testplaner

Der er tre hovedtyper af Testplaner i softwaretestning.

1. Hovedtestplan: Et overordnet dokument, der skitserer den overordnede teststrategi, omfang, ressourcer og tidsplan for alle testniveauer. Det fungerer som projektets hovedkøreplan.
2. Niveauspecifik testplan: Fokuserer på bestemte testniveauer såsom enheds-, integrations-, system- eller accepttest. Hver plan beskriver tilgangen, miljøet og leverancerne for det pågældende niveau.
3. Typespecifik testplan: Targets specialiserede testtyper som ydeevne-, sikkerheds-, brugervenligheds- eller automatiseringstest. Den definerer værktøjer, teknikker og kriterier, der er unikke for den pågældende testtype.

Sammen sikrer disse testplaner omfattende dækning, afstemmer testmål med projektmål og forbedrer koordineringen på tværs af teams for at opnå højere softwarekvalitet.

Sådan skriver du en testplan

Du ved allerede, at man laver en Testplan er den vigtigste opgave for Test Management ProcessFølg de syv trin nedenfor for at oprette en testplan i henhold til IEEE 829

1. Analyser produktet
2. Design teststrategien
3. Definer testmålene
4. Definer testkriterier
5. Ressourceplanlægning
6. Planlæg testmiljø
7. Tidsplan og estimering
8. Bestem testleverancer

Trin 1) Analyser produktet

Hvordan kan du teste et produkt uden nogen information om det? Svaret er UmuligtDu skal lære et produkt at kende grundigt før du tester det.

Produktet, der testes, er Guru99 bankwebstedet. Du bør undersøge kunder og slutbrugere for at kende deres behov og forventninger til applikationen.

• Hvem vil bruge hjemmesiden?
• Hvad bruges det til?
• Hvordan vil det fungere?
• Hvilken software/hardware bruger produktet?

Du kan bruge følgende metode til at analysere webstedet.

Lad os nu anvende ovenstående viden til et rigtigt produkt: Analyser bankens hjemmeside https://demo.guru99.com/V4.

Du bør tage en kig omkring denne hjemmeside og også gennemgå Produktdokumentation. Review af produktdokumentation hjælper dig med at forstå alle funktionerne på webstedet, samt hvordan du bruger det. Hvis du er uklar om nogen ting, kan du evt Interview kunde, udvikler, designer for at få mere information.

Trin 2) Udvikl teststrategi

Teststrategi er en kritisk trin i udarbejdelsen af ​​en testplan i softwaretestning. Et teststrategidokument er et dokument på højt niveau, som normalt udvikles af testlederen. Dette dokument definerer:

• Projektets testmål og midlerne til at opnå dem
• Bestemmer test indsats og omkostninger

Tilbage til dit projekt, skal du udvikle en teststrategi til test af den pågældende bankhjemmeside. Du skal følge nedenstående trin.

Trin 2.1) Definer omfanget af test

Før starten af ​​enhver testaktivitet, bør omfanget af testen være kendt. Du skal tænke dig grundigt om.

• De systemkomponenter, der skal testes (hardware, software, middleware osv.), er defineret som "inden for omfanget"
• De komponenter i systemet, der ikke skal testes, skal også være klart defineret som værende "uden for anvendelsesområde."

Det er meget vigtigt for alle interessenter at definere omfanget af dit testprojekt. Et præcist omfang hjælper dig.

• Giv alle tillid og præcis information om den test, du laver.
• Alle projektmedlemmer vil have en klar forståelse af, hvad der testes, og hvad der ikke testes.

Hvordan bestemmer du omfanget af dit projekt?

For at bestemme omfanget skal du –

• Præcis kundekrav
• Projekt Budget
• Produktspecifikation
• Færdigheder og talent hos dit testhold

Nu bør den klart definere, hvad der er "inden for testens omfang" og "uden for testens omfang".

• Som softwarekravet specs, projektet Guru99 Bank kun fokusere på at teste alle funktioner og ekstern grænseflade på hjemmesiden Guru99 Bank (i omfang test)
• Ikke-funktionel test som f.eks stress, præstation or logisk database vil ikke blive testet. (ud af omfang)

Problemscenarie

Kunden ønsker, at du tester hans API. Men projektets budget tillader det ikke. Hvad vil du gøre i så fald?

I et sådant tilfælde skal du overbevise kunden om, at Api test er ekstra arbejde og vil forbruge betydelige ressourcer. Giv ham data, der understøtter dine fakta. Fortæl ham, at hvis API-testning er inkluderet i omfanget, vil budgettet stige med XYZ-beløb.

Kunden accepterer, og derfor er de nye omfang og varer uden for omfanget

• Elementer inden for rammerne: Funktionstest, Api-testning
• Elementer uden for rækkevidde: Database test, hardware og andre eksterne grænseflader

Trin 2.2) Identificer testtype

A Testtype er en standard testprocedure, der giver et forventet testresultat.

Hver testtype er formuleret til at identificere en specifik type produktfejl. Men alle testtyper har til formål at opnå ét fælles mål:Tidlig påvisning af alle defekter, før produktet frigives til kunden"

ofte brugt Testtyperne er beskrevet som følger i figuren

Der er tons af testtyper til test af et softwareprodukt. Dit team kan ikke sætte tilstrækkelig indsats til at håndtere alle former for test. Som testmanager skal du indstille prioritet af testtyperne

• Hvilke testtyper skal være fokuserede til test af webapplikationer?
• Hvilke testtyper skal være ignoreret for at spare omkostninger?

Trin 2.3) Dokumentrisiko og problemer

Risiko er en fremtid usikker begivenhed med en sandsynlighed for Hændelse og en potentiale for tab. Når risikoen rent faktisk indtræffer, bliver det 'spørgsmål'.

I artiklen Risikoanalyse og løsning, har du allerede lært om 'Risiko'-analysen i detaljer og identificeret potentielle risici i projektet.

I QA-testplanen vil du dokumentere disse risici

Risiko	Mitigation
Teammedlemmer mangler de nødvendige færdigheder til test af websteder.	Planlæg en kursus at dygtiggøre dine medlemmer
Projektplanen er for stram; det er svært at gennemføre dette projekt til tiden	sæt Testprioritet for hver af testaktiviteterne.
Testlederen har dårlige ledelsesevner	Plan lederuddannelse til lederen
Manglende samarbejde påvirker dine medarbejderes produktivitet negativt	Tilskynde hvert teammedlem i deres opgave, og inspirere dem til en større indsats.
Forkert budgetoverslag og omkostningsoverskridelser	Etabler rækkevidde Vær meget opmærksom på projektplanlægningen, inden du påbegynder arbejdet, og følg og mål konstant fremskridtene.

Trin 2.4) Opret testlogistik

I testlogistik skal testlederen besvare følgende spørgsmål:

• Hvem vil teste?
• Når vil testen finde sted?

Hvem vil teste?

Du kender måske ikke de nøjagtige navne på de testere, der skal teste, men type tester kan defineres.

For at vælge det rette medlem til en specifik opgave, skal du overveje, om deres færdigheder er kvalificerede til opgaven eller ej, og også estimere projektets budget. Hvis du vælger det forkerte medlem til opgaven, kan det føre til, at projektet ikke gennemføres. mislykkes or blive forsinket.

En person med følgende færdigheder er ideel til at udføre softwaretest:

• Evne til at forstå kundens synspunkt
• Stærk ønske for kvalitet
• Opmærksomhed til detaljer
• god samarbejde

I dit projekt er det medlem, der skal tage ansvar for testens udførelse, testerBaseret på projektets budget kan du vælge et internt eller outsourcet medlem som tester.

Hvornår finder testen sted?

Testaktiviteter skal matches med tilhørende udviklingsaktiviteter.

Du begynder at teste, når du har alle de nødvendige varer vist i følgende figur.

Trin 3) Definer testmål

Testformålet er det overordnede mål og opnåelse af testens udførelse. Målet med testen er at finde så mange softwarefejl som muligt; sikre, at den software, der testes, er fejlfri før frigivelse.

For at definere testmålene skal du udføre følgende to trin

1. Angiv alle softwarefunktioner (funktionalitet, ydeevne, GUI…), der muligvis skal testes.
2. Definer mål eller mål af testen baseret på ovenstående funktioner

Lad os anvende disse trin for at finde testmålet for dit Guru99 Bank-testprojekt

Du kan vælge 'TOPFRA OG NED' metode til at finde hjemmesidens funktioner, der muligvis skal testes. I denne metode opdeler du den applikation, der testes, i komponenter og delkomponenter.

I det forrige emne har du allerede analyseret kravspecifikationerne og gennemgået hjemmesiden, så du kan oprette en Mindmap for at finde hjemmesidens funktioner som følger:

Denne figur viser alle de funktioner, som Guru99-webstedet måtte have.

Baseret på ovenstående funktioner kan du definere testmålet for projektet Guru99 som følger:

• Tjek om hjemmesiden Guru99 funktionalitet(Konto, Indbetaling…) fungerer som forventet uden fejl eller bugs i det virkelige forretningsmiljø
• Kontroller, at webstedets eksterne brugerflade, f.eks. UI, fungerer som forventet og opfylder kundens behov
• Bekræft usability af hjemmesiden. Er disse funktioner praktiske for brugeren eller ej?

Trin 4) Definer testkriterier

Testkriterier er en standard eller regel, som en testprocedure eller testvurdering kan baseres på. Der er to typer testkriterier som følger:

Suspensionskriterier

Angiv de kritiske suspensionskriterier for en test. Hvis suspensionskriterierne er opfyldt under testen, vil den aktive testcyklus være suspenderet indtil kriterierne er løst.

Eksempel på testplan: Hvis dine teammedlemmer rapporterer, at 40% af testsager mislykkedes, bør du suspendere test indtil udviklingsteamet fikser alle de fejlslagne sager.

Afgangskriterier

Den specificerer de kriterier, der betegner en vellykket afslutning af en testfase. Exitkriterierne er de målrettede resultater af testen og er nødvendige, før man går videre til næste udviklingsfase. Eksempel: 95% af alle kritiske testsager skal bestå.

Nogle metoder til at definere exitkriterier er ved at angive et mål løbshastighed og bestået sats.

• Løbehastigheden er forholdet mellem antal udførte testcases og/eller samlede testcases af testspecifikationen. For eksempel har testspecifikationen i alt 120 TC'er, men testeren udførte kun 100 TC'er, så kørselsraten er 100/120 = 0.83 (83%)
• Beståelsesprocenten er forholdet mellem antal beståede testcases / udførte testcasesFor eksempel, i de ovenstående 100 udførte TC'er, er der 80 TC'er, der bestod, så beståelsesraten er 80/100 = 0.8 (80%)

Disse data kan hentes i Test Metric-dokumenter.

• Kør sats er obligatorisk at være 100% medmindre der er givet en klar begrundelse.
• Pass sats er afhængig af projektets omfang, men opnåelse af en høj beståelsesprocent er et mål.

Eksempel på testplan:Dit team har allerede udført testene. De rapporterer testresultatet til dig, og de vil have dig til at bekræfte Udgangskriterier.

I ovenstående tilfælde er kørselshastigheden obligatorisk og er 100%, men testholdet gennemførte kun 90% af testcasene. Det betyder, at kørselsraten ikke er opfyldt, så bekræft IKKE afslutningskriterierne.

Trin 5) Ressourceplanlægning

En ressourceplan er en detaljeret resumé af alle typer ressourcer, der kræves for at fuldføre en projektopgave. Ressourcer kan være menneskelige ressourcer, udstyr og materialer, der er nødvendige for at fuldføre et projekt.

Ressourceplanlægning er en vigtig faktor i testplanlægningen, fordi den hjælper med bestemmelse og nummer af ressourcer (medarbejdere, udstyr…) der skal bruges til projektet. Derfor kan testlederen udarbejde den korrekte tidsplan og det korrekte estimat for projektet.

Dette afsnit repræsenterer de anbefalede ressourcer til dit projekt.

Menneskelige ressourcer

Følgende tabel repræsenterer forskellige medlemmer i dit projektteam

Nej.	Medlem	Opgaver
1.	Test Manager	Administrer hele projektet Definer projekt retninger Anskaf passende ressourcer
2.	tester	Identifikation og beskrivelse af passende testteknikker/værktøjer/automatiseringsarkitektur Bekræft og vurder testmetoden Udfør testene, log resultater, og indberette manglerne. Testeren kan være internt eller outsourcede medlemmer, baseret på projektets budget. Til den opgave, der kræver lav færdighed, jeg anbefaler dig at vælge outsourcet medlemmer til spare projektomkostninger.
3.	Udvikler i test	Implement testcases, testprogram, testsuite osv.
4.	Test administrator	Bygger op og sikrer Testmiljø og aktiver er lykkedes og opretholdes Supporttester at bruge testmiljøet til testudførelse
5.	SQA medlemmer	Tag ansvar for kvalitetssikring. Kontroller, om testprocessen opfylder de specificerede krav

Systemressource

For at teste en webapplikation bør du planlægge ressourcerne som følger:

Nej.	Ressourcer	Descriptioner
1.	Server	Installer webapplikationen under test. Dette inkluderer en separat webserver, databaseserver og applikationsserver, hvis relevant.
2.	Test værktøj	Testværktøjet har til formål at automatisere testningen, simulere brugerens operationer og generere testresultaterne. Der findes tonsvis af testværktøjer, du kan bruge til dette projekt, f.eks. Selenium, QTP osv.
3.	Netværk	Du har brug for et netværk, inklusive LAN og internet, for at simulere det virkelige forretnings- og brugermiljø
4.	Computer	Den pc, som brugerne ofte bruger til at oprette forbindelse til webserveren

Trin 6) Planlæg testmiljø

Hvad er testmiljøet

Et testmiljø er en opsætning af software og hardware, som testteamet skal udføre testcases på. Testmiljøet består af en rigtig forretning og bruger miljø, såvel som fysiske miljøer, såsom en server og et frontend-miljø.

Sådan opsætter du testmiljøet

Tilbage til dit projekt, hvordan opsætter du en testmiljø til denne bankwebside?

For at afslutte denne opgave, skal du stærkt samarbejde mellem testteamet og udviklingsteamet.

Du bør stille nogle spørgsmål til udvikleren for at forstå den webapplikation, der testes tydeligtHer er nogle anbefalede spørgsmål. Du kan selvfølgelig stille de andre spørgsmål, hvis du har brug for det.

• Hvad er det maksimale antal brugerforbindelser, som dette websted kan håndtere på samme tid?
• Hvad er hardware-/softwarekravene for at installere denne hjemmeside?
• Har brugerens computer brug for bestemte indstillinger for at kunne navigere på hjemmesiden?

Følgende figur beskriver testmiljøet for bankwebstedet https://demo.guru99.com/V4

Trin 7) Tidsplan og estimering

I artiklen Test estimering, du har allerede brugt nogle teknikker til at estimere indsatsen for at fuldføre projektet. Nu skal du inkludere dette estimat samt tidsplanen i testplanlægningen.

I testestimeringsfasen skal du antage, at du opdeler hele projektet i små opgaver og tilføjer estimatet for hver opgave som følger

Opgaver	Medlemmer	Estimer indsats
Opret testspecifikationen	Test designer	170 mandetimer
Udfør testudførelse	Tester, testadministrator	80 mandetimer
Test rapport	tester	10 mandetimer
Test levering		20 mandetimer
Samlet beløb		280 mandetimer

Så opretter du planlægge at udføre disse opgaver.

At lave en tidsplan er et almindeligt udtryk inden for projektledelse. Ved at oprette en solid tidsplan i testplanlægningen kan testlederen bruge den som et værktøj til at overvåge projektets fremskridt og kontrollere omkostningsoverskridelser.

For at oprette projektplanen skal testlederen bruge flere typer input som følger:

• Medarbejder- og projektdeadlineArbejdsdage, projektets deadline og ressourcetilgængelighed er de faktorer, der påvirker tidsplanen.
• ProjektvurderingBaseret på estimatet ved testlederen, hvor lang tid det tager at færdiggøre projektet. Så han kan lave den passende projektplan.
• ProjektrisikoForståelse af risikoen hjælper testlederen med at tilføje tilstrækkelig ekstra tid til projektplanen til at håndtere risiciene

Lad os øve os med et eksempel:

Antag, at chefen ønsker at fuldføre projektet Guru99 i en måned, og du har allerede estimeret indsatsen for hver opgave i Testestimering. Du kan oprette tidsplanen som følger

Trin 8) Test leverancer

Testleverancer er en liste over alle de dokumenter, værktøjer og andre komponenter, der skal udvikles og vedligeholdes til støtte for testindsatsen.

Der er forskellige testleverancer i hver fase af livscyklus til softwareudvikling.

Testleverancer leveres før testfasen.

• Dokument for testplaner.
• Testcases dokumenter
• Test design specifikationer.

Testleverancer leveres i løbet af testningen

• Test scripts
• Simulatorer.
• Testdata
• Test sporbarhedsmatrix
• Fejllogs og udførelseslogfiler.

Testleverancer leveres efter testcyklussen er slut.

• Testresultater/rapporter
• Fejlrapport
• Retningslinjer for installation/testprocedurer
• Release notes

Almindelige udfordringer i testplanlægning (og deres løsninger)

Effektiv testplanlægning støder ofte på praktiske forhindringer. At anerkende disse udfordringer og anvende proaktive løsninger sikrer en mere gnidningsløs udførelse og højere softwarekvalitet.

1. Uklare krav
   Udfordring: Tvetydige eller skiftende projektkrav fører til ufuldstændig testdækning.
   Opløsning: Udfør gennemgang af krav og vedligehold en sporbarhedsmatrix for levekrav.
2. Begrænsede ressourcer
   Udfordring: Utilstrækkelige værktøjer, tid eller dygtige testere påvirker testkvaliteten.
   Opløsning: Prioritér kritiske testcases og udnyt automatisering til gentagne opgaver.
3. Urealistiske deadlines
   Udfordring: Stramme tidsplaner reducerer tiden til korrekt testdesign og -udførelse.
   Opløsning: Brug estimeringsteknikker og kommuniker risici tidligt til interessenter.
4. Dårlig kommunikation
   Udfordring: Forskellen mellem teams forårsager forsinkelser og omarbejde.
   Opløsning: Implementer regelmæssige synkroniseringsmøder og delte dashboards for at sikre gennemsigtighed.
5. Utilstrækkelig risikostyring
   Udfordring: At ignorere potentielle risici kan afspore projektets tidsrammer.
   Opløsning: Identificer risici tidligt, før en risikolog og planlæg afbødende strategier.

Ofte stillede spørgsmål: