TESTPLAN i softwaretestning (eksempel)

Testplan

A Testplan er et detaljeret dokument, der beskriver teststrategi, mål, tidsplan, estimering, leverancer og ressourcer, der kræves for at udføre test for et softwareprodukt. 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 plan for at udføre softwaretestaktiviteter som en defineret proces, der minutiøst overvåges og kontrolleres af testlederen.

I henhold til ISTQB definition: "Testplan er et dokument, der beskriver omfanget, tilgangen, ressourcerne og tidsplanen for påtænkte testaktiviteter."

Lad os starte med følgende Testplan-eksempel/-scenarie: På et møde vil du diskutere testplanen med teammedlemmerne, men de er ikke interesserede – .

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

Hvad er vigtigheden af ​​testplanen?

At lave et testplan-dokument har flere fordele

• Hjælp folk uden for testteamet såsom udviklere, virksomhedsledere, 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 Testplan, så den kan gennemgås af ledelsesteamet og genbruges til andre projekter.

Sådan skriver du en testplan

Du ved allerede, at man laver en Testplan er den vigtigste opgave i Test Management Process. Fø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 Umulig. Du skal lære et produkt grundigt før du tester det.

Produktet under test er Guru99 bankwebsted. Du bør undersøge kunder og slutbrugere for at kende deres behov og forventninger fra applikationen

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

Du kan bruge følgende tilgang til at analysere webstedet

Lad os nu anvende ovenstående viden til et rigtigt produkt: Analyser bankens hjemmeside http://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 at lave en testplan i softwaretest. Et teststrategidokument er et dokument på højt niveau, som normalt udvikles af Test Manager. 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 for at teste det pågældende bankwebsted. Du skal følge trinene nedenfor

Trin 2.1) Definer omfanget af test

Inden påbegyndelse af enhver testaktivitet bør omfanget af testen være kendt. Du skal tænke dig godt om.

• Komponenterne i systemet, der skal testes (hardware, software, middleware osv.) er defineret som "i omfang"
• De komponenter i systemet, der ikke vil blive testet, skal også være klart defineret som værende "ude af sigte".

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

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

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 klart definere testens "i omfang" og "uden for omfang" af testen.

• 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, ydeevne or logisk database vil i øjeblikket ikke blive testet. (ud af omfang)

Problemscenarie

Kunden vil have dig til at teste hans API. Men det tillader projektbudgettet ikke. Hvad vil du i et sådant tilfælde gøre?

I så fald skal du overbevise kunden om det Api test er ekstra arbejde og vil tære betydelige ressourcer. Giv ham data, der understøtter dine fakta. Fortæl ham, hvis Api-testning er inkluderet i omfanget, vil budgettet stige med XYZ-beløb.

Kunden er indforstået, og de nye scopes er derfor uden for scope

• 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 er rettet mod at opnå ét fælles mål "Tidlig påvisning af alle defekter, før produktet frigives til kunden"

ofte brugt testtyper er beskrevet som følgende figur

Der er tons af testtyper til test af softwareprodukt. Dit hold kan ikke have nok indsats til at håndtere alle former for test. Som Test Manager 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 fremtidens usikker begivenhed med en sandsynlighed for Hændelse og en potentiale for tab. Når risikoen faktisk opstår, bliver denproblem'.

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

Trin 2.4) Opret testlogistik

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

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

Hvem vil teste?

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

For at vælge det rigtige medlem til en bestemt opgave, skal du overveje, om hans dygtighed er kvalificeret til opgaven eller ej, også estimere projektets budget. Valg af forkert medlem til opgaven kan forårsage, at projektet mislykkes or forsinkelse.

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

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

I dit projekt er det medlem, der skal stå for testudførelsen tester. Baseret på projektbudgettet kan du vælge in-source eller outsource medlem som tester.

Hvornår finder testen sted?

Testaktiviteter skal matches med tilhørende udviklingsaktiviteter.

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

Trin 3) Definer testmål

Testmål er det overordnede mål og opnåelse af testudførelsen. Formålet med testen er at finde så mange softwarefejl som muligt; sikre, at den software, der testes fejlfri før frigivelse.

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

1. Liste over alle de softwarefunktioner (funktionalitet, ydeevne, GUI...), som 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 'OPPEFRA OG NED' metode til at finde hjemmesidens funktioner, som muligvis skal testes. I denne metode nedbryder du den applikation, der testes til komponent og underkomponent.

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

Denne figur viser alle de funktioner, som Guru99-webstedet kan have.

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

• Tjek, om webstedet Guru99 funktionalitet(Konto, depositum...) fungerer som forventet uden fejl eller fejl i det rigtige forretningsmiljø
• Tjek at hjemmesidens eksterne grænseflade som 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 testbedømmelse kan baseres på. Der er 2 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.

Testplan Eksempel: Hvis dine teammedlemmer rapporterer, at der er 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.

• Kørselshastighed er forholdet mellem antal udførte testsager/samlet testsager af testspecifikation. For eksempel har testspecifikationen i alt 120 TC'er, men testeren udførte kun 100 TC'er, så kørselshastigheden er 100/120 = 0.83 (83 %)
• Beståelsesprocent er forholdet mellem numre testsager bestået / testsager udført. For eksempel, i over 100 udførte TC'er er der 80 TC'er, der har bestået, 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å 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 Run rate obligatorisk 100%, men testholdet gennemførte kun 90 % af testcaserne. Det betyder, at kørselshastigheden ikke er opfyldt, så bekræft IKKE udgangskriterierne

Trin 5) Ressourceplanlægning

Ressourceplan er en detaljeret resumé af alle typer ressourcer, der kræves for at fuldføre projektopgaven. Ressource kan være menneske, udstyr og materialer, der er nødvendige for at fuldføre et projekt

Ressourceplanlægningen er en vigtig faktor i testplanlægningen, fordi den hjælper bestemmelse og nummer af ressourcer (medarbejder, udstyr...), der skal bruges til projektet. Derfor kan testlederen lave den korrekte tidsplan og estimering for projektet.

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

Menneskelige ressourcer

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

Systemressource

Til test, en webapplikation, bør du planlægge ressourcerne som følgende tabeller:

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 rigtig forretning og bruger miljø, såvel som fysiske miljøer, såsom server, frontend kørende miljø.

Sådan opsætter du testmiljøet

Tilbage til dit projekt, hvordan sætter du op testmiljø til denne bankwebside?

For at afslutte denne opgave, skal du et stærkt samarbejde mellem testteam og udviklingsteam

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

• Hvad er den maksimale brugerforbindelse, som denne hjemmeside kan håndtere på samme tid?
• Hvad er hardware-/softwarekravene for at installere denne hjemmeside?
• Har brugerens computer brug for nogle særlige indstillinger for at browse på hjemmesiden?

Følgende figur beskriver testmiljøet på bankwebstedet http://demo.guru99.com/V4

Trin 7) Tidsplan og estimering

I artiklen Test estimering, har du allerede brugt nogle teknikker til at estimere indsatsen for at fuldføre projektet. Nu skal du inkludere denne vurdering såvel som tidsplanen i testplanlægningen

Antag i testvurderingsfasen, at du deler hele projektet op i små opgaver og tilføjer estimatet for hver opgave som nedenfor

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

At lave tidsplan er en almindelig betegnelse i projektledelse. Ved at skabe en solid tidsplan i testplanlægningen kan testlederen bruge den som værktøj til at overvåge projektets fremskridt, kontrollere omkostningsoverskridelserne.

For at oprette projektplanen har testlederen brug for flere typer input som nedenfor:

• Medarbejder- og projektdeadline: Arbejdsdagene, projektets deadline, ressourcetilgængelighed er de faktorer, der påvirkede tidsplanen
• Projektvurdering: Baseret på estimatet ved testlederen, hvor lang tid det tager at gennemføre projektet. Så han kan lave den passende projektplan
• Projektrisiko : At forstå risikoen hjælper Test Manager med at tilføje nok 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, har du allerede estimeret indsatsen for hver opgave i Test Estimation. Du kan oprette tidsplanen som nedenfor

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 testfase.

• 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

Ressourcer

Download et eksempel på en testplanskabelon

Download prøvesystemets testplan for webstedet Guru99 Bank