Eksempel på testplanmal

Hva er en testplanmal?

A Testplanmal er et detaljert dokument som beskriver teststrategi, mål, tidsplan, estimering, leveranser og ressurser som kreves for testing. Det bidrar til å bestemme innsatsen som trengs for å validere kvaliteten og fungerer som en blåkopi kontrollert av testlederen.

Opprette en Testplan er obligatorisk for å sikre at testprosjektet ditt lykkes. Hvis du ikke har brukt det før, se Hvordan lage en testplan.

Last ned prøvemal for testplan

Struktur av testplanmal

Nedenfor er de viktige bestanddelene i en testplanmal, forklart i rekkefølge:

• 1. Innledning
• 1.1 Omfang
• 1.1.1 I omfang
• 1.1.2 Utenfor virkeområdet
• 1.2 Kvalitetsmål
• 1.3 Roller og ansvar
• 2. Testmetodikk
• 2.1 Oversikt
• 2.2 Testnivåer
• 2.3 Bug Triage
• 2.4 Suspensjonskriterier og gjenopptakelseskrav
• 2.5 Testfullstendighet
• 3. Testleveranser
• 4. Ressurs- og miljøbehov
• 4.1 Testverktøy
• 4.2 Testmiljø
• 5. Begreper/akronymer

1. Introduksjon

Innledningen gir en kort oversikt over teststrategiene, prosessene, arbeidsflyten og metodene som brukes i prosjektet.

1.1) Omfang

---

Omfanget er delt inn i to deler slik at testgrensen forblir entydig.

1.1.1) I omfang

In Scope definerer funksjonene, funksjonelle eller ikke-funksjonelle kravene til programvaren som vil være testet.

1.1.2) Utenfor virkeområde

Utenfor omfang definerer funksjonene, funksjonelle eller ikke-funksjonelle kravene til programvaren som vil IKKE være testet.

1.2) Kvalitetsmål

---

Her nevner du de overordnede målene som teamet planlegger å oppnå gjennom manuell testing og automatisert testing. Noen mål for et typisk testprosjekt inkluderer:

• Sørg for at applikasjonen under test (AUT) samsvarer med funksjonelle og ikke-funksjonelle krav.
• Sørg for at AUT-en oppfyller kvalitetsspesifikasjonene som er definert av kunden.
• Identifiser og fiks feil før applikasjonen legges ut.

1.3) Roller og ansvar

---

Gi en detaljert beskrivelse av rollene og ansvaret til de ulike involverte teammedlemmene, for eksempel:

• QA-analytiker
• Testleder
• Konfigurasjonsbehandling
• Utviklere
• Installasjonsteam

Blant andre.

👉 Meld deg på gratis live programvaretestingsprosjekt

2) Testmetodikk

Denne delen bestemmer livssyklusen, nivåene og reglene som brukes til å styre testutførelsen.

2.1) Oversikt

---

Nevn grunnen til at man bruker en bestemt testmetode for prosjektet. Testmetoden som er valgt for prosjektet kan være:

• Waterfall
• iterativ
• Agile
• Ekstrem programmering

Valg av metode avhenger av flere faktorer. Du kan lese mer om testmetodikk her..

2.2) Testnivåer

---

Testnivåer definerer hvilke typer testing som skal utføres på applikasjonen under test (AUT)De valgte nivåene avhenger hovedsakelig av prosjektets omfang, tids- og budsjettbegrensninger.

2.3) Bug Triage

---

Målet med feilsortering er å:

• Definer løsningstypen for hver feil.
• Prioriter feil og bestem en tidsplan for alle feil som «skal fikses».

2.4) Suspensjonskriterier og gjenopptakelseskrav

---

Kriterier for suspensjon definerer betingelsene der hele eller deler av testprosedyren skal settes på pause. Gjenopptakelseskriteriene bestemmer når testingen kan gjenopptas etter at den har blitt suspendert.

2.5) Testfullstendighet

---

Her definerer du kriteriene som vil anse testingen din som fullført. Vanlige kriterier for å sjekke testfullstendighet vil for eksempel være:

• 100 % testdekning oppnådd.
• Alle manuelle og automatiserte testtilfeller ble utført.
• Alle åpne feil er fikset eller planlagt for neste utgivelse.

3) Testleveranser

List opp alle artefakter som produseres i løpet av testsyklusen. Registrer dem på forhånd for å forhindre tapte overleveringer mellom team.

4) Ressurs- og miljøbehov

List opp verktøy og infrastruktur for å sikre budsjetter, lisenser og miljøer før utførelsen starter.

4.1) Testverktøy

---

Lag en liste over verktøy som:

• Krav Tracking Tool
• Bug Tracking Tool
• Automatisering Verktøy

Disse er nødvendige for å teste prosjektet effektivt.

4.2) Testmiljø

---

Nevn minimum maskinvare kravene som skal brukes til å teste applikasjonen.

Følgende programvare kreves i tillegg til klientspesifikk programvare:

• Windows 11 og over
• Microsoft 365 (eller Office 2021 og nyere)
• MS Exchange, etc.

5) Vilkår/akronymer

Dokumenter eventuelle termer eller akronymer som brukes i prosjektet, slik at nykommere kan lese planen uten tvetydighet.

Last ned testplanmalformatet ovenfor

Eksempel på testplandokument: Eksempel på nettapplikasjon for banktjenester

Følgende utarbeidede eksempel viser hvordan malen ovenfor fylles ut for Guru99 Bank nettapplikasjon.

1. Innledning

Testplanen foreskriver omfanget, tilnærmingen, ressursene og tidsplanen for alle testaktiviteter for Guru99 Bank-prosjekt. Det identifiserer elementene og funksjonene som skal testes, hvilke typer testing som utføres, ansvarlig personell og risikoene forbundet med planen.

1.1 Omfang

1.1.1 I omfang

Alle funksjonene til Guru99 Banknettsted definert i programvarekravet specs må testes.

Modulnavn	Gjeldende roller	Tekniske beskrivelser
Balanseforespørsel	Leder, kunde	Kunde: En kunde kan ha flere bankkontoer og kan bare se saldoen på sine egne kontoer. manager: En leder kan se saldoen til alle kunder under hans veiledning.
Overføring av midler	Leder, kunde	Kunde: En kunde kan overføre penger fra sin egen konto til en hvilken som helst destinasjonskonto. manager: En leder kan overføre midler fra en hvilken som helst kildekonto til en hvilken som helst destinasjonskonto.
Mini erklæring	Leder, kunde	En miniutskrift viser de siste 5 transaksjonene på en konto. Kunde: Ser kun miniutskriften av sine egne regnskaper. manager: Ser miniutskriften for enhver konto.
Tilpasset erklæring	Leder, kunde	En tilpasset utskrift filtrerer og viser transaksjoner i en konto etter dato eller transaksjonsverdi. Kunde: Kun hans egne kontoer. manager: Enhver konto.
Endre passord	Leder, kunde	Kunde: Kan endre passordet til sin egen konto. manager: Kan endre passordet til sin egen konto, men ikke til kundene sine.
Ny kunde	Leder	manager: En leder kan legge til en ny kunde.
Rediger kunde	Leder	manager: Kan redigere detaljer som adresse, e-post og telefonnummer til en kunde.
Ny konto	Leder	Systemet tilbyr to kontotyper: Sparekonto og brukskonto. En kunde kan ha flere sparekontoer (enkeltkonto eller felleskonto) og flere brukskontoer. manager: Kan legge til en ny konto for en eksisterende kunde.
Rediger bruker	Leder	manager: Kan redigere kontodetaljer for en eksisterende konto.
Slett konto	Leder	manager: Kan slette en konto som tilhører en kunde.
Slett kunde	Leder	En kunde kan bare slettes hvis hun ikke har noen aktive bruks- eller sparekontoer. manager: Kan slette en kunde.
Innskudd	Leder	manager: Kan sette inn penger på hvilken som helst konto, vanligvis når kontanter settes inn i en bankfilial.
Tilbaketrekking	Leder	manager: Kan ta ut penger fra enhver konto, vanligvis når kontanter tas ut i en bankfilial.

1.1.2 Utenfor virkeområdet

Disse funksjonene er ikke testet fordi de ikke er en del av programvarekravspesifikasjonene:

• Brukergrensesnitt
• Maskinvaregrensesnitt
• Programvaregrensesnitt
• Logisk databasedesign
• Kommunikasjonsgrensesnitt
• Nettstedets sikkerhet og ytelse

1.2 Kvalitetsmål

Testmålene er å verifisere funksjonaliteten til Guru99 Banks nettsted. Prosjektet bør fokusere på å teste bankvirksomhet, som for eksempel kontoadministrasjon, uttak og saldoforespørsel, til garantere at alle disse operasjonene fungerer normalt i et reelt forretningsmiljø.

1.3 Roller og ansvar

Prosjektet bør bruke outsourcet medlemmer som testere for å spare på prosjektkostnader.

Nei.	Medlem	Oppgaver
1.	Testleder	Styrer hele prosjektet, definerer prosjektets retning og anskaffer nødvendige ressurser.
2.	tester	Identifiserer og beskriver passende testteknikker, verktøy og automatiseringsarkitektur; verifiserer testtilnærmingen; utfører tester; logger resultater; rapporterer feil. Outsourcede medlemmer.
3.	Utvikler i test	Implementerer testtilfeller, testprogrammer, testsuiter, etc.
4.	Test administrator	Bygger og vedlikeholder testmiljøet og -ressursene; støtter testere under utførelse.
5.	SQA medlemmer	Ta ansvar for kvalitetssikring og bekreft om testprosessen oppfyller de spesifiserte kravene.

2. Testmetodikk

2.1 Oversikt

Ocuco Guru99 Bank-prosjektet følger en agilvennlig testmetodikk, som lar testere tilpasse seg raske utviklingssprinter samtidig som de opprettholder strukturert dokumentasjon.

2.2 Testnivåer

på Guru99 Bank-prosjektet, tre typer testing bør utføres:

• Integrasjonstesting: Individuelle programvaremoduler kombineres og testes som en gruppe.
• Systemtesting: Gjennomført på et komplett, integrert system for å evaluere samsvar med spesifiserte krav.
• API-testing: Tester alle API-er som eksponeres av programvaren som testes.

2.3 Bug Triage

Møter for feilvurdering holdes to ganger i uken for å klassifisere alvorlighetsgraden av feilen, eieren og målrettet utgivelse.

2.4 Suspensjonskriterier og gjenopptakelseskrav

If 40% av testtilfeller har mislyktes, stopp testingen inntil utviklingsteamet har rettet alle feiltilfeller.

2.5 Testfullstendighet

• Spesifiserer kriteriene som angir en vellykket fullføring av en testfase.
• Løpsrate er obligatorisk kl. 100% med mindre det er gitt en klar grunn.
• Passrate is 80%å oppnå beståttprosenten er obligatorisk.

2.6 Prosjektoppgaver, estimering og tidsplan

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

Tidsplan: Teamet forplikter seg til å fullføre disse oppgavene i løpet av det avtalte testsyklusvinduet.

3. Testleveranser

Testleveranser for Guru99 Bank-prosjektet er organisert i tre faser.

Før testfasen:

• Testplandokument.
• Testtilfeller dokumenter.
• Spesifikasjoner for testdesign.

I løpet av testfasen:

• Simulatorer for testverktøy.
• Test data.
• Test traceffektivitetsmatrise, feillogger og utførelseslogger.

Etter at testsyklusene er over:

• Testresultater og rapporter.
• Feilmelding.
• Retningslinjer for installasjon og testprosedyre.
• Utgivelsesnotater.

4. Ressurs- og miljøbehov

4.1 Testverktøy

Nei.	Ressurser	Tekniske beskrivelser
1.	Server	En databaseserver som kjører MySQL og en webserver som kjører Apache.
2.	Testverktøy	Et verktøy som kan automatisk generere testresultater i et forhåndsdefinert skjema og automatisere testkjøring.
3.	Network	Et LAN gigabit-oppsett og én internettlinje med en minimumshastighet på 5 Mb/s.
4.	datamaskin	Minst 4 arbeidsstasjoner i gang Windows 11, med 8 GB RAM og en 3.4 GHz CPU.

4.2 Testmiljø

Dette underavsnittet viser minimumskravene til maskinvare og programvare som brukes til å teste applikasjonen. Følgende programvare kreves i tillegg til klientspesifikk programvare:

• Windows 11 og over
• Microsoft 365 (eller Office 2021 og nyere)
• MS Exchange, etc.

Hvordan AI hjelper med testplanlegging

Moderne testplanlegging bruker i økende grad kunstig intelligens til å komprimere innsats og avdekke blindsoner. Generative assistenter som ChatGPT, Claude eller Gemini kan utarbeide en innledende testplan fra et kravdokument, foreslå manglende kanttilfeller og produsere traceability-matriser automatisk. Maskinlæringsmodeller flagger risikable moduler fra historiske feildata, helping Testlederen fokuserer innsatsen der det betyr mest.

AI-assistanse erstatter imidlertid ikke menneskelig dømmekraft. RevIakttakere må validere omfang, regulatorisk dekning og forretningsintensjon før de godkjenner en AI-generert plan. Behandle AI-forslag som et førsteutkast, ikke det endelige dokumentet.

Beste praksis for en effektiv testplan

En godt skrevet testplan sørger for at alle interessenter er på linje. Bruk disse beste praksisene når du skriver dokumentet ditt:

• Hold det kortfattet: Bruk tydelig språk og punktlister; unngå sjargong som bremser lesere som ikke er eksperter på kvalitetssikring.
• Klare det Reviewable: Del tidlig med utviklere og forretningsanalytikere for å fange opp manglende krav.
• Kvantifiser utgangskriterier: Definer numerisk dekning, beståttprosent og terskler for feil.
• Knytt risikoer til avbøtende tiltak: Kombiner enhver risiko med en inneslutnings- eller reservestrategi.
• Versjonskontroll av planen: Lagre det i et dokumentasjonsverktøy for å track endringer på tvers av prosjektet.

Spørsmål og svar