TESTPLAN: Hva er, hvordan lage (med eksempel)

Testplan

En testplan er en detaljert dokument som beskriver test strategi, mål, tidsplan, estimering, leveranser og ressurser som kreves for å utføre tester for et programvareprodukt. Testplan hjelper oss med å bestemme innsatsen som trengs for å validere kvaliteten på applikasjonen som testes. Testplanen fungerer som en plan for å gjennomføre programvaretestaktiviteter som en definert prosess, som blir nøye overvåket og kontrollert av testansvarlig.

I henhold til ISTQB-definisjonen: "Testplan er et dokument som beskriver omfanget, tilnærmingen, ressursene og tidsplanen for tiltenkte testaktiviteter."

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

I så fall, hva vil du gjøre? Velg svaret ditt som følgende figur

A) Jeg er manager gjør alt som jeg sa
B) OK, la meg forklare hvorfor vi trenger en testplan
feil
Som testleder, må du forklare dem viktigheten av testplan i stedet for å tvinge teamet til å gjøre det du vil. Riktig
Som testleder må du forklare dem viktigheten av testplan i stedet for å tvinge teamet til å gjøre det du vil.

Hva er viktigheten av testplan?

Å lage et testplan-dokument har flere fordeler

• Hjelp folk utenfor testteamet som utviklere, bedriftsledere, kunder med å forstå detaljene i testingen.
• Testplan styrer vår tenkning. Det er som en regelbok, som må følges.
• Viktige aspekter som testestimering, testomfang, Teststrategi er dokumentert i Testplan, slik at den kan gjennomgås av Management Team og brukes på nytt til andre prosjekter.

Hvordan skrive en testplan

Du vet allerede at å lage en testplan er den viktigste oppgaven med Test Management Process. Følg de syv 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 informasjon om det? Svaret er umulig. Du må lære et produkt grundig før du tester det.

Produktet som testes er Guru99 banks nettsted. Du bør undersøke klienter og sluttbrukere for å kjenne deres behov og forventninger fra applikasjonen

• Hvem skal bruke nettstedet?
• Hva brukes det til?
• Hvordan vil det fungere?
• Hva er programvare / maskinvare produktet bruker?

Du kan bruke følgende tilnærming til å analysere nettstedet

La oss nå anvende ovennevnte kunnskap på et ekte produkt: Analyser banksiden http://demo.guru99.com/V4.

Du bør se deg rundt på dette nettstedet og også lese produktdokumentasjonen. Gjennomgang av produktdokumentasjon hjelper deg med å forstå alle funksjonene på nettstedet, samt hvordan du bruker det. Hvis du er uklar om noen ting, kan du intervjue kunde, utvikler, designer for å få mer informasjon.

Trinn 2) Utvikle teststrategi

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

• Prosjektets testmål og virkemidlene for å oppnå dem
• Bestemmer testing innsats og kostnader

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

Trinn 2.1) Definer omfanget av testing

Før starten på en testaktivitet, bør omfanget av testingen være kjent. Du må tenke deg om.

• Komponentene i systemet som skal testes (maskinvare, programvare, mellomvare osv.) Er definert som " i omfang "
• Komponentene i systemet som ikke vil bli testet, må også defineres tydelig som " utenfor omfanget ."

Å definere omfanget av testprosjektet er veldig viktig for alle interessenter. Et presist omfang hjelper deg

• Gi alle tillit og nøyaktig informasjon om testingen du gjør
• Alle prosjektmedlemmene vil ha en klar forståelse av hva som testes og ikke

Hvordan bestemmer du omfanget av prosjektet ditt?

For å bestemme omfanget, må du -

• Nøyaktig kundekrav
• Prosjektbudsjett
• Produkt spesifikasjon
• Ferdigheter og talent fra testteamet ditt

Nå skal klart definere "i omfang" og "utenfor omfang" av testingen.

• Som programvarekravet spesifiserer, fokuserer prosjektet Guru99 Bank bare på å teste alle funksjonene og det eksterne grensesnittet til nettstedet Guru99 Bank ( i omfangstesting )
• Ikke-funksjonell testing som stress , ytelse eller logisk database vil for øyeblikket ikke bli testet. ( utenfor omfanget)

Problem Scenario

Kunden vil at du skal teste API-en hans. Men prosjektbudsjettet tillater ikke det. I så fall hva vil du gjøre?

Vel, i slike tilfeller må du overbevise kunden om at Api Testing er ekstra arbeid og vil forbruke betydelige ressurser. Gi ham data som støtter fakta dine. Fortell ham at hvis Api Testing er inkludert i budsjettet, vil budsjettet øke med XYZ-beløpet.

Kunden er enig og følgelig er de nye omfangene utenfor varene

• In-scope-artikler: Funksjonstesting, Api-testing
• Utenfor omfanget: Datatabestesting, maskinvare og andre eksterne grensesnitt

Trinn 2.2) Identifiser testtype

En Testing Type er en standard testprosedyre som gir en forventet test resultat.

Hver testtype er formulert for å identifisere en bestemt type produktfeil. Men alle testtyper er rettet mot å oppnå ett felles mål " Tidlig oppdagelse av alle feilene før produktet slippes ut til kunden"

De vanligste testtypene er beskrevet som følgende figur

Det er mange testtyper for testing av programvareprodukt. Teamet ditt kan ikke ha nok innsats for å håndtere all slags testing. Som testleder må du angi prioritet for testtypene

• Hvilke testtyper bør fokuseres for testing av webapplikasjoner?
• Hvilke testtyper bør ignoreres for å spare kostnader?

La oss nå øve på prosjektet ditt. Produktet du vil teste er et banknettsted.
Hvilke testtyper bør du fokusere i dette tilfellet?
Velg Alt som gjelder A) Enhetstesting B) API-testing C) Integrasjonstesting D) Systemtesting E) Installere / avinstallere testing F) Agile testing Vi velger bare B) API-testing C) Integrasjonstesting D) Systemtesting for Guru99-prosjekt

Trinn 2.3) Dokumenter risiko og problemer

Risiko er fremtidens usikre hendelse med sannsynlighet for forekomst og potensial for tap. Når risikoen faktisk skjer, blir det " problemet".

I artikkelen Risikoanalyse og løsning har du allerede lært om risikoanalysen i detalj og identifisert potensielle risikoer i prosjektet.

I QA-testplanen vil du dokumentere disse risikoene

Fare	Skadebegrensning
Teammedlem mangler de nødvendige ferdighetene for testing av nettsteder.	Planlegg opplæringskurs for å gjøre medlemmene dine bedre
Prosjektplanen er for stram; det er vanskelig å fullføre dette prosjektet i tide	Angi testprioritet for hver av testaktivitetene.
Test Manager har dårlig ledelseskompetanse	Planlegg ledertrening for leder
Manglende samarbeid påvirker de ansattes produktivitet negativt	Oppmuntre hvert teammedlem i oppgaven, og inspirer dem til større innsats.
Feil budsjettoverslag og kostnadsoverskridelser	Sett opp omfanget før du begynner å jobbe, legg stor vekt på prosjektplanlegging og følg og måle fremdriften hele tiden

Trinn 2.4) Opprett testlogistikk

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

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

Hvem skal teste?

Du vet kanskje ikke nøyaktige navn på testeren som skal teste, men typen tester kan defineres.

For å velge riktig medlem for spesifisert oppgave, må du vurdere om hans dyktighet er kvalifisert for oppgaven eller ikke, også estimere prosjektbudsjettet. Valg av feil medlem for oppgaven kan føre til at prosjektet mislykkes eller forsinkes .

Personer med følgende ferdigheter er mest ideelle for å utføre programvaretesting:

• Evne til å forstå kundens synspunkt
• Sterkt ønske om kvalitet
• Oppmerksomhet på detaljer
• Godt samarbeid

I prosjektet ditt er medlemmet som tar ansvaret for testutførelsen testeren. Basert på prosjektbudsjettet, kan du velge in-source eller outsource medlem som testeren.

Når vil testen skje?

Testaktiviteter må matches med tilhørende utviklingsaktiviteter.

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

Trinn 3) Definer testmål

Testmål er det overordnede målet og oppnåelsen av testutførelsen. Målet med testingen er å finne så mange programvarefeil som mulig; sørg for at programvaren som testes er feilfri før utgivelsen.

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

1. Oppgi alle programvarefunksjonene (funksjonalitet, ytelse, GUI ...) som kan trenge å teste.
2. Definer målet eller målet for testen basert på funksjonene ovenfor

La oss bruke disse trinnene for å finne testmålet for Guru99 Bank-testprosjektet

Du kan velge ' TOP-NED' -metoden for å finne nettstedets funksjoner som kan trenge å teste. I denne metoden bryter du ned applikasjonen som testes til komponent og underkomponent .

I forrige emne har du allerede analysert kravspesifikasjonene og går gjennom nettstedet, slik at du kan lage et Mind-Map for å finne nettstedets funksjoner som følger

Denne figuren viser alle funksjonene som Guru99-nettstedet kan ha.

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

• Sjekk om Guru99- funksjonaliteten på nettstedet (konto, innskudd ...) fungerer som forventet uten feil eller feil i virkelige forretningsmiljø
• Sjekk at det eksterne grensesnittet til nettstedet, som UI , fungerer som forventet og oppfyller kundens behov
• Bekreft brukervennligheten til nettstedet. Er disse funksjonene praktiske for brukeren eller ikke?

Trinn 4) Definer testkriterier

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

Suspensjonskriterier

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

Testplaneksempel: Hvis teammedlemmene dine rapporterer at det er 40% av testtilfellene som mislyktes, bør du avbryte testingen til utviklingsteamet løser alle de mislykkede sakene.

Utgangskriterier

Den spesifiserer kriteriene som betegner en vellykket gjennomføring av en testfase. Utgangskriteriene er målrettede resultater av testen og er nødvendige før du går videre til neste fase av utviklingen. Eksempel: 95% av alle kritiske testsaker må bestå.

Noen metoder for å definere utgangskriterier er ved å spesifisere en målrettet løpshastighet og bestått rate .

• Løpshastighet er forholdet mellom antall testtilfeller som er utført / totale testtilfeller med testspesifikasjon. For eksempel har testspesifikasjonen totalt 120 TCer, men testeren utførte bare 100 TCer, så løpshastigheten er 100/120 = 0,83 (83%)
• Bestått rate er forholdet mellom antall testsaker bestått / testsaker utført . For eksempel, i over 100 TC-er utført, er det 80 TC-er som har bestått, så pass-rate er 80/100 = 0,8 (80%)

Disse dataene kan hentes i testmetriske dokumenter.

• Kjøresatsen er obligatorisk å være 100% med mindre en klar grunn er gitt.
• Bestått hastighet er avhengig av prosjektets omfang, men å oppnå høy beståttid er et mål.

Testplaneksempel: Teamet ditt har allerede utført testutførelsene. De rapporterer testresultatet til deg, og de vil at du skal bekrefte utgangskriteriene.

I ovennevnte tilfelle er kjøresatsen obligatorisk 100%, men testteamet fullførte bare 90% av testtilfellene. Det betyr at Run rate ikke er oppfylt, så IKKE bekreft utgangskriteriene

Trinn 5) Ressursplanlegging

Ressursplan er et detaljert sammendrag av alle typer ressurser som kreves for å fullføre prosjektoppgaven. Ressursen kan være menneskelig, utstyr og materialer som trengs for å fullføre et prosjekt

Den ressursplanlegging er viktig faktor for testplanlegging fordi hjelper på å bestemme det antall 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.

Menneskelig ressurs

Tabellen nedenfor representerer forskjellige medlemmer i prosjektgruppen

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 testtilnærmingen Utfør testene, Logg resultatene, Rapporter feilene. Tester kan være medlemmer som kommer inn eller ut, basert på prosjektbudsjettet For oppgaven som krevde lite dyktighet, anbefaler jeg at du velger outsourcede medlemmer for å spare prosjektkostnader.
3.	Utvikler i Test	Implementere testtilfellene, testprogrammet, testpakken osv.
4.	Test administrator	Bygger opp og sikrer at testmiljø og eiendeler administreres og vedlikeholdes Support Tester for å bruke testmiljøet for testutførelse
5.	SQA-medlemmer	Ta ansvar for kvalitetssikring Kontroller om testprosessen oppfyller spesifiserte krav

Systemressurs

For testing, en webapplikasjon, bør du planlegge ressursene som følgende tabeller:

Nei.	Ressurser	Beskrivelser
1.	Server	Installer webapplikasjonen under test Dette inkluderer en egen webserver, databaseserver og applikasjonsserver hvis aktuelt
2.	Testverktøy	Testverktøyet er å automatisere testingen, simulere brukeroperasjonen, generere testresultatene Det er mange testverktøy du kan bruke til dette prosjektet, for eksempel Selen, QTP ... etc.
3.	Nettverk	Du trenger et nettverk som inkluderer LAN og Internett for å simulere det virkelige forretnings- og brukermiljøet
4.	Datamaskin	PC-en som brukerne ofte bruker for å koble til webserveren

Trinn 6) Planlegg testmiljø

Hva er testmiljøet?

Et testmiljø er et oppsett av programvare og maskinvare som testteamet skal utføre testtilfeller på. Testmiljøet består av ekte forretnings- og brukermiljø , så vel som fysiske miljøer, for eksempel server, frontend running-miljø.

Hvordan sette opp testmiljøet

Tilbake til prosjektet ditt, hvordan setter du opp testmiljø for dette banknettstedet?

For å fullføre denne oppgaven, trenger du et sterkt samarbeid mellom Test Team og Development Team

Du bør stille utvikleren noen spørsmål for å forstå webapplikasjonen som testes tydelig . Her er noen anbefalte spørsmål. Selvfølgelig kan du stille de andre spørsmålene hvis du trenger det.

• Hva er den maksimale brukerforbindelsen som dette nettstedet kan håndtere samtidig?
• Hva er maskinvare / programvarekrav for å installere dette nettstedet?
• Trenger brukerens datamaskin noen spesielle innstillinger for å bla gjennom nettstedet?

Følgende figur beskriver testmiljøet til banknettstedet www.demo.guru99.com/V4

Trinn 7) Tidsplan og estimering

I artikkelen Testestimering brukte du allerede noen teknikker for å estimere innsatsen for å fullføre prosjektet. Nå bør du inkludere den estimeringen samt tidsplanen for testplanleggingen

Anta at du deler opp hele prosjektet i små oppgaver i testestimeringsfasen og legger til estimeringen for hver oppgave som nedenfor

Oppgave	Medlemmer	Anslå innsats
Lag testspesifikasjonen	Testdesigner	170 arbeidstimer
Utfør testutførelse	Tester, testadministrator	80 arbeidstimer
Testrapport	Tester	10 arbeidstimer
Test levering		20 arbeidstimer
Total		280 arbeidstimer

Deretter lager du timeplanen for å fullføre disse oppgavene.

Å lage tidsplan er et vanlig begrep i prosjektledelse. Ved å lage en solid tidsplan i testplanleggingen, kan testansvarlig bruke den som verktøy for å overvåke prosjektfremdriften, kontrollere kostnadsoverskridelsene.

For å lage prosjektplanen, trenger Test Manager flere typer input som nedenfor:

• Frist for ansatt og prosjekt : Arbeidsdagene, prosjektfristen, ressurstilgjengeligheten er faktorene som påvirket planen
• Prosjektestimering : Basert på estimatet vet testlederen hvor lang tid det tar å fullføre prosjektet. Så han kan lage riktig prosjektplan
• Prosjektrisiko : Å forstå risikoen hjelper Test Manager å legge til nok ekstra tid til prosjektplanen for å håndtere risikoen

La oss øve med et eksempel:

Anta at sjefen vil fullføre prosjektet Guru99 på en måned, du anslår allerede innsatsen for hver oppgave i Testestimering. Du kan lage timeplanen som nedenfor

Trinn 8) Test leveranser

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

Det er forskjellige testleveranser i hver fase av programvarens utviklingslivssyklus.

Testleveranser leveres før testfasen.

• Testplaner dokument.
• Test saksdokumenter
• Test Design spesifikasjoner.

Testleveranser leveres under testingen

• Test skript
• Simulatorer.
• Testdata
• Test sporbarhetsmatrise
• Feillogger og kjøringslogger.

Testleveranser leveres etter at testsyklusene er over.

• Testresultater / rapporter
• Manglerapport
• Retningslinjer for installasjon / testprosedyrer
• Utgivelsesmerknader

Ressurser

Last ned et eksempel på en testplanmal

Last ned testsystemplanen for nettstedet Guru99 Bank