TESTPLAN: Hvad er, hvordan man opretter (med eksempel)

Testplan

En 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 nødvendige indsats for at validere kvaliteten af den applikation, der testes. Testplanen fungerer som en plan for at udføre softwaretestaktiviteter som en defineret proces, som minutvis overvåges og kontrolleres af testadministratoren.

I henhold til ISTQB-definitionen: "Testplan er et dokument, der beskriver omfanget, tilgangen, ressourcerne og tidsplanen for tilsigtede testaktiviteter."

Lad os starte med følgende testplaneksempel / -scenarie: I et møde vil du diskutere testplanen med teammedlemmerne, men de er ikke interesserede -.

I så fald, hvad vil du gøre? Vælg dit svar som nedenstående figur

A) Jeg er manager gør alt som jeg sagde
B) OK, lad mig forklare, hvorfor vi har brug for en testplan
forkert
Som testmanager skal du forklare dem vigtigheden af testplan i stedet for at tvinge holdet til at gøre, hvad du vil. Korrekt
Som testleder skal du forklare dem vigtigheden af testplan i stedet for at tvinge holdet til at gøre, hvad du vil.

Hvad er vigtigheden af testplan?

At lave testplan dokument har flere fordele

Hjælp mennesker uden for testteamet som udviklere, forretningsledere, kunder med at forstå detaljerne i test.
Testplan styrer vores tænkning. Det er som en regelbog, som skal følges.
Vigtige aspekter som testestimering, testomfang, teststrategi er dokumenteret i testplan, så den kan gennemgås af Management Team og genbruges til andre projekter.

Hvordan man skriver en testplan

Du ved allerede, at udarbejdelse af 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

Analyser produktet
Design teststrategien
Definer testmålene
Definer testkriterier
Ressourceplanlægning
Planlæg testmiljø
Tidsplan & skøn
Bestem testleverancer

Trin 1) Analyser produktet

Hvordan kan du teste et produkt uden nogen oplysninger om det? Svaret er umuligt. Du skal lære et produkt grundigt inden du tester det.

Det testede produkt er Guru99 bankwebsted. Du bør undersøge klienter og slutbrugere for at kende deres behov og forventninger fra applikationen

Hvem bruger hjemmesiden?
Hvad bruges det til?
Hvordan fungerer det?
Hvad er software / hardware, som produktet bruger?

Du kan bruge følgende fremgangsmåde til at analysere webstedet

Lad os nu anvende ovenstående viden på et ægte produkt: Analyser bankwebstedet http://demo.guru99.com/V4.

Du bør kigge rundt på dette websted og også gennemgå produktdokumentationen. Gennemgang 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 interviewe kunde, udvikler, designer for at få mere information.

Trin 2) Udvikl teststrategi

Teststrategi er et kritisk trin i udarbejdelsen af 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 nå dem
Bestemmer testindsats og omkostninger

Tilbage til dit projekt skal du udvikle teststrategi til at teste det bankwebsted. Du skal følge trinene nedenfor

Trin 2.1) Definer omfanget af testningen

Før testaktivitetens start skal testens omfang være kendt. Du skal tænke hårdt over det.

Komponenterne i systemet, der skal testes (hardware, software, middleware osv.), Defineres som " i omfang "
Komponenterne i systemet, der ikke testes, skal også defineres tydeligt som " uden for anvendelsesområdet ."

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

Giv alle en tillid og nøjagtig information om den test, du laver
Alle projektmedlemmer har en klar forståelse af, hvad der testes, og hvad der ikke er

Hvordan bestemmer du omfanget af dit projekt?

For at bestemme omfanget skal du -

Præcis kundekrav
Projektbudget
Produkt specifikation
Dit testteams færdigheder og talent

Nu skal klart definere testens "i omfang" og "uden for anvendelsesområdet".

Som softwarekravet specificerer, fokuserer projektet Guru99 Bank kun på at teste alle funktionerne og den eksterne grænseflade på hjemmesiden Guru99 Bank ( i omfangstest )
Ikke-funktionel test såsom stress , ydeevne eller logisk database vil i øjeblikket ikke blive testet. ( uden for anvendelsesområdet)

Problem Scenario

Kunden vil have dig til at teste sin API. Men projektbudgettet tillader ikke det. I så fald hvad vil du gøre?

I så fald skal du overbevise kunden om, at Api Testing er ekstra arbejde og vil forbruge betydelige ressourcer. Giv ham data, der understøtter dine fakta. Fortæl ham, at hvis Api-test er inkluderet i omfanget, øges budgettet med XYZ-beløbet.

Kunden er enig og følgelig er de nye anvendelsesområder, varer uden for anvendelsesområdet

In-scope poster: Funktionel test, Api-test
Uden for anvendelsesområdet: Databasetest, hardware og andre eksterne grænseflader

Trin 2.2) Identificer testtype

En testtype er en standard testprocedure, der giver et forventet testresultat.

Hver testtype er formuleret til at identificere en bestemt type produktfejl. Men alle testtyper er rettet mod at nå et fælles mål " Tidlig detektion af alle mangler inden frigivelse af produktet til kunden"

De almindeligt anvendte testtyper er beskrevet som følgende figur

Der er masser af testtyper til test af softwareprodukt. Dit team kan ikke have nok indsats for at håndtere alle slags test. Som testhåndtering skal du angive prioritet for testtyperne

Hvilke testtyper skal fokuseres til test af webapplikationer?
Hvilke testtyper skal ignoreres for at spare omkostninger?

Lad os nu øve dig med dit projekt. Det produkt, du vil teste, er et bankwebsted.
Hvilke testtyper skal du fokusere i dette tilfælde?
Vælg det, der passer A) Enhedstest B) API-test C) Integrationstest D) Systemtest E) Installation / afinstallation af test F) Agil test Vi vælger kun B) API-test C) Integrationstest D) Systemtest til Guru99-projekt

Trin 2.3) Dokumentér risici og problemer

Risiko er fremtidens usikre begivenhed med sandsynlighed for forekomst og potentiale for tab. Når risikoen faktisk opstår, bliver det ' problemet'.

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

I QA-testplanen vil du dokumentere disse risici

Risiko	Afbødning
Teammedlem mangler de krævede færdigheder til test af websteder.	Planlæg træningskursus for at øge dine medlemmer
Projektplanen er for stram; det er svært at gennemføre dette projekt til tiden	Indstil testprioritet for hver af testaktiviteterne.
Test Manager har dårlig ledelsesevne	Planlæg ledertræning for leder
Manglende samarbejde påvirker dine medarbejderes produktivitet negativt	Tilskynd hvert teammedlem til hans opgave og inspirer dem til større indsats.
Forkert budgetoverslag og overskridelse af omkostninger	Fastlæg rækkevidden inden arbejdet påbegyndes, vær meget opmærksom på projektplanlægning og følg konstant og mål fremskridtene

Trin 2.4) Opret testlogistik

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

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

Hvem vil teste?

Du kender muligvis ikke nøjagtige navne på testeren, der vil teste, men typen testeren kan defineres.

For at vælge det rigtige medlem til den angivne opgave skal du overveje, om hans dygtighed er kvalificeret til opgaven eller ej, også estimere projektbudgettet. Valg af forkert medlem til opgaven kan få projektet til at mislykkes eller forsinke .

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

Evne til at forstå kundernes synspunkt
Stærkt ønske om kvalitet
Opmærksomhed på detaljer
Godt samarbejde

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

Hvornår vil testen finde sted?

Testaktiviteter skal matches med tilhørende udviklingsaktiviteter.

Du begynder at teste, når du har alle nødvendige emner vist i nedenstående 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; sørg for, at softwaren, der testes, er fejlfri inden frigivelse.

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

Skriv en liste over alle softwarefunktioner (funktionalitet, ydeevne, GUI ...), som muligvis skal testes.
Definer målet eller målet for testen baseret på ovenstående funktioner

Lad os anvende disse trin for at finde testmålsætningen for dit Guru99 Bank-testprojekt

Du kan vælge metoden ' TOP-NED' for at finde webstedsfunktioner, som muligvis skal testes. I denne metode opdeler du applikationen under test til komponent og underkomponent .

I det forrige emne har du allerede analyseret kravspecifikationerne og gå gennem hjemmesiden, så du kan oprette et Mind-Map for at finde webstedsfunktionerne som følger

Denne figur viser alle de funktioner, som Guru99-webstedet muligvis har.

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

Kontroller, om Guru99- funktionalitet på webstedet (konto, indbetaling ...) fungerer som forventet uden nogen fejl eller fejl i reelle forretningsmiljøer
Kontroller, at den eksterne grænseflade på webstedet, såsom UI , fungerer som forventet og opfylder kundens behov
Kontroller webstedets anvendelighed . Er disse funktioner bekvemme 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 to typer testkriterier som følger

Suspensionskriterier

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

Testplaneksempel: Hvis dine teammedlemmer rapporterer, at der er 40% af testsagerne mislykkedes, skal du afbryde testen, indtil udviklingsteamet løser alle de mislykkede sager.

Udgangskriterier

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

Nogle metoder til at definere exitkriterier er ved at angive en målrettet kørselshastighed og passrate .

Kørselshastighed er forholdet mellem antallet af eksekverede testtilfælde / samlede test tilfælde af testspecifikation. F.eks. Har testspecifikationen i alt 120 TC'er, men testeren udførte kun 100 TC'er, så kørselshastigheden er 100/120 = 0,83 (83%)
Passrate er forholdet mellem antallet af beståede testsager / eksekverede testsager . For eksempel i over 100 TC'er, der er udført, er der 80 TC'er, der har bestået, så pass-rate er 80/100 = 0,8 (80%)

Disse data kan hentes i testmetriske dokumenter.

Kørselshastighed er obligatorisk at være 100%, medmindre der gives en klar grund.
Bestået er afhængig af projektets omfang, men det er et mål at nå en høj beståelsesrate .

Testplaneksempel: Dit team har allerede udført testudførelserne. De rapporterer testresultatet til dig, og de vil have dig til at bekræfte udgangskriterierne.

I ovennævnte tilfælde er kørselshastigheden obligatorisk 100%, men testteamet afsluttede kun 90% af testsagerne. Det betyder, at kørselshastigheden ikke er opfyldt, så bekræft IKKE udgangskriterierne

Trin 5) Ressourceplanlægning

Ressourceplan er et detaljeret resumé af alle typer ressourcer, der kræves for at gennemføre projektopgaven. Ressourcen kunne være menneskelig, udstyr og materialer, der er nødvendige for at gennemføre et projekt

Den ressourceplanlægning er vigtig faktor af testen planlægning, fordi hjælper med at bestemme det antal af ressourcer (medarbejder, udstyr ...), der skal anvendes til projektet. Derfor kan Test Manager 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

Ingen.	Medlem	Opgaver
1.	Test Manager	Administrer hele projektet Definer projektets retninger Anskaf passende ressourcer
2.	Tester	Identifikation og beskrivelse af passende testteknikker / værktøjer / automatiseringsarkitektur Bekræft og vurder testmetoden Udfør testene, logresultater , rapporter fejlene. Testeren kan være medlemmer, der er indkøbt eller kilder, baseret på projektbudgettet Til den opgave, der krævede ringe færdigheder, anbefaler jeg, at du vælger outsourcede medlemmer for at spare projektomkostninger.
3.	Udvikler i test	Implementere testsagerne, testprogrammet, testpakken osv.
4.	Test administrator	Opbygger og sikrer, at testmiljø og aktiver administreres og vedligeholdes Support Tester til at bruge testmiljøet til testudførelse
5.	SQA medlemmer	Tag ansvaret for kvalitetssikring Kontroller for at bekræfte, om testprocessen opfylder specificerede krav

Systemressource

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

Ingen.	Ressourcer	Beskrivelser
1.	Server	Installer webapplikationen under test Dette inkluderer en separat webserver, databaseserver og applikationsserver, hvis det er relevant
2.	Testværktøj	Testværktøjet er at automatisere testen, simulere brugerdriften, generere testresultaterne Der er masser af testværktøjer, du kan bruge til dette projekt, såsom Selen, QTP ... osv.
3.	Netværk	Du har brug for et netværk, der inkluderer LAN og internet for at simulere det virkelige forretnings- og brugermiljø
4.	Computer	Den pc, som brugerne ofte bruger til at forbinde 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 testsager på. Testmiljøet består af ægte forretnings- og brugermiljø samt fysiske miljøer, såsom server, frontend-kørende miljø.

Sådan opsættes testmiljøet

Tilbage til dit projekt, hvordan opretter du testmiljø til dette bankwebsted?

For at afslutte denne opgave har du brug for et stærkt samarbejde mellem Test Team og Development Team

Du bør stille udvikleren nogle spørgsmål for at forstå webapplikationen under test tydeligt . Her er nogle anbefalede spørgsmål. Selvfølgelig kan du stille de andre spørgsmål, hvis du har brug for det.

Hvad er den maksimale brugerforbindelse, som dette websted kan håndtere på samme tid?
Hvad er hardware / softwarekrav for at installere dette websted?
Har brugerens computer brug for en bestemt indstilling for at gennemse webstedet?

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

Trin 7) Tidsplan og estimering

I artiklen Testestimering har du allerede brugt nogle teknikker til at estimere indsatsen for at gennemføre projektet. Nu skal du inkludere dette skøn samt tidsplanen for testplanlægningen

I testestimationsfasen, formoder du at opdele hele projektet i små opgaver og tilføje estimationen for hver opgave som nedenfor

Opgave	Medlemmer	Anslå indsats
Opret testspecifikationen	Testdesigner	170 mandtimer
Udfør testudførelse	Tester, testadministrator	80 arbejdstimer
Test rapport	Tester	10 arbejdstimer
Test levering		20 mandtimer
Total		280 arbejdstimer

Derefter opretter du tidsplanen for at fuldføre disse opgaver.

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

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

Medarbejder- og projektfrist : Arbejdsdage, projektfrist, ressourcetilgængelighed er de faktorer, der påvirkes af tidsplanen
Projektestimering : Baseret på estimatet ved Test Manager, hvor lang tid det tager at gennemføre projektet. Så han kan lave den passende projektplan
Projektrisiko : Forståelse af risikoen hjælper Test Manager med at tilføje nok ekstra tid til projektplanen til at håndtere risiciene

Lad os øve med et eksempel:

Antag, at chefen vil gennemføre projektet Guru99 på en måned, og du har allerede estimeret indsatsen for hver opgave i Test Estimation. Du kan oprette tidsplanen som nedenfor

Trin 8) Testleverancer

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 softwareudviklingens livscyklus.

Testleverancer leveres inden testfasen.

Testplaner dokument.
Test sags dokumenter
Test design specifikationer.

Testleverancer leveres under testen

Test scripts
Simulatorer.
Testdata
Test sporbarhedsmatrix
Fejllogfiler og udførelseslogfiler.

TESTPLAN: Hvad er, hvordan man opretter (med eksempel)

Indholdsfortegnelse:

Testplan

Hvad er vigtigheden af testplan?