Eksempel på skabelon til testplan
Thomas Hamilton
⚡ Smart opsummering
Testplanskabelonen indeholder den strategi, det omfang, den tidsplan, de leverancer og de ressourcer, der kræves for at validere softwarekvaliteten. Dette dokument fungerer som en kontrolleret plan, der driver enhver testaktivitet og skærper ansvarligheden på tværs af udgivelser.
Hvad er en skabelon til testplan?
A Test plan skabelon er et detaljeret dokument, der beskriver teststrategi, mål, tidsplan, estimering, leverancer og ressourcer, der kræves til testning. Det hjælper med at bestemme den nødvendige indsats for at validere kvaliteten og fungerer som en skabelon, der kontrolleres af testmanageren.
Oprettelse af en Testplan er obligatorisk for at sikre succes med dit testprojekt. Hvis du er nybegynder, kan du se Sådan opretter du en testplan.
Download prøveskabelon for testplan
Struktur af skabelon til testplan
Nedenfor er de vigtige bestanddele af en testplanskabelon, forklaret i rækkefølge:
- 1. Introduktion
- 1.1 Anvendelsesområde
- 1.1.1 I omfang
- 1.1.2 Uden for anvendelsesområde
- 1.2 Kvalitetsmål
- 1.3 Roller og ansvar
- 2. Testmetode
- 2.1 Oversigt
- 2.2 Testniveauer
- 2.3 Fejltriage
- 2.4 Suspensionskriterier og genoptagelseskrav
- 2.5 Test fuldstændighed
- 3. Testleverancer
- 4. Ressource- og miljøbehov
- 4.1 Testværktøjer
- 4.2 Testmiljø
- 5. Begreber/akronymer
1) Introduktion
Introduktionen giver et kort overblik over de teststrategier, processer, arbejdsgange og metoder, der anvendes i projektet.
1.1) Omfang
Omfanget er opdelt i to dele, så testgrænsen forbliver entydig.
1.1.1) I omfang
In Scope definerer funktionerne, funktionelle eller ikke-funktionelle krav til den software, der vil være testet.
1.1.2) Uden for anvendelsesområde
Uden for omfang definerer funktionerne, funktionelle eller ikke-funktionelle krav til den software, der vil ikke være testet.
1.2) Kvalitetsmål
Her nævner du de overordnede mål, som teamet planlægger at opnå gennem manuel testning og automatiseret testning. Nogle mål for et typisk testprojekt inkluderer:
- Sørg for, at den testede applikation (AUT) overholder funktionelle og ikke-funktionelle krav.
- Sørg for, at AUT'en opfylder de kvalitetsspecifikationer, der er defineret af kunden.
- Identificer og ret fejl, før applikationen går live.
1.3) Roller og ansvar
Giv en detaljeret beskrivelse af de forskellige involverede teammedlemmers roller og ansvarsområder, såsom:
- QA analytiker
- Test Manager
- konfigurationsmanager
- Udviklere
- Installationsteam
Blandt andre.
👉 Tilmeld dig et gratis live softwaretestprojekt
2) Testmetode
Dette afsnit fastlægger livscyklussen, niveauerne og reglerne, der bruges til at styre testudførelsen.
2.1) Overblik
Angiv årsagen til at anvende en bestemt testmetode til projektet. Den valgte testmetode til projektet kunne være:
- Vandfald
- iterativ
- Agile
- Ekstrem programmering
Den valgte metode afhænger af flere faktorer. Du kan læse mere om testmetoder link..
2.2) Testniveauer
Testniveauer definerer de typer test, der skal udføres på den applikation, der testes (AUT).De valgte niveauer afhænger primært af projektets omfang, tids- og budgetmæssige begrænsninger.
2.3) Bug Triage
Målet med fejltriage er at:
- Definer løsningstypen for hver fejl.
- Prioritér fejl, og fastlæg en tidsplan for alle fejl, der "skal rettes".
2.4) Suspensionskriterier og genoptagelseskrav
Suspensionskriterier definerer de betingelser, hvorunder hele eller dele af testproceduren sættes på pause. Genoptagelseskriterier bestemmer, hvornår testningen kan genoptages efter at være blevet suspenderet.
2.5) Test fuldstændighed
Her definerer du de kriterier, der vil anse din test for fuldført. For eksempel ville almindelige kriterier for at kontrollere testens fuldstændighed være:
- 100% testdækning opnået.
- Alle manuelle og automatiserede testcases blev udført.
- Alle åbne fejl er rettet eller planlagt til næste udgivelse.
3) Test leverancer
Lav en liste over alle artefakter, der produceres i løbet af testcyklussen. Registrer dem på forhånd for at forhindre overdragelser mellem teams.
|
4) Ressource- og miljøbehov
List værktøjer og infrastruktur for at sikre budgetter, licenser og miljøer, før udførelsen påbegyndes.
4.1) Testværktøjer
Lav en liste over værktøjer såsom:
- Krav Tracking Værktøj
- Bug Tracking Værktøj
- Automation Værktøj
Disse er nødvendige for at teste projektet effektivt.
4.2) Testmiljø
Nævn minimum hardware krav, der vil blive brugt til at teste applikationen.
Følgende software kræves ud over klientspecifik software:
- Windows 11 og derover
- Microsoft 365 (eller Office 2021 og nyere)
- MS Exchange osv.
5) Begreber/akronymer
Dokumentér alle termer eller akronymer, der bruges i projektet, så nyankomne kan læse planen uden tvetydighed.
| TERM/AKRONYM | DEFINITION |
|---|---|
| API | Applikationsprogramgrænseflade |
| AUT | Ansøgning under test |
Download ovenstående testplanskabelonformat
Eksempel på testplandokument: Eksempel på webapplikation til banktjenester
Følgende eksempel viser, hvordan ovenstående skabelon udfyldes for Guru99 Bank webapplikation.
1. Introduktion
Testplanen foreskriver omfanget, tilgangen, ressourcerne og tidsplanen for alle testaktiviteter for Guru99 Bank-projekt. Det identificerer de elementer og funktioner, der skal testes, de typer test, der udføres, det ansvarlige personale og de risici, der er forbundet med planen.
1.1 Anvendelsesområde
1.1.1 I omfang
Alle funktioner i Guru99 Bankwebsted defineret i softwarekravet specs skal testes.
| Modul Navn | Gældende roller | Beskrivelse |
|---|---|---|
| Balanceundersøgelse | Leder, Kunde | Kunde: En kunde kan have flere bankkonti og kan kun se saldoen på sine egne konti. Manager: En leder kan se saldoen på alle kunder under hans/hendes ledelse. |
| Pengeoverførsel | Leder, Kunde | Kunde: En kunde kan overføre penge fra sin egen konto til enhver destinationskonto. Manager: En administrator kan overføre penge fra enhver kildekonto til enhver destinationskonto. |
| Mini erklæring | Leder, Kunde | En mini-opgørelse viser de seneste 5 transaktioner på en konto. Kunde: Ser kun mini-opgørelsen over sine egne regnskaber. Manager: Ser mini-opgørelsen for enhver konto. |
| Tilpasset erklæring | Leder, Kunde | En brugerdefineret opgørelse filtrerer og viser transaktioner på en konto efter dato eller transaktionsværdi. Kunde: Kun hans egne konti. Manager: Enhver konto. |
| Skift adgangskode | Leder, Kunde | Kunde: Kan ændre adgangskoden til sin egen konto. Manager: Kan ændre adgangskoden til sin egen konto, men ikke til sine kunders. |
| Ny kunde | Manager | Manager: En leder kan tilføje en ny kunde. |
| Rediger kunde | Manager | Manager: Kan redigere oplysninger såsom en kundes adresse, e-mail og telefonnummer. |
| Ny konto | Manager | Systemet tilbyder 2 kontotyper: Opsparing og løbende konto. En kunde kan have flere opsparingskonti (enkelt- eller fælleskonti) og flere løbende konti. Manager: Kan tilføje en ny konto for en eksisterende kunde. |
| Rediger konto | Manager | Manager: Kan redigere kontooplysninger for en eksisterende konto. |
| Slet konto | Manager | Manager: Kan slette en konto, der tilhører en kunde. |
| Slet kunde | Manager | En kunde kan kun slettes, hvis hun ikke har aktive løbende konti eller opsparingskonti. Manager: Kan slette en kunde. |
| Depositum | Manager | Manager: Kan indsætte penge på enhver konto, typisk når kontanter indsættes i en bankfilial. |
| Tilbagetrækning | Manager | Manager: Kan hæve penge fra enhver konto, typisk når kontanter hæves i en bankfilial. |
1.1.2 Uden for anvendelsesområde
Disse funktioner er ikke testet, da de ikke er en del af softwarekravspecifikationerne:
- Brugergrænseflader
- Hardware -grænseflader
- Software grænseflader
- Logisk databasedesign
- Kommunikationsgrænseflader
- Hjemmesidesikkerhed og ydeevne
1.2 Kvalitetsmål
Testens mål er at verificere funktionaliteten af Guru99 Banks hjemmeside. Projektet bør fokusere på at teste bankdrift, såsom kontoadministration, udbetalinger og saldoforespørgsler, til garanti at alle disse operationer fungerer Normalt i et rigtigt forretningsmiljø.
1.3 Roller og ansvar
Projektet skal bruge outsourcet medlemmer som testere for at spare på projektomkostninger.
| Nej. | Medlem | Opgaver |
|---|---|---|
| 1. | Test Manager | Styrer hele projektet, definerer projektretningen og anskaffer passende ressourcer. |
| 2. | tester | Identificerer og beskriver passende testteknikker, værktøjer og automatiseringsarkitektur; verificerer testtilgangen; udfører tests; logger resultater; rapporterer fejl. Outsourcede medlemmer. |
| 3. | Udvikler i test | Implementerer testcases, testprogrammer, testsuiter osv. |
| 4. | Test administrator | Opbygger og vedligeholder testmiljøet og -aktiverne; understøtter testere under udførelsen. |
| 5. | SQA medlemmer | Tag ansvar for kvalitetssikring og bekræft, om testprocessen opfylder de specificerede krav. |
2. Testmetode
2.1 Oversigt
Guru99 Bank-projektet følger en agilvenlig testmetode, der giver testere mulighed for at tilpasse sig hurtige udviklingssprints, samtidig med at struktureret dokumentation opretholdes.
2.2 Testniveauer
I Guru99 Bank-projektet, bør der udføres tre typer test:
- Integrationstest: Individuelle softwaremoduler kombineres og testes som en gruppe.
- Systemtest: Udført på et komplet, integreret system for at evaluere overholdelse af specificerede krav.
- API-testning: Tester alle API'er, der eksponeres af den testede software.
2.3 Fejltriage
Der afholdes fejldiagnosemøder to gange om ugen for at klassificere fejlens alvorlighedsgrad, ejer og målrettet udgivelse.
2.4 Suspensionskriterier og genoptagelseskrav
If 40% af testtilfælde har mislykkedes, suspender testningen, indtil udviklingsteamet har rettet alle fejlede tilfælde.
2.5 Test fuldstændighed
- Angiver de kriterier, der betegner en vellykket afslutning af en testfase.
- Løbehastighed er obligatorisk kl. 100% medmindre der er givet en klar begrundelse.
- Pass rate is 80%; at opnå beståelsesprocenten er obligatorisk.
2.6 Projektopgaver, estimering og tidsplan
| Opgaver | Medlemmer | Estimeret indsats |
|---|---|---|
| Opret testspecifikationen | Test designer | 170 mandetimer |
| Udfør testudførelse | Tester, testadministrator | 80 mandetimer |
| Test rapport | tester | 10 mandetimer |
| Test levering | Test Manager | 20 mandetimer |
| Samlet beløb | — | 280 mandetimer |
Køreplan: Teamet forpligter sig til at udføre disse opgaver inden for det aftalte testcyklusvindue.
3. Testleverancer
Testleverancer for Guru99 Bank-projektet er organiseret i tre faser.
Før testfasen:
- Dokument om testplan.
- Test tilfælde Dokumenter.
- Specifikationer for testdesign.
Under testfasen:
- Simulatorer for testværktøjer.
- Test data.
- Test traceffektivitetsmatrix, fejllogfiler og udførelseslogfiler.
Efter testcyklusserne er overstået:
- Testresultater og rapporter.
- Fejlrapport.
- Retningslinjer for installations- og testprocedure.
- Udgivelsesnoter.
4. Ressource- og miljøbehov
4.1 Testværktøjer
| Nej. | Resource | Beskrivelse |
|---|---|---|
| 1. | Server | En databaseserver kører MySQL og en webserver, der kører Apache. |
| 2. | Test værktøj | Et værktøj, der automatisk kan generere testresultater i en foruddefineret form og automatisere testudførelsen. |
| 3. | Netværk | En LAN gigabit-opsætning og én internetlinje med en minimumshastighed på 5 Mb/s. |
| 4. | Computer | Mindst 4 arbejdsstationer kørende Windows 11, med 8 GB RAM og en 3.4 GHz CPU. |
4.2 Testmiljø
Dette underafsnit angiver minimumskravene til hardware og software, der bruges til at teste applikationen. Følgende software er påkrævet ud over klientspecifik software:
- Windows 11 og derover
- Microsoft 365 (eller Office 2021 og nyere)
- MS Exchange osv.
Hvordan AI hjælper med testplanlægning
Moderne testplanlægning bruger i stigende grad kunstig intelligens til at komprimere indsatsen og afdække blinde vinkler. Generative assistenter som ChatGPT, Claude eller Gemini kan udarbejde en indledende testplan ud fra et kravdokument, foreslå manglende kanttilfælde og producere traceability-matricer automatisk. Maskinlæringsmodeller markerer risikable moduler fra historiske defektdata, helping Testmanageren fokuserer indsatsen der, hvor det betyder mest.
AI-assistance erstatter dog ikke menneskelig dømmekraft. RevIagttagere skal validere omfang, lovgivningsmæssig dækning og forretningsintention, før de godkender en AI-genereret plan. Betragt AI-forslag som et første udkast, ikke det endelige dokument.
De bedste fremgangsmåder for en effektiv testplan
En velskrevet testplan sørger for, at alle interessenter er på linje. Anvend disse bedste fremgangsmåder, når du udarbejder dit dokument:
- Hold det kortfattet: Brug et klart sprog og punktlister; undgå jargon, der sinker læsere, der ikke er QA-kyndige.
- Lav det Reviewable: Del tidligt med udviklere og forretningsanalytikere for at opdage manglende krav.
- Kvantificér exitkriterier: Definer numerisk dækning, beståelsesprocent og defekttærskler.
- Knyt risici til afbødninger: Kombiner enhver risiko med en inddæmnings- eller reservestrategi.
- Versionskontrol af planen: Gem det i et dokumentationsværktøj for at track ændringer på tværs af projektet.
