Voorbeeld van een sjabloon voor een testplan

Wat is een testplansjabloon?

A Sjabloon voor testplan Het is een gedetailleerd document waarin de teststrategie, doelstellingen, planning, kostenraming, resultaten en benodigde middelen voor het testen worden beschreven. Het helpt bij het bepalen van de benodigde inspanning om de kwaliteit te valideren en dient als blauwdruk die door de testmanager wordt beheerd.

Een maken Testplan is essentieel voor het succes van uw testproject. Als u hier nog niet bekend mee bent, raadpleeg dan de volgende informatie. Hoe u een testplan maakt.

Download een voorbeeld van een testplansjabloon

Structuur van een sjabloon voor een testplan

Hieronder volgen de belangrijkste onderdelen van een testplansjabloon, in de aangegeven volgorde:

• 1. Inleiding
• 1.1 bereik
• 1.1.1 Binnen bereik
• 1.1.2 Buiten bereik
• 1.2 Kwaliteitsdoelstelling
• 1.3 rollen en verantwoordelijkheden
• 2. Testmethodologie
• 2.1 Overzicht
• 2.2 Testniveaus
• 2.3 Bugtriage
• 2.4 Opschortingscriteria en hervattingsvereisten
• 2.5 Testvolledigheid
• 3. Testresultaten
• 4. Behoeften op het gebied van hulpbronnen en milieu
• 4.1 Hulpmiddelen testen
• 4.2 Testomgeving
• 5. Termen/Afkortingen

1) Inleiding

De inleiding geeft een kort overzicht van de teststrategieën, -processen, -workflows en -methodologieën die voor het project zijn gebruikt.

1.1) Toepassingsgebied

---

De scope is opgesplitst in twee delen, zodat de testgrens eenduidig ​​blijft.

1.1.1) Binnen bereik

In Scope worden de kenmerken, functionele of niet-functionele eisen van de software gedefinieerd. zal zijn getest.

1.1.2) Buiten bereik

Buiten het toepassingsgebied worden de kenmerken, functionele of niet-functionele eisen van de software gedefinieerd die zal niet zijn getest.

1.2) Kwaliteitsdoelstelling

---

Hier noem je de algemene doelstellingen die het team wil bereiken door middel van handmatig testen en geautomatiseerd testen. Enkele doelstellingen van een typisch testproject zijn:

• Zorg ervoor dat de te testen applicatie (AUT) voldoet aan de functionele en niet-functionele eisen.
• Zorg ervoor dat de AUT voldoet aan de kwaliteitsspecificaties die door de klant zijn vastgesteld.
• Identificeer en verhelp bugs voordat de applicatie live gaat.

1.3) Rollen en verantwoordelijkheden

---

Geef een gedetailleerde beschrijving van de rollen en verantwoordelijkheden van de verschillende teamleden, zoals:

• QA-analist
• Testmanager
• Configuratiebeheer
• Developers
• Installatie Team

Onder andere.

👉 Schrijf je gratis in voor een live softwaretestproject

2) Testmethodologie

In dit gedeelte worden de levenscyclus, niveaus en regels bepaald die worden gebruikt om de testuitvoering te reguleren.

2.1) Overzicht

---

Geef de reden aan waarom voor deze specifieke testmethodologie is gekozen voor het project. De gekozen testmethodologie zou bijvoorbeeld kunnen zijn:

• Waterval
• iteratieve
• Behendig
• Extreem programmeren

De gekozen methodologie hangt af van meerdere factoren. U kunt meer lezen over testmethodologie. hier.

2.2) Testniveaus

---

Testniveaus definiëren de soorten tests die op de te testen applicatie (AUT) moeten worden uitgevoerd.De gekozen niveaus hangen voornamelijk af van de omvang van het project, de beschikbare tijd en de budgettaire beperkingen.

2.3) Bugtriage

---

Het doel van bugtriage is:

• Definieer het type oplossing voor elke bug.
• Geef prioriteit aan de bugs en bepaal een planning voor alle bugs die "opgelost moeten worden".

2.4) Opschortingscriteria en hervattingsvereisten

---

De criteria voor opschorting definiëren de voorwaarden waaronder de testprocedure geheel of gedeeltelijk wordt onderbroken. De criteria voor hervatting bepalen wanneer de tests na de opschorting kunnen worden hervat.

2.5) Volledigheid van de test

---

Hier definieert u de criteria die bepalen of uw test is voltooid. Veelgebruikte criteria om de volledigheid van een test te controleren zijn bijvoorbeeld:

• 100% testdekking behaald.
• Alle handmatige en geautomatiseerde testgevallen zijn uitgevoerd.
• Alle openstaande bugs zijn verholpen of staan ​​gepland voor de volgende release.

3) Testresultaten

Maak een lijst van alle artefacten die tijdens de testcyclus worden geproduceerd. Door ze van tevoren vast te leggen, worden overdrachten tussen teams voorkomen.

4) Behoeften aan hulpbronnen en milieu

Maak een lijst van de tools en infrastructuur om budgetten, licenties en omgevingen te beveiligen voordat de uitvoering begint.

4.1) Testhulpmiddelen

---

Maak een lijst van hulpmiddelen zoals:

• Voorwaarden Tracking Gereedschap
• Bug Tracking Gereedschap
• automatisering Gereedschap

Deze zijn nodig om het project effectief te testen.

4.2) Testomgeving

---

Vermeld het minimum hardware vereisten die gebruikt zullen worden om de applicatie te testen.

De volgende software Naast klantspecifieke software is het volgende vereist:

• Windows 11 en hoger
• Microsoft 365 (of Office 2021 en hoger)
• MS Exchange, enz.

5) Termen/acroniemen

Documenteer alle termen en afkortingen die in het project worden gebruikt, zodat nieuwkomers het plan zonder onduidelijkheden kunnen lezen.

Download het bovenstaande testplan-sjabloonformaat

Voorbeeld van een testplan: een webapplicatie voor de banksector

Het volgende uitgewerkte voorbeeld laat zien hoe de bovenstaande sjabloon wordt ingevuld voor de Guru99 Bank webapplicatie.

1. Inleiding

Het testplan beschrijft de omvang, aanpak, middelen en planning van alle testactiviteiten voor het GuruHet 99 Bank-project beschrijft de te testen onderdelen en kenmerken, de soorten tests die worden uitgevoerd, het verantwoordelijke personeel en de risico's die aan het plan verbonden zijn.

1.1 bereik

1.1.1 Binnen bereik

Alle functies van de GuruDe website van 99 Bank is gedefinieerd in de softwarevereisten. bril moeten worden getest.

Module Naam	Toepasselijke rollen	Beschrijving
Balans onderzoek	Manager, Klant	Klant: Een klant kan meerdere bankrekeningen hebben en kan alleen de saldi van zijn eigen rekeningen bekijken. Manager: Een manager kan het saldo van alle klanten onder zijn toezicht inzien.
Geld transfer	Manager, Klant	Klant: Een klant kan geld overmaken van zijn eigen rekening naar elke gewenste rekening. Manager: Een manager kan geld overmaken van elke bronrekening naar elke bestemmingsrekening.
Mini Statement	Manager, Klant	Een mini-afschrift toont de laatste 5 transacties van een rekening. Klant: Hij ziet alleen het beknopte overzicht van zijn eigen rekeningen. Manager: Toont het mini-overzicht van elke rekening.
Aangepaste verklaring	Manager, Klant	Een aangepast overzicht filtert en toont transacties in een rekening op datum of transactiewaarde. Klant: Uitsluitend zijn eigen verklaringen. Manager: Elk account.
Wachtwoord wijzigen	Manager, Klant	Klant: Hij kan het wachtwoord van zijn eigen account wijzigen. Manager: Hij kan het wachtwoord van zijn eigen account wijzigen, maar niet dat van zijn klanten.
Nieuwe klant	Manager	Manager: Een manager kan een nieuwe klant toevoegen.
Klant bewerken	Manager	Manager: Gegevens zoals adres, e-mailadres en telefoonnummer van een klant kunnen worden bewerkt.
Nieuw account	Manager	Het systeem biedt twee soorten rekeningen: spaarrekeningen en betaalrekeningen. Een klant kan meerdere spaarrekeningen (alleen of samen) en meerdere betaalrekeningen aanhouden. Manager: Je kunt een nieuw account aanmaken voor een bestaande klant.
Bewerk je account	Manager	Manager: Je kunt de accountgegevens van een bestaand account bewerken.
Account verwijderen	Manager	Manager: Een account van een klant kan worden verwijderd.
Klant verwijderen	Manager	Een klant kan alleen worden verwijderd als zij geen actieve lopende of spaarrekeningen heeft. Manager: Een klant kan worden verwijderd.
Statiegeld	Manager	Manager: Je kunt geld storten op elke rekening, meestal wanneer je contant geld stort bij een bankfiliaal.
Opname	Manager	Manager: Je kunt geld opnemen van elke rekening, meestal wanneer je contant geld opneemt bij een bankfiliaal.

1.1.2 Buiten bereik

Deze functies worden niet getest omdat ze geen deel uitmaken van de softwarevereisten:

• user interfaces
• Hardware-interfaces
• Software-interfaces
• Logisch databaseontwerp
• Communicatie-interfaces
• Websitebeveiliging en -prestaties

1.2 Kwaliteitsdoelstelling

De testdoelstellingen zijn om controleren de functionaliteit van de GuruDe website van 99 Bank. Het project moet zich richten op het testen van de bankactiviteitenzoals rekeningbeheer, opnames en saldo-opvraging, om garantie dat al deze operaties werken normaal in een echte zakelijke omgeving.

1.3 rollen en verantwoordelijkheden

Het project moet gebruiken uitbestede leden als testers om projectkosten te besparen.

Nee.	Lid	Taken
1.	Testmanager	Beheert het gehele project, bepaalt de projectrichting en zorgt voor de benodigde middelen.
2.	tester	Identificeert en beschrijft geschikte testtechnieken, -tools en automatiseringsarchitectuur; verifieert de testaanpak; voert tests uit; registreert resultaten; rapporteert defecten. Externe medewerkers.
3.	Ontwikkelaar in testfase	Implementeert testgevallen, testprogramma's, testsuites, enz.
4.	Testbeheerder	Bouwt en onderhoudt de testomgeving en bijbehorende middelen; ondersteunt testers tijdens de uitvoering.
5.	SQA-leden	Neem de kwaliteitsborging in eigen hand en controleer of het testproces aan de gestelde eisen voldoet.

2. Testmethodologie

2.1 Overzicht

De GuruHet 99 Bank-project hanteert een Agile-vriendelijke testmethodologie, waardoor testers zich kunnen aanpassen aan snelle ontwikkelingssprints en tegelijkertijd gestructureerde documentatie kunnen bijhouden.

2.2 Testniveaus

In de GuruVoor het 99 Bank-project moeten drie soorten tests worden uitgevoerd:

• Integratie testen: De afzonderlijke softwaremodules worden gecombineerd en als groep getest.
• Systeem testen: Uitgevoerd op een compleet, geïntegreerd systeem om de naleving van gespecificeerde eisen te evalueren.
• API-testen: Test elke API die door de te testen software beschikbaar wordt gesteld.

2.3 Bugtriage

Er worden twee keer per week bugtriagevergaderingen gehouden om de ernst van defecten, de verantwoordelijke en de beoogde releasedatum voor de oplossing te bepalen.

2.4 Opschortingscriteria en hervattingsvereisten

If 40% testgevallen hebben misluktSchort het testen op totdat het ontwikkelteam alle fouten heeft verholpen.

2.5 Testvolledigheid

• Specificeert de criteria die a aanduiden geslaagd voltooiing van een testfase.
• Loopsnelheid is verplicht bij 100% tenzij er een duidelijke reden voor is.
• Slagingspercentage is 80%Het behalen van het slagingspercentage is verplicht.

2.6 Projecttaken, kostenraming en planning

Taak	Leden	Geschatte inspanning
Maak de testspecificatie	Ontwerper testen	170 manuren
Voer een testuitvoering uit	Tester, Testbeheerder	80 manuren
Test rapport	tester	10 manuren
Testlevering	Testmanager	20 manuren
Totaal	-	280 manuren

Programma: Het team verbindt zich ertoe deze taken binnen de afgesproken testcyclus af te ronden.

3. Testresultaten

Testresultaten voor de GuruHet 99 Bank-project is opgedeeld in drie fasen.

Vóór de testfase:

• Testplan document.
• Test gevallen documenten.
• Testontwerpspecificaties.

Tijdens de testfase:

• Testtoolsimulatoren.
• Testgegevens.
• Test tracgeschiktheidsmatrix, foutenlogboeken en uitvoeringslogboeken.

Na afloop van de testcycli:

• Testresultaten en rapporten.
• Defect Rapport.
• Richtlijnen voor installatie en testprocedures.
• Release-opmerkingen.

4. Behoeften op het gebied van hulpbronnen en milieu

4.1 Hulpmiddelen testen

Nee.	Informatiebronnen	Beschrijving
1.	Server	Een databaseserver die draait MySQL en een webserver waarop Apache draait.
2.	Testtool	Een tool die automatisch testresultaten in een vooraf gedefinieerd formaat kan genereren en de testuitvoering kan automatiseren.
3.	Netwerk	Een gigabit LAN-configuratie en één internetlijn met een minimale snelheid van 5 Mb/s.
4.	Computer	Minimaal 4 werkstations actief Windows 11, met 8 GB RAM en een 3.4 GHz CPU.

4.2 Testomgeving

In dit onderdeel worden de minimale hardware- en softwarevereisten vermeld die nodig zijn om de applicatie te testen. Naast clientspecifieke software is de volgende software vereist:

• Windows 11 en hoger
• Microsoft 365 (of Office 2021 en hoger)
• MS Exchange, enz.

Hoe AI helpt bij testplanning

Bij moderne testplanning wordt steeds vaker AI gebruikt om de benodigde inspanning te verminderen en blinde vlekken aan het licht te brengen. Generatieve assistenten zoals ChatGPT, Claude of Gemini kan een eerste testplan opstellen op basis van een eisenpakket, ontbrekende randgevallen suggereren en produceren tracAutomatische geschiktheidsmatrices. Machine learning-modellen signaleren risicovolle modules op basis van historische defectgegevens, enz.ping De testmanager moet zijn inspanningen richten op datgene wat er het meest toe doet.

AI-ondersteuning vervangt echter geen menselijk oordeel. RevBeoordelaars moeten de reikwijdte, de wettelijke dekking en de zakelijke intentie valideren voordat ze een door AI gegenereerd plan goedkeuren. Beschouw AI-suggesties als een eerste concept, niet als het definitieve document.

Beste werkwijzen voor een effectief testplan

Een goed opgesteld testplan zorgt ervoor dat alle belanghebbenden op één lijn zitten. Pas deze best practices toe bij het opstellen van uw document:

• Houd het beknopt: Gebruik duidelijke taal en opsommingstekens; vermijd jargon dat lezers die geen kwaliteitscontrole uitvoeren, afremt.
• Maak het Reviewable: Deel dit tijdig met ontwikkelaars en businessanalisten om eventuele ontbrekende vereisten op te sporen.
• Kwantificeer de exitcriteria: Definieer de numerieke dekking, het slagingspercentage en de defectdrempels.
• Koppel risico's aan maatregelen om ze te beperken: Koppel elk risico aan een beheersings- of noodstrategie.
• Versiebeheer van het plan: Bewaar het in een documentatieprogramma om track verandert gedurende het project.

Veelgestelde vragen