TESTPLAN i programvaretesting (eksempel)

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 klart definere "in scope" og "out of scope" av testingen.

• 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 stresset, ytelse or logisk database vil foreløpig ikke testes. (ut av omfang)

Problemscenario

Kunden vil at du skal teste API-en hans. Men prosjektbudsjettet tillater ikke dette. Hva vil du gjøre i et slikt tilfelle?

Vel, i slike tilfeller må du overbevise kunden om det API-testing er ekstraarbeid og vil kreve 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 utenfor rekkevidde

• 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 testtyper er rettet mot å oppnå ett felles mål "Tidlig oppdagelse av alle defektene før produktet frigis til kunden"

Ocuco ofte brukt testtyper er beskrevet som følgende figur

Det finnes tonnevis med testtyper for testing av programvareprodukt. Laget ditt kan ikke ha nok innsats til å håndtere alle typer testing. Som testleder må du stille inn prioritet av testtypene

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

Trinn 2.3) Dokumentrisiko og problemer

Risiko er fremtidens usikker hendelse med en sannsynlighet for forekomst og en potensiell for tap. Når risikoen faktisk skjer, blir denutgave'.

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

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 nøyaktig navn på testeren som skal teste, men type tester kan defineres.

For å velge riktig medlem for spesifisert oppgave, må du vurdere om hans ferdigheter er kvalifisert for oppgaven eller ikke, også estimere prosjektbudsjettet. Å velge feil medlem for oppgaven kan føre til at prosjektet gjør det mislykkes or forsinkelse.

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

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

I prosjektet ditt er medlemmet som skal ta ansvar for testgjennomføringen tester. Basert på prosjektbudsjettet kan du velge in-source eller outsource 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 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; sikre at programvaren som testes er Feilfri før utgivelsen.

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

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

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

Du kan velge 'TOPP-NED' metode for å finne nettsidens funksjoner som kanskje må testes. I denne metoden bryter du ned applikasjonen som testes til komponent og underkomponent.

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-nettstedet kan ha.

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

• Sjekk at om nettstedet Guru99 funksjonalitet(Konto, innskudd ...) fungerer som forventet uten noen feil eller feil i ekte forretningsmiljø
• Sjekk at det eksterne grensesnittet til nettstedet som f.eks UI fungerer som forventet og møter 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 er 2 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 det er 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.

• Run rate er forholdet mellom antall testcaser utført/total testcases av testspesifikasjonen. For eksempel har testspesifikasjonen totalt 120 TC-er, men testeren utførte bare 100 TC-er, så kjørehastigheten er 100/120 = 0.83 (83 %)
• Bestått rate er forholdet mellom tall testsaker bestått / testtilfeller utført. For eksempel, i over 100 utførte TC-er, er det 80 TC-er som har bestått, så beståttraten 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å høy bestått rate 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 Run rate obligatorisk 100%, men testteamet fullførte bare 90 % av testsakene. Det betyr at kjørehastigheten ikke er oppfylt, så IKKE bekreft utgangskriteriene

Trinn 5) Ressursplanlegging

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

Ressursplanleggingen er en viktig faktor i testplanleggingen fordi den hjelper bestemme de Antall av ressurser (ansatt, 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

Systemressurs

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

Trinn 6) Planlegg testmiljø

Hva er testmiljøet

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

Hvordan sette opp testmiljøet

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

For å fullføre denne oppgaven trenger du et sterkt samarbeid mellom testteam og utviklingsteam

Du bør stille utvikleren noen spørsmål for å forstå nettapplikasjonen som testes klart. 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 brukertilkoblingen som dette nettstedet kan håndtere samtidig?
• Hva er krav til maskinvare/programvare for å installere dette nettstedet?
• Trenger brukerens datamaskin noen spesiell innstilling for å surfe på nettstedet?

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

Trinn 7) Tidsplan og estimering

I artikkelen Test estimering, har du allerede brukt noen teknikker for å beregne innsatsen for å fullføre prosjektet. Nå bør du inkludere det estimatet så vel som tidsplanen i testplanleggingen

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

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

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

For å lage prosjektplanen trenger testlederen flere typer input som nedenfor:

• Ansatt- og prosjektfrist: Arbeidsdagene, prosjektfristen, ressurstilgjengeligheten er faktorene som påvirket tidsplanen
• Prosjektestimat: Basert på estimatet vet testlederen hvor lang tid det tar å fullføre prosjektet. Så han kan lage den passende prosjektplanen
• Prosjektrisiko : Å forstå risikoen hjelper Test Manager å legge nok ekstra tid til prosjektplanen til å håndtere risikoene

La oss øve med et eksempel:

Anta at sjefen ønsker å fullføre prosjektet Guru99 i en måned har du allerede estimert 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 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 sporbarhetsmatrise
• Feillogger og utførelseslogger.

Testleveranser leveres etter testsyklusene er over.

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

Ressurser

Last ned en prøvemal for testplan

Last ned prøvesystemtestplanen til nettstedet Guru99 Bank