Sjabloon voor testplan (voorbeelddocumentvoorbeeld)
Thomas Hamilton
Wat is een testplansjabloon?
Sjabloon voor testplan is een gedetailleerd document dat de teststrategie, doelstellingen, planning, schatting en deliverables beschrijft, en de middelen die nodig zijn voor het testen. Testplan helpt ons bij het bepalen van de inspanning die nodig is om de kwaliteit van de te testen applicatie te valideren. Het testplan dient als blauwdruk voor het uitvoeren van softwaretestactiviteiten als een gedefinieerd proces dat minutieus wordt gemonitord en gecontroleerd door de testmanager.
Een maken Testplan is verplicht om het succes van uw softwaretestproject te garanderen. Als u nieuw bent bij Testplanning, raadpleeg dan deze tutorial Hoe u een testplan maakt
Download een voorbeeld van een testplansjabloon
Sjabloon voor testplan
Hieronder vindt u belangrijke onderdelen van een testplan-
- 1 Inleiding
- 1.1 Reikwijdte
- 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 Hulpbronnen en omgevingsbehoeften
- 4.1 Hulpmiddelen testen
- 4.2 Testomgeving
1) Inleiding
Korte introductie van de teststrategieën, het proces, de workflow en de methodologieën die voor het project zijn gebruikt
1.1) Toepassingsgebied
1.1.1) Binnen bereik
Scope definieert de kenmerken, functionele of niet-functionele vereisten van de software die zal zijn getest
1.1.2) Buiten bereik
Out Of Scope definieert de kenmerken, functionele of niet-functionele vereisten van de software die zal niet zijn getest
1.2) Kwaliteitsdoelstelling
Vermeld hier het algemene doel dat u van plan bent te bereiken met uw handmatige tests en automatiseringstests.
Sommige doelstellingen van uw testproject kunnen dat zijn
- Zorg ervoor dat de geteste applicatie voldoet aan functionele en niet-functionele vereisten
- Zorg ervoor dat de AUT voldoet aan de kwaliteitsspecificaties die door de klant zijn gedefinieerd
- Bugs/problemen worden geïdentificeerd en opgelost voordat ze live gaan
1.3) Rollen en verantwoordelijkheden
Gedetailleerde beschrijving van de rollen en verantwoordelijkheden van verschillende teamleden, zoals
- QA-analist
- Testmanager
- Configuratiebeheer
- Ontwikkelaars
- Installatie Team
Onder anderen
2) Testmethodologie
2.1) Overzicht
Vermeld de reden waarom voor het project een bepaalde testmethodologie is toegepast. De voor het project geselecteerde testmethodologie zou kunnen zijn
- WaterFall
- iteratieve
- Behendig
- Extreem programmeren
De gekozen methodologie is afhankelijk van meerdere factoren. U kunt lezen over testmethodologie hier
2.2) Testniveaus
Testniveaus definiëren de soorten testen die moeten worden uitgevoerd op de te testen applicatie (AUT). De testniveaus zijn voornamelijk afhankelijk van de omvang van het project en de tijd- en budgetbeperkingen.
2.3) Bugtriage
Het doel van de triage is om
- Om het type oplossing voor elke bug te definiëren
- Om bugs te prioriteren en een schema vast te stellen voor alle 'nog te repareren bugs'.
2.4) Opschortingscriteria en hervattingsvereisten
Opschortingscriteria definiëren de criteria die moeten worden gebruikt om de testprocedure geheel of gedeeltelijk op te schorten, terwijl de hervattingscriteria bepalen wanneer het testen kan worden hervat nadat deze is opgeschort
2.5) Volledigheid van de test
Hier definieert u de criteria die uw test als voltooid beschouwen.
Een paar criteria om de volledigheid van de test te controleren zijn bijvoorbeeld:
- 100% testdekking
- Alle handmatige en geautomatiseerde testgevallen uitgevoerd
- Alle openstaande bugs zijn opgelost of zullen in de volgende release worden opgelost
3) Testresultaten
Vermeld hier alle testartefacten die tijdens de verschillende fasen van de testlevenscyclus zullen worden opgeleverd.
Hier zijn de eenvoudige resultaten
|
4) Behoeften aan hulpbronnen en milieu
4.1) Testhulpmiddelen
Maak een lijst met hulpmiddelen zoals
- Hulpprogramma voor het bijhouden van vereisten
- Tool voor het volgen van bugs
- automatisering Gereedschap
Vereist om het project te testen
4.2) Testomgeving
Er wordt het minimum vermeld hardware vereisten die zullen worden gebruikt om de Applicatie te testen.
volgend software zijn vereist naast klantspecifieke software.
- Windows 8 en hoger
- Office 2013 en hoger
- MS Exchange, enz.
5) Termen/acroniemen
Vermeld eventuele termen of acroniemen die in het project worden gebruikt
| TERM/ACRONIEM | DEFINITIE |
|---|---|
| API | Application Program Interface |
| AUT | Toepassing wordt getest |
Download het bovenstaande testplan-sjabloonformaat
Voorbeeld van een testplandocument Bankieren Webapplicatie Voorbeeld
1 Inleiding
Het Testplan is ontworpen om de reikwijdte, aanpak, middelen en planning van alle testactiviteiten van het project Guru99 Bank voor te schrijven.
Het plan identificeert de te testen items, de te testen kenmerken, de soorten testen die moeten worden uitgevoerd, het personeel dat verantwoordelijk is voor het testen, de middelen en het schema die nodig zijn om het testen te voltooien, en de risico's die aan het plan zijn verbonden.
1.1 Reikwijdte
1.1.1 Binnen bereik
Alle functies van websiteGuru99 Bank die zijn gedefinieerd in de softwarevereisten bril moeten worden getest
| Module Naam | Toepasselijke rollen | Beschrijving |
|---|---|---|
| Balans onderzoek | Beheerder Klant |
: Een klant kan meerdere bankrekeningen hebben. Hij kan alleen het saldo van zijn rekeningen bekijken Manager: Een manager kan het saldo bekijken van alle klanten die onder zijn toezicht komen |
| Geld transfer | Beheerder Klant |
Klant: Een klant kan geld overmaken van zijn “eigen” account naar een bestemmingsaccount. Manager: Een manager kan geld overboeken van elke bronbank account naar bestemmingsaccount |
| Mini Statement | Beheerder Klant |
Op een mini-afschrift worden de laatste 5 transacties van een rekening weergegeven Klant: Een klant kan alleen een miniverklaring van zijn ‘eigen’ zien rekeningen Manager: Een manager kan het mini-afschrift van elke rekening bekijken |
| Aangepaste verklaring | Beheerder Klant |
Met een op maat gemaakte verklaring kunt u filteren en weergeven transacties op een rekening op basis van datum, transactiewaarde Klant: Een klant kan alleen de verklaring op maat zien zijn “eigen” rekeningen Manager: Een manager kan de aangepaste verklaring van iedereen zien account |
| Wachtwoord wijzigen | Beheerder Klant |
Klant: Een klant kan alleen het wachtwoord van zijn account wijzigen. Manager: Een manager kan alleen het wachtwoord van zijn account wijzigen. Hij kan de wachtwoorden van zijn klanten niet wijzigen |
| Nieuwe klant | Manager | Manager: Een manager kan een nieuwe klant toevoegen. |
| Manager |
Manager: Een manager kan gegevens zoals adres, e-mailadres, telefoon van een klant. |
|
| Nieuw account | Manager |
Momenteel biedt het systeem 2 soorten accounts • Besparen • Huidige Een klant kan meerdere spaarrekeningen hebben (één op zijn naam, andere op een gezamenlijke naam enz.). Hij kan meerdere zichtrekeningen hebben voor verschillende bedrijven hij bezit. Of hij kan meerdere betaal- en spaarrekeningen hebben. Manager: Een manager kan een nieuw account toevoegen aan een bestaand account klant. |
| Bewerk je account | Manager | Manager: Een manager kan accountgegevens voor een bestaand account bewerken |
| Account verwijderen | Manager | Manager: Een manager kan een account voor een klant verwijderen. |
| Klant verwijderen | Manager |
Een klant kan alleen worden verwijderd als hij/zij geen actieve betaal- of spaarrekening heeft Manager: Een manager kan een klant verwijderen. |
| Statiegeld | Manager |
Manager: Een beheerder kan op iedere rekening geld storten. Meestal gedaan wanneer contant geld wordt gestort bij een bankfiliaal. |
| Opname | Manager |
Manager: Een beheerder kan van elke rekening geld opnemen. Meestal gedaan wanneer contant geld wordt opgenomen bij een bankfiliaal. |
1.1.2 Buiten bereik
Deze functies worden niet getest omdat ze niet zijn opgenomen in de specificaties van de softwarevereisten
- user interfaces
- Hardware-interfaces
- Software-interfaces
- Database logisch
- Communicatie-interfaces
- Websitebeveiliging en -prestaties
1.2 Kwaliteitsdoelstelling
De testdoelstellingen zijn om controleren de functionaliteit van website Guru99 Bank, het project zou zich moeten concentreren op het testen van de bankoperatie zoals accountbeheer, opname en saldo... enz. naar garantie al deze operaties kunnen werken normaal in een echte zakelijke omgeving.
1.3 rollen en verantwoordelijkheden
Het project moet gebruiken uitbesteden leden als tester om de projectkosten te besparen.
| Nr. | Lid | Taken |
|---|---|---|
| 1. | Testmanager | Beheer het hele project Projectrichtingen definiëren Zorg voor de juiste hulpmiddelen |
| 2. | test | Identificeren en beschrijven van geschikte testtechnieken/tools/automatiseringsarchitectuur Verifiëren en beoordelen van de testaanpak Voer de tests uit, log resultaten, rapporteer de defecten. Uitbestede leden |
| 3. | Ontwikkelaar in testfase | Implementeren van de testgevallen, testprogramma, testsuite etc. |
| 4. | Testbeheerder | Bouwt en zorgt ervoor dat de testomgeving en assets worden beheerd en onderhouden Ondersteun Tester om de testomgeving te gebruiken voor testuitvoering |
| 5. | SQA-leden | Neem de leiding over de kwaliteitsborging Controleer of het testproces aan de gespecificeerde eisen voldoet |
2 Testmethodologie
2.1 Overzicht
2.2 Testniveaus
In het project Guru99 Bank moeten er 3 soorten tests worden uitgevoerd.
- Integratie Testen (individuele softwaremodules worden gecombineerd en als groep getest)
- Systeem Testen: Uitgevoerd op een compleet, geïntegreerde systeem om te beoordelen of het systeem voldoet aan de gespecificeerde eisen
- API-testen: Test alle API's die zijn gemaakt voor de geteste software
2.3 Bugtriage
2.4 Opschortingscriteria en hervattingsvereisten
Als de teamleden melden dat die er zijn 40% testgevallen mislukt, schort u het testen op totdat het ontwikkelingsteam alle mislukte gevallen heeft opgelost.
2.5 Testvolledigheid
- Specificeert de criteria die a aanduiden geslaagd voltooiing van een testfase
- lopen tarief is verplicht 100% tenzij er een duidelijke reden voor is.
- Passeren tarief is 80% het behalen van het slagingspercentage is verplicht
2.6 Projecttaak en schatting en planning
| Taak | Leden | schatting inspanning |
|---|---|---|
| Maak de testspecificatie | Ontwerper testen | 170 manuur |
| Voer een testuitvoering uit | Tester, Testbeheerder | 80 manuur |
| Test rapport | tester | 10 manuur |
| Testlevering | 20 manuur | |
| Totaal | 280 manuur |
Plan om deze taken te voltooien
3 Testresultaten
Testresultaten worden hieronder verstrekt
Vóór de testfase
- Document testplannen.
- Test gevallen documenten
- Testontwerpspecificaties.
Tijdens het testen
– Testtoolsimulators.
– Testtraceerbaarheidsmatrix – Foutlogboeken en uitvoeringslogboeken.
Nadat de testcycli voorbij zijn
- Testresultaten/rapporten
- Defect Rapport
- Richtlijnen voor installatie-/testprocedures
- Release notes
4 Hulpbronnen en omgevingsbehoeften
4.1 Hulpmiddelen testen
| Nr. | Middelen | Descriptionen |
|---|---|---|
| 1. | Server | Een databaseserver nodig die kan worden geïnstalleerd MySQL server Webserver waarop Apache Server wordt geïnstalleerd |
| 2. | Testtool | Ontwikkel een testtool die het testresultaat automatisch kan genereren in de vooraf gedefinieerde vorm en geautomatiseerde testuitvoering |
| 3. | Netwerk | Zet een LAN Gigabit en 1 internetlijn op met een snelheid van minimaal 5 Mb/s |
| 4. | Computer | Minimaal 4 computerruns Windows 7, Ram 2 GB, CPU 3.4 GHz |
4.2 Testomgeving
Hierin worden de minimale hardware- en softwarevereisten vermeld die zullen worden gebruikt om de Applicatie te testen.
Naast klantspecifieke software zijn de volgende softwareprogramma's vereist.
- Windows 11 en hoger
- Office 2021 en hoger
- MS Exchange, enz.
