TESTPLAN i programvaretesting (eksempel)

Testplan

A Testplan er et detaljert dokument som beskriver teststrategien, målene, tidsplanen, estimeringen, leveransene og ressursene som kreves for å utføre testing av et programvareprodukt. En testplan hjelper oss med å bestemme innsatsen som trengs for å validere kvaliteten på applikasjonen som testes. Testplanen fungerer som en blåkopi for å gjennomføre programvaretestaktiviteter som en definert prosess, som overvåkes og kontrolleres nøye av testlederen.

I henhold til ISTQB-definisjonen: «Testplan er et dokument som beskriver omfanget, tilnærmingen, ressursene og tidsplanen for de planlagte testaktivitetene.»

La oss starte med følgende eksempel/scenario på en testplan: I et møte ønsker du å diskutere testplanen med teammedlemmene, men de er ikke interessert.

Hva vil du gjøre i et slikt tilfelle? Velg svaret ditt som vist i figuren nedenfor.

👉 Meld deg på gratis live programvaretestingsprosjekt

Hva er viktigheten av en testplan?

Det er flere fordeler med å lage et testplandokument.

• Hjelpe folk utenfor testteamet, som utviklere, forretningsledere og kunder, forstå detaljene i testingen.
• Testplan guider vår tenkning. Det er som en regelbok som må følges.
• Viktige aspekter som testestimering, testomfang, Teststrategi er dokumentert i testplanen, slik at den kan gjennomgås av ledergruppen og brukes på nytt i andre prosjekter.

Typer testplaner

Det er tre hovedtyper av Testplaner i programvaretesting.

1. Hovedtestplan: Et overordnet dokument som skisserer den overordnede teststrategien, omfanget, ressursene og tidsplanen for alle testnivåer. Det fungerer som prosjektets hovedveikart.
2. Nivåspesifikk testplan: Fokuserer på bestemte testnivåer som enhetstesting, integrasjonstesting, systemtesting eller aksepttesting. Hver plan beskriver tilnærmingen, miljøet og leveransene for det nivået.
3. Typespesifikk testplan: Targetspesialiserte testtyper som ytelsestesting, sikkerhetstesting, brukervennlighetstesting eller automatiseringstesting. Den definerer verktøy, teknikker og kriterier som er unike for den testtypen.

Sammen sikrer disse testplanene omfattende dekning, samsvarer testmål med prosjektmål og forbedrer koordineringen på tvers av team for høyere programvarekvalitet.

Hvordan skrive en testplan

Du vet allerede at å lage en Testplan er den viktigste oppgaven til TeststyringsprosessFølg de sju trinnene nedenfor for å lage en testplan i henhold til IEEE 829

1. Analyser produktet
2. Design teststrategien
3. Definer testmålene
4. Definer testkriterier
5. Ressursplanlegging
6. Planlegg testmiljø
7. Tidsplan og estimering
8. Bestem testleveranser

Trinn 1) Analyser produktet

Hvordan kan du teste et produkt uten noen opplysninger om det? Svaret er UmuligDu må lære deg et produkt grundig før du tester den.

Produktet som testes er Guru99 banknettsted. Du bør undersøke kunder og sluttbrukere for å forstå deres behov og forventninger til applikasjonen.

• Hvem skal bruke nettsiden?
• Hva er det brukt til?
• Hvordan vil det fungere?
• Hvilken programvare/maskinvare bruker produktet?

Du kan bruke følgende metode for å analysere nettstedet.

La oss nå bruke kunnskapen ovenfor på et ekte produkt: Analyser banknettstedet https://demo.guru99.com/V4.

Du bør ta en se deg rundt denne nettsiden og også anmeldelse Produktdokumentasjon. Review av produktdokumentasjon hjelper deg å forstå alle funksjonene på nettstedet, samt hvordan du bruker det. Hvis du er uklar på noen ting, kan du kanskje intervju kunde, utvikler, designer for å få mer informasjon.

Trinn 2) Utvikle teststrategi

Teststrategi er en kritisk trinn i å lage en testplan i programvaretesting. Et teststrategidokument er et dokument på høyt nivå, som vanligvis utvikles av testlederen. Dette dokumentet definerer:

• Prosjektets testingsmål og midlene for å oppnå dem
• Bestemmer testing innsats og kostnader

Tilbake til prosjektet ditt, må du utvikle en teststrategi for testing av banknettstedet. Du bør følge trinnene nedenfor.

Trinn 2.1) Definer omfanget av testing

Før oppstart av enhver testaktivitet bør omfanget av testingen være kjent. Du må tenke nøye gjennom det.

• Komponentene i systemet som skal testes (maskinvare, programvare, mellomvare osv.) er definert som «innenfor omfanget»
• Komponentene i systemet som ikke skal testes må også være tydelig definert som «utenfor omfanget».

Det er svært viktig for alle interessenter å definere omfanget av testprosjektet ditt. Et presist omfang hjelper deg.

• Gi alle tillit og nøyaktig informasjon om testen du gjør.
• Alle prosjektmedlemmer vil ha en fjerne forståelse av hva som testes og hva som ikke testes.

Hvordan bestemmer du omfanget av prosjektet ditt?

For å bestemme omfanget må du –

• Nøyaktige kundekrav
• Prosjekt Budsjett
• Produktspesifikasjon
• Ferdigheter og talent for testteamet ditt

Nå bør den tydelig definere hva som er «innenfor» og «utenfor» testingens omfang.

• Som programvarekravet specs, prosjektet Guru99 Bank fokuserer kun på å teste alle funksjoner og eksternt grensesnitt på nettsiden Guru99 Bank (i sikte testing)
• Ikke-funksjonell testing som f.eks stress, ytelse or logisk database vil ikke bli testet. (ut av omfang)

Problemscenario

Kunden vil at du skal teste API-et hans. Men prosjektets budsjett tillater ikke det. Hva vil du gjøre i så fall?

Vel, i et slikt tilfelle må du overbevise kunden om at API-testing er ekstra arbeid og vil forbruke betydelige ressurser. Gi ham data som støtter faktaene dine. Fortell ham at hvis API-testing er inkludert i omfanget, vil budsjettet øke med XYZ-beløp.

Kunden samtykker, og følgelig er de nye omfangene og varene utenfor omfanget

• Artikler som omfattes av: Funksjonell testing, Api-testing
• Elementer utenfor omfanget: Databasetesting, maskinvare og andre eksterne grensesnitt

Trinn 2.2) Identifiser testtype

A Testtype er en standard testprosedyre som gir et forventet testresultat.

Hver testtype er formulert for å identifisere en spesifikk type produktfeil. Men alle testtypene har som mål å oppnå ett felles mål: «Tidlig oppdagelse av alle defektene før produktet frigis til kunden"

Ocuco ofte brukt Testtypene er beskrevet som følger i figuren

Det finnes tonnevis med testtyper for testing av et programvareprodukt. Teamet ditt kan ikke sette nok innsats til å håndtere alle typer testing. Som testleder må du sette prioritet av testtypene

• Hvilke testtyper bør være fokuserte på for testing av webapplikasjoner?
• Hvilke testtyper bør være ignorert for å spare kostnader?

Trinn 2.3) Dokumentrisiko og problemer

Risiko er en fremtid usikker hendelse med en sannsynlighet for forekomst og en potensiell for tap. Når risikoen faktisk inntreffer, blir den 'utgave'.

I artikkelen Risikoanalyse og løsning, har du allerede lært om "Risiko"-analysen i detalj og identifisert potensielle risikoer i prosjektet.

I QA-testplanen vil du dokumentere disse risikoene

Risiko	Begrensning
Teammedlemmene mangler de nødvendige ferdighetene for testing av nettsteder.	Planlegg a kurs for å dyktiggjøre medlemmene dine
Prosjektplanen er for stram; det er vanskelig å fullføre dette prosjektet i tide	Sett Testprioritet for hver av testaktivitetene.
Testlederen har dårlige lederegenskaper	Plan ledertrening for sjefen
Mangel på samarbeid påvirker dine ansattes produktivitet negativt	Oppmuntre hvert teammedlem i sin oppgave, og inspirere dem til større innsats.
Feil budsjettanslag og kostnadsoverskridelser	Etablere omfang før du starter arbeidet, vær nøye med prosjektplanleggingen, og vær stadig oppmerksom på track og mål fremgangen

Trinn 2.4) Opprett testlogistikk

I testlogistikk bør testlederen svare på følgende spørsmål:

• Hvem vil teste?
• Når vil testen skje?

Hvem skal teste?

Du vet kanskje ikke de nøyaktige navnene på testerne som skal teste, men type tester kan defineres.

For å velge riktig medlem for en spesifikk oppgave, må du vurdere om ferdighetene deres er kvalifisert for oppgaven eller ikke, og også estimere prosjektbudsjettet. Å velge feil medlem for oppgaven kan føre til at prosjektet ikke fullføres. mislykkes or bli forsinket.

En person med følgende ferdigheter er ideell for å utføre programvaretesting:

• Evnen til å forstå kundens synspunkt
• Sterk ønske for kvalitet
• Oppmerksomhet å detaljere
• Flink samarbeid

I prosjektet ditt er det medlemmet som skal ta ansvar for testkjøringen testerBasert på prosjektbudsjettet kan du velge et internt eller eksternt medlem som tester.

Når vil testen finne sted?

Testaktiviteter skal matches med tilhørende utviklingsaktiviteter.

Du vil begynne å teste når du har alle de nødvendige varene vist i følgende figur.

Trinn 3) Definer testmål

Testmålet er det overordnede målet og oppnåelsen av testkjøringen. Målet med testingen er å finne så mange programvarefeil som mulig; sørge for at programvaren som testes er Feilfri før utgivelsen.

For å definere testmålene, bør du gjøre følgende to trinn

1. List opp alle programvarefunksjonene (funksjonalitet, ytelse, GUI…) som kan trenge å testes.
2. Definer mål eller mål av testen basert på funksjonene ovenfor

La oss bruke disse trinnene for å finne testmålet for din Guru99 Banktestprosjekt

Du kan velge 'TOPP-NED' metode for å finne nettsidens funksjoner som kanskje må testes. I denne metoden deler du opp applikasjonen som testes inn i komponenter og underkomponenter.

I forrige emne har du allerede analysert kravspesifikasjonene og gått gjennom nettstedet, slik at du kan lage en Tankekart for å finne nettsidens funksjoner som følger:

Denne figuren viser alle funksjonene som Guru99 nettsteder kan ha.

Basert på funksjonene ovenfor kan du definere testmålet for prosjektet. Guru99 som følger:

• Sjekk om nettsiden Guru99 funksjonalitet(Konto, Innskudd…) fungerer som forventet uten feil eller bugs i det virkelige forretningsmiljøet
• Sjekk at nettstedets eksterne grensesnitt, som f.eks. UI, fungerer som forventet og oppfyller kundens behov
• Bekreft brukervennlighet av nettstedet. Er disse funksjonene praktiske for brukeren eller ikke?

Trinn 4) Definer testkriterier

Testkriterier er en standard eller regel som en testprosedyre eller testvurdering kan baseres på. Det finnes to typer testkriterier som følger:

Suspensjonskriterier

Spesifiser de kritiske suspensjonskriteriene for en test. Hvis suspensjonskriteriene er oppfylt under testing, vil den aktive testsyklusen være suspendert til kriteriene er løst.

Eksempel på testplan: Hvis teammedlemmene dine rapporterer at 40% av testtilfellene mislyktes, bør du henge testing til utviklingsteamet fikser alle de mislykkede tilfellene.

Utgangskriterier

Den spesifiserer kriteriene som angir en vellykket fullføring av en testfase. Utgangskriteriene er de målrettede resultatene av testen og er nødvendige før du går videre til neste utviklingsfase. Eksempel: 95% av alle kritiske testtilfeller må bestå.

Noen metoder for å definere utgangskriterier er ved å spesifisere et mål kjørehastighet og bestått.

• Løpshastigheten er forholdet mellom antall utførte testtilfeller og/totalt antall testtilfeller av testspesifikasjonen. For eksempel har testspesifikasjonen totalt 120 TC-er, men testeren utførte bare 100 TC-er, så kjøringsraten er 100/120 = 0.83 (83 %)
• Beståttprosenten er forholdet mellom antall beståtte testtilfeller / utførte testtilfellerFor eksempel, av de ovennevnte 100 utførte TC-ene, er det 80 TC-er som bestod, så beståttprosenten er 80/100 = 0.8 (80 %).

Disse dataene kan hentes i Test Metriske dokumenter.

• Kjør sats er obligatorisk å være 100% med mindre det er gitt en klar grunn.
• Pass sats er avhengig av prosjektets omfang, men oppnå en høy beståttprosent er et mål.

Eksempel på testplan:Teamet ditt har allerede utført testkjøringene. De rapporterer testresultatet til deg, og de vil at du skal bekrefte Utgangskriterier.

I tilfellet ovenfor er løpshastigheten obligatorisk og er 100%, men testteamet fullførte bare 90 % av testtilfellene. Det betyr at kjøringsraten ikke er oppfylt, så bekreft IKKE avslutningskriteriene.

Trinn 5) Ressursplanlegging

En ressursplan er en detaljert sammendrag av alle typer ressurser som kreves for å fullføre en prosjektoppgave. Ressurser kan være menneskelige ressurser, utstyr og materialer som trengs for å fullføre et prosjekt.

Ressursplanlegging er en viktig faktor i testplanleggingen fordi den bidrar til bestemme de Antall av ressurser (ansatte, utstyr…) som skal brukes til prosjektet. Derfor kan testlederen lage riktig tidsplan og estimering for prosjektet.

Denne delen representerer de anbefalte ressursene for prosjektet ditt.

Human Resource

Tabellen nedenfor representerer ulike medlemmer i prosjektteamet ditt

Nei.	Medlem	Oppgaver
1.	Testleder	Administrer hele prosjektet Definer prosjekt retninger Skaff deg passende ressurser
2.	tester	Identifisere og beskrive passende testteknikker/verktøy/automatiseringsarkitektur Verifiser og vurder testmetoden Henrette testene, logg resultater, og rapporterer defektene. Testeren kan være internt eller eksternt innleide medlemmer, basert på prosjektets budsjett. For oppgaven som krever lav ferdighet, jeg anbefaler deg å velge outsourcet medlemmer til redde prosjektkostnad.
3.	Utvikler i test	Implementere testtilfellene, testprogrammet, testsuiten osv.
4.	Test administrator	Bygger opp og sikrer Test miljø og eiendeler er fikk til og opprettholdt Støttetester å bruke testmiljøet til testkjøring
5.	SQA medlemmer	Ta ansvar for kvalitetssikring. Sjekk for å bekrefte om testprosessen oppfyller de spesifiserte kravene

Systemressurs

For testing av en webapplikasjon bør du planlegge ressursene slik:

Nei.	Ressurser	Descriptioner
1.	Server	Installer webapplikasjonen som testes. Dette inkluderer en separat webserver, databaseserver og applikasjonsserver, hvis aktuelt.
2.	Testverktøy	Testverktøyet skal automatisere testingen, simulere brukeroperasjonen og generere testresultatene. Det finnes tonnevis av testverktøy du kan bruke til dette prosjektet, som for eksempel Selenium, QTPOsv
3.	Network	Du trenger et nettverk, inkludert LAN og Internett, for å simulere det virkelige forretnings- og brukermiljøet
4.	datamaskin	PC-en som brukere ofte bruker for å koble seg til webserveren

Trinn 6) Planlegg testmiljø

Hva er testmiljøet

Et testmiljø er et oppsett av programvare og maskinvare som testteamet skal kjøre testtilfeller på. Testmiljøet består av en ekte virksomhet og bruker miljø, så vel som fysiske miljøer, for eksempel en server og et frontend-kjøremiljø.

Slik setter du opp testmiljøet

Tilbake til prosjektet ditt, hvordan setter du opp en test miljø for dette banknettstedet?

For å fullføre denne oppgaven trenger du sterkt samarbeid mellom testteamet og utviklingsteamet.

Du bør stille utvikleren noen spørsmål for å forstå nettapplikasjonen som testes klartHer er noen anbefalte spørsmål. Du kan selvfølgelig stille de andre spørsmålene hvis du trenger det.

• Hva er det maksimale antallet brukertilkoblinger som dette nettstedet kan håndtere samtidig?
• Hva er kravene til maskinvare/programvare for å installere denne nettsiden?
• Trenger brukerens datamaskin noen spesielle innstillinger for å bla gjennom nettstedet?

Figuren nedenfor beskriver testmiljøet til banknettstedet https://demo.guru99.com/V4

Trinn 7) Tidsplan og estimering

I artikkelen Test estimering, du har allerede brukt noen teknikker for å estimere innsatsen for å fullføre prosjektet. Nå bør du inkludere dette estimatet samt tidsplanen i testplanleggingen.

I testestimeringsfasen, anta at du deler opp hele prosjektet i små oppgaver og legger til estimatet for hver oppgave som følger

Oppgave	medlemmer	Beregn innsats
Lag testspesifikasjonen	Testdesigner	170 arbeidstimer
Utfør testutførelse	Tester, testadministrator	80 arbeidstimer
Testrapport	tester	10 arbeidstimer
Testlevering		20 arbeidstimer
Totalt		280 arbeidstimer

Deretter oppretter du planlegge for å fullføre disse oppgavene.

Å lage en tidsplan er et vanlig begrep innen prosjektledelse. Ved å lage en solid tidsplan i testplanleggingen kan testlederen bruke den som et verktøy for å overvåke prosjektets fremdrift og kontrollere kostnadsoverskridelser.

For å lage prosjektplanen trenger testlederen flere typer innspill som følger:

• Ansatt- og prosjektfristArbeidsdager, prosjektets frist og ressurstilgjengelighet er faktorene som påvirker tidsplanen
• ProsjektestimatBasert på estimatet vet testlederen hvor lang tid det tar å fullføre prosjektet. Slik at han kan lage en passende prosjektplan.
• ProsjektrisikoÅ forstå risikoen hjelper testlederen med å legge til nok ekstra tid i prosjektplanen til å håndtere risikoene

La oss øve med et eksempel:

Anta at sjefen ønsker å fullføre prosjektet Guru99 i en måned, og du har allerede estimert innsatsen for hver oppgave i Testestimering. Du kan opprette tidsplanen som følger

Trinn 8) Test leveranser

Testleveranser er en liste over alle dokumenter, verktøy og andre komponenter som må utvikles og vedlikeholdes for å støtte testarbeidet.

Det er forskjellige testleveranser i hver fase av livssyklus for programvareutvikling.

Testleveranser leveres før du testfasen.

• Dokument for testplaner.
• Testcases dokumenter
• Test designspesifikasjoner.

Testleveranser leveres under testingen

• Test skript
• Simulatorer.
• Testdata
• Test Tracevnematrise
• Feillogger og utførelseslogger.

Testleveranser leveres etter testsyklusen er over.

• Testresultater/rapporter
• Feilmelding
• Retningslinjer for installasjon/testprosedyrer
• Utgiv notater

Vanlige utfordringer i testplanlegging (og løsningene deres)

Effektiv testplanlegging møter ofte praktiske hindringer. Å erkjenne disse utfordringene og bruke proaktive løsninger sikrer smidigere utførelse og høyere programvarekvalitet.

1. Uklare krav
   Utfordring: Tvetydige eller endrede prosjektkrav fører til ufullstendig testdekning.
   Løsning: Gjennomfør kravgjennomganger og vedlikehold et levekrav tracevnematrise.
2. Begrensede ressurser
   Utfordring: Utilstrekkelige verktøy, tid eller dyktige testere påvirker testkvaliteten.
   Løsning: Prioriter kritiske testtilfeller og utnytt automatisering for repeterende oppgaver.
3. Urealistiske tidsfrister
   Utfordring: Stramme tidsplaner reduserer tiden for riktig testdesign og -utførelse.
   Løsning: Bruk estimeringsteknikker og kommuniser risikoer tidlig til interessenter.
4. Dårlig kommunikasjon
   Utfordring: Feiljustering mellom teamene forårsaker forsinkelser og omarbeid.
   Løsning: Implementer regelmessige synkroniseringsmøter og delte dashbord for åpenhet.
5. Utilstrekkelig risikostyring
   Utfordring: Å ignorere potensielle risikoer kan forringe prosjektets tidsfrister.
   Løsning: Identifiser risikoer tidlig, før en risikologg og planlegg strategier for å redusere risikoen.

Spørsmål og svar: