Exempel på testplanmall

Vad är en testplanmall?

A Testplanmall är ett detaljerat dokument som beskriver teststrategi, mål, schema, uppskattning, leveranser och resurser som krävs för testning. Det hjälper till att fastställa den insats som krävs för att validera kvalitet och fungerar som en ritning som kontrolleras av testledaren.

Skapa ett Testplan är obligatoriskt för att säkerställa att ditt testprojekt lyckas. Om du är nybörjare, se Hur man skapar en testplan.

Ladda ner provmall för testplan

Struktur för testplanmall

Nedan följer de viktiga beståndsdelarna i en testplanmall, förklarade i ordning:

• 1. Inledning
• 1.1 Omfattning
• 1.1.1 I omfattning
• 1.1.2 Utanför tillämpningsområdet
• 1.2 Kvalitetsmål
• 1.3 Roller och ansvar
• 2. Testmetodik
• 2.1 Översikt
• 2.2 Testnivåer
• 2.3 Bugg triage
• 2.4 Avstängningskriterier och återupptagandekrav
• 2.5 Testets fullständighet
• 3. Testresultat
• 4. Resurs- och miljöbehov
• 4.1 Testverktyg
• 4.2 Testmiljö
• 5. Termer/Akronymer

1) Introduktion

Introduktionen ger en kort översikt över de teststrategier, processer, arbetsflöden och metoder som används för projektet.

1.1) Räckvidd

---

Omfattningen är uppdelad i två delar så att testgränsen förblir entydig.

1.1.1) I omfattning

In Scope definierar funktionerna, funktionella eller icke-funktionella kraven för programvaran som kommer vara testat.

1.1.2) Utanför tillämpningsområdet

Utanför omfattningen definierar funktionerna, funktionella eller icke-funktionella kraven för programvaran som kommer inte att vara testat.

1.2) Kvalitetsmål

---

Här nämner du de övergripande mål som teamet planerar att uppnå genom manuell testning och automatiseringstestning. Några mål för ett typiskt testprojekt inkluderar:

• Säkerställ att den testade applikationen (AUT) uppfyller funktionella och icke-funktionella krav.
• Säkerställ att AUT:n uppfyller de kvalitetsspecifikationer som definierats av kunden.
• Identifiera och åtgärda buggar innan applikationen lanseras.

1.3) Roller och ansvar

---

Ge en detaljerad beskrivning av de olika inblandade teammedlemmarnas roller och ansvarsområden, såsom:

• QA-analysör
• Test Manager
• Konfigurationshanteraren
• Utvecklare
• Installationsteam

Bland andra.

👉 Anmäl dig till gratis live-mjukvarutestningsprojekt

2) Testmetodik

Det här avsnittet fastställer livscykeln, nivåerna och reglerna som används för att styra testkörningen.

2.1) Översikt

---

Ange anledningen till att en viss testmetod har använts för projektet. Den testmetod som valts för projektet kan vara:

• Vattenfall
• iterativ
• Agile
• Extrem programmering

Vilken metod som väljs beror på flera faktorer. Du kan läsa mer om testmetodik här..

2.2) Testnivåer

---

Testnivåer definierar vilka typer av tester som ska utföras på den testade applikationen (AUT)De valda nivåerna beror främst på projektets omfattning, tids- och budgetbegränsningar.

2.3) Bugg triage

---

Målet med buggtriage är att:

• Definiera typ av lösning för varje bugg.
• Prioritera buggar och fastställ ett schema för alla buggar som "ska åtgärdas".

2.4) Avstängningskriterier och återupptagandekrav

---

Avstängningskriterierna definierar de villkor under vilka hela eller delar av testproceduren pausas. Återupptagningskriterierna avgör när testningen kan återupptas efter att den har avbrutits.

2.5) Testets fullständighet

---

Här definierar du kriterierna som kommer att bedöma att din testning är slutförd. Vanliga kriterier för att kontrollera testets fullständighet skulle till exempel vara:

• 100 % testtäckning uppnådd.
• Alla manuella och automatiserade testfall kördes.
• Alla öppna buggar är åtgärdade eller planerade för nästa utgåva.

3) Testa leveranser

Lista alla artefakter som produceras under testcykeln. Registrera dem i förväg för att förhindra missade överlämningar mellan team.

4) Resurs- och miljöbehov

Lista verktyg och infrastruktur för att säkra budgetar, licenser och miljöer innan genomförandet påbörjas.

4.1) Testverktyg

---

Gör en lista över verktyg som till exempel:

• Krav Tracking Verktyget
• Bug Tracking Verktyget
• Automatiseringsverktyg

Dessa krävs för att testa projektet effektivt.

4.2) Testmiljö

---

Nämn det minsta hårdvara krav som kommer att användas för att testa applikationen.

Följande programvara krävs utöver klientspecifik programvara:

• Windows 11 och över
• Microsoft 365 (eller Office 2021 och senare)
• MS Exchange, etc.

5) Termer/Akronymer

Dokumentera alla termer eller akronymer som används i projektet så att nykomlingar kan läsa planen utan tvetydigheter.

Ladda ner ovanstående testplanmallformat

Exempel på testplandokument: Exempel på webbapplikation för banktjänster

Följande utförda exempel visar hur mallen ovan fylls i för Guru99 Bank webbapplikation.

1. Inledning

Testplanen föreskriver omfattning, tillvägagångssätt, resurser och schema för alla testaktiviteter för Guru99 Bankprojekt. Det identifierar de objekt och funktioner som ska testas, de typer av tester som utförs, ansvarig personal och de risker som är förknippade med planen.

1.1 Omfattning

1.1.1 I omfattning

Alla funktioner i Guru99 Bankwebbplats definierad i programvarukravet specifikationer behöver testas.

Modulnamn	Tillämpliga roller	BESKRIVNING
Balansförfrågan	Chef, kund	kund: En kund kan ha flera bankkonton och kan bara se saldon på sina konton. Manager: En chef kan se saldot för alla kunder under hans/hennes övervakning.
Fondöverföring	Chef, kund	kund: En kund kan överföra pengar från sitt eget konto till vilket destinationskonto som helst. Manager: En förvaltare kan överföra pengar från vilket källkonto som helst till vilket destinationskonto som helst.
Mini uttalande	Chef, kund	Ett miniutdrag visar de senaste 5 transaktionerna för ett konto. kund: Ser endast miniutdraget från sina egna konton. Manager: Ser miniutdraget för alla konton.
Anpassat uttalande	Chef, kund	Ett anpassat utdrag filtrerar och visar transaktioner i ett konto efter datum eller transaktionsvärde. kund: Endast hans egna konton. Manager: Vilket konto som helst.
Ändra lösenord	Chef, kund	kund: Kan ändra lösenordet för sitt eget konto. Manager: Kan ändra lösenordet för sitt eget konto men inte för sina kunders.
Ny kund	chef	Manager: En chef kan lägga till en ny kund.
Redigera kund	chef	Manager: Kan redigera uppgifter som adress, e-postadress och telefonnummer för en kund.
Nytt konto	chef	Systemet erbjuder två kontotyper: Sparkonto och löpandekonto. En kund kan ha flera sparkonton (enskilda eller gemensamma) och flera löpandekonton. Manager: Kan lägga till ett nytt konto för en befintlig kund.
Redigera konto	chef	Manager: Kan redigera kontouppgifter för ett befintligt konto.
Radera konto	chef	Manager: Kan radera ett konto som tillhör en kund.
Ta bort kund	chef	En kund kan endast raderas om hen inte har några aktiva löpande konton eller sparkonton. Manager: Kan ta bort en kund.
Deposition	chef	Manager: Kan sätta in pengar på vilket konto som helst, vanligtvis när kontanter sätter in på ett bankkontor.
Tillbakadragande	chef	Manager: Kan ta ut pengar från vilket konto som helst, vanligtvis när kontanter tas ut på ett bankkontor.

1.1.2 Utanför tillämpningsområdet

Dessa funktioner testas inte eftersom de inte ingår i programvarans kravspecifikationer:

• Användargränssnitt
• Hårdvarugränssnitt
• Mjukvarugränssnitt
• Databaslogisk design
• Kommunikationsgränssnitt
• Webbplatssäkerhet och prestanda

1.2 Kvalitetsmål

Testmålen är att verifiera funktionaliteten hos Guru99 Banks webbplats. Projektet bör fokusera på att testa bankverksamhet, såsom kontohantering, uttag och saldoförfrågan, till garanti att alla dessa operationer fungerar normalt i en verklig affärsmiljö.

1.3 Roller och ansvar

Projektet bör använda utlagd medlemmar som testare för att spara på projektkostnader.

Nej.	Medlem	Uppgifter
1.	Test Manager	Leder hela projektet, definierar projektets inriktning och anskaffar lämpliga resurser.
2.	Testare	Identifierar och beskriver lämpliga testtekniker, verktyg och automatiseringsarkitektur; verifierar testmetoden; utför tester; loggar resultat; rapporterar fel. Outsourcar medlemmar.
3.	Utvecklare i test	Implementerar testfall, testprogram, testsviter etc.
4.	Testadministratör	Bygger och underhåller testmiljön och resurserna; stödjer testare under körning.
5.	SQA-medlemmar	Ta ansvar för kvalitetssäkring och bekräfta att testprocessen uppfyller de specificerade kraven.

2. Testmetodik

2.1 Översikt

Ocuco-landskapet Guru99 Bank-projektet följer en agilvänlig testmetodik, vilket gör det möjligt för testare att anpassa sig till snabba utvecklingssprintar samtidigt som de bibehåller strukturerad dokumentation.

2.2 Testnivåer

I Guru99 Bank-projektet, tre typer av tester bör utföras:

• Integrationstestning: Enskilda programvarumoduler kombineras och testas som en grupp.
• Systemtestning: Genomförs på ett komplett, integrerat system för att utvärdera efterlevnaden av specificerade krav.
• API-testning: Testar varje API som exponeras av den testade programvaran.

2.3 Bugg triage

Möten för felbedömning hålls två gånger i veckan för att klassificera felets allvarlighetsgrad, ägare och mål för felsökning.

2.4 Avstängningskriterier och återupptagandekrav

If 40% av testfallen har misslyckades, pausa testningen tills utvecklingsteamet har åtgärdat alla misslyckade fall.

2.5 Testets fullständighet

• Anger kriterierna som betecknar a framgångsrik slutförandet av en testfas.
• Löphastighet är obligatoriskt kl. 100% om inte ett tydligt skäl ges.
• Passräntan is 80%att uppnå godkändfrekvensen är obligatoriskt.

2.6 Projektuppgifter, uppskattning och schema

uppgift	Medlemmar	Uppskattad ansträngning
Skapa testspecifikationen	Testdesigner	170 mantimmar
Utför testkörning	Testare, testadministratör	80 mantimmar
Testrapport rapport~~POS=HEADCOMP	Testare	10 mantimmar
Provleverans	Test Manager	20 mantimmar
Totalt	-	280 mantimmar

Schema: Teamet åtar sig att slutföra dessa uppgifter inom det överenskomna testcykelfönstret.

3. Testresultat

Testleveranser för Guru99 Bank-projektet är organiserat i tre faser.

Före testfasen:

• Testplandokument.
• Testfall dokument.
• Specifikationer för testdesign.

Under testfasen:

• Simulatorer för testverktyg.
• Testdata.
• Testa traceffektivitetsmatris, felloggar och körningsloggar.

Efter att testcyklerna är över:

• Testresultat och rapporter.
• Felanmälan.
• Riktlinjer för installation och testprocedur.
• Versionsinformation.

4. Resurs- och miljöbehov

4.1 Testverktyg

Nej.	Resurs	BESKRIVNING
1.	server	En databasserver som körs MySQL och en webbserver som kör Apache.
2.	Testverktyg	Ett verktyg som automatiskt kan generera testresultat i ett fördefinierat formulär och automatisera testkörning.
3.	nätverks	En LAN gigabit-installation och en internetlinje med en minsta hastighet på 5 Mb/s.
4.	Dator	Minst 4 arbetsstationer igång Windows 11, med 8 GB RAM och en 3.4 GHz-processor.

4.2 Testmiljö

Detta avsnitt listar de lägsta hårdvaru- och mjukvarukrav som används för att testa applikationen. Följande programvara krävs utöver klientspecifik programvara:

• Windows 11 och över
• Microsoft 365 (eller Office 2021 och senare)
• MS Exchange, etc.

Hur AI hjälper till vid testplanering

Modern testplanering använder alltmer AI för att komprimera ansträngning och upptäcka blinda fläckar. Generativa assistenter som ChatGPT, Claude eller Gemini kan utarbeta en initial testplan från ett kravdokument, föreslå saknade edge-fall och producera traceability-matriser automatiskt. Maskininlärningsmodeller flaggar riskfyllda moduler från historiska defektdata, helping Testchefen fokuserar insatserna där det är som viktigast.

AI-hjälp ersätter dock inte mänskligt omdöme. RevUtredare måste validera omfattning, regelverk och affärsavsikt innan de godkänner en AI-genererad plan. Behandla AI-förslag som ett första utkast, inte det slutgiltiga dokumentet.

Bästa praxis för en effektiv testplan

En välskriven testplan håller alla intressenter på rätt spår. Använd dessa bästa metoder när du skriver ditt dokument:

• Håll det kortfattat: Använd tydligt språk och punktlistor; undvik jargong som gör läsare som inte är QA-experter långsammare.
• Gör det Reviewable: Dela tidigt med utvecklare och affärsanalytiker för att upptäcka saknade krav.
• Kvantifiera utgångskriterier: Definiera numerisk täckning, godkännandegrad och tröskelvärden för defekter.
• Koppla risker till begränsningsåtgärder: Koppla ihop varje risk med en inneslutnings- eller reservstrategi.
• Versionskontrollera planen: Lagra det i ett dokumentationsverktyg för att track förändringar över hela projektet.

Vanliga frågor