Testplan

Een testplan is een plan om een testobject zoals een machine, een procedure, software of een combinatie daarvan te testen.

Een testplan wordt normaal gesproken gemaakt door de testmanager, die het plan daarna ook gaat uitvoeren. Doel van het testen is om informatie te verschaffen over het te testen object. Het doel van het testplan is om aan te geven hoe deze informatie verkregen wordt en welke delen van het testobject daarbij meer of minder aandacht krijgen. Daarnaast moet het testen een inschatting geven van de kwaliteit van het product en de risico's die men loopt als het testobject gebruikt gaat worden. Een (master of hoofd) testplan is een uitwerking van een teststrategie.

Onderdelen

Afhankelijk van het te testen product, de testbasis en de verantwoordelijkheid van de organisatie die het testplan laat opstellen, zal een testplan de volgende onderdelen bevatten:

• Review van de ontwerpdocumenten - Deze wordt tijdens de ontwikkeling uitgevoerd. Bekeken wordt of de documentatie aan de (vorm)eisen voldoet.
• Productietest - Hierbij wordt gekeken of het geheel acceptabel is voor de beheerders. Of het voldoet aan de eisen die zij stellen, of er voldoende documentatie aanwezig is, etc. Soms wordt ook een stresstest uitgevoerd om te zien of het product ook de aantallen aankan die tijdens productie kunnen voorkomen.
• Unittest - Wordt uitgevoerd door de programmeurs zelf waarbij zij hun specifieke onderdeel testen, los van het geheel.
• Integratietest - Wordt aan het einde van de ontwikkeling uitgevoerd, vaak door speciale testers waarbij het geheel geïntegreerd getest wordt.
• Acceptatietest - Wordt uitgevoerd door (vertegenwoordigers van) de gebruikers als het product wordt geïmplementeerd, geïnstalleerd of afgeleverd. Wordt ook wel UAT of User Acceptance Test (gebruikersacceptatietest) genoemd.
• Regressietest - Wordt uitgevoerd op een bestaand en werkend product om te controleren dat de functionaliteit ervan niet verloren is gegaan als de omgevingsfactoren veranderen (bv. het upgraden van een platform waarop een bestaand programma draait).

Een uitgebreid systeem kan een master-/hoofdtestplan hebben, waarin de belangrijkste requirements aan de orde komen, plus gedetailleerde testplannen voor onderdelen van het geheel.

Het uiterlijk van testplannen is net zo verschillend als de producten die getest worden of de organisaties waar gewerkt wordt. Drie belangrijke onderdelen zullen echter in elk testplan aan de orde komen en die zijn: testdekking, testmethoden en testverantwoordelijkheden. Deze zullen ook al in de teststrategie aan de orde komen.

Testdekking

De testdekking geeft aan wanneer welke requirements getest zullen worden en welke niet. De dekking wordt afgeleid van de testbasis. In het ideale geval worden alle specificaties getest, tijdens de verschillende ontwikkelingsfasen. Maar testen kost geld (en tijd) zodat er bij het ontwikkelen van een testplan voornamelijk gekeken wordt naar de risico's en de beheersing daarvan. Het testen moet een risico-inschatting geven, vandaar dat bij het testontwerp de nadruk zal liggen op de belangrijkste requirements. Het testontwerp heeft ook gevolgen voor het functioneel en technisch ontwerp, omdat testen mogelijk moet zijn en daarvoor het ontwerp soms moet worden aangepast. Het ontwerp moet soms duidelijker, testbaarder geformuleerd worden.

Testvorm

In de testvorm wordt aangegeven hoe de testdekking wordt uitgevoerd. Sommige testvormen zijn wettelijk vereist, of in besluiten of contracten vastgelegd, andere zullen vrij gekozen kunnen worden. In de testvorm wordt soms ook al de testomgeving en de testtools vastgelegd en de testnormen. Testen om hardware te testen kunnen verschillen van eenvoudige visuele inspecties tot uitgebreide testprocedures die apart beschreven worden.

Verantwoordelijkheden

Aangegeven moet worden wie, wanneer, wat test. Hierdoor kunnen de verantwoordelijken zich goed voorbereiden, om de testomgeving in orde te brengen, de testers vrij te maken en overige noodzakelijke maatregelen te nemen. Hierbij wordt ook precies aangegeven wie welke testproducten oplevert ("deliverables"). Een onderdeel van een goed testplan is een verslag van alles wat getest is (en wat niet).

IEEE 829-structuur van het testplan

IEEE 829|IEEE 829-2008, ook bekend als de "829 Standard for Software Test Documentation", is een IEEE-standaard waarin vorm en inhoud van een aantal documenten wordt aangegeven die bij het testen van software gebruikt moeten worden.

• Naam van het testplan en versienummer.
• Inleiding.
• Onderdelen die getest worden.
• Onderdelen die niet getest worden.
• Aanpak.
• Testproducten.
• Testcases.
• Exacte criteria waaraan voldaan moet worden en waarmee bepaald kan worden of de test geslaagd is.
• Testonderdelen.
• Randvoorwaarden.
• Verantwoordelijkheden.
• Personeel en opleidingsbehoefte.
• Planning.
• Risico's.
• Goedkeuringen.

Er zijn ook andere IEEE-documenten waarin staat wat in een testplan zou moeten staan zoals:

• 829-1983 IEEE Standard for Software Test Documentation (superseded by 829-1998)
• 829-1998 IEEE Standard for Software Test Documentation (superseded by 829-2008)
• 1008-1987 IEEE Standard for Software Unit Testing
• 1012-2004 IEEE Standard for Software Verification & Validation Plans
• 1059-1993 IEEE Guide for Software Verification & Validation Plans (withdrawn)

Zie ook

• Testen (software)
• Testcase
• Testscript
• TMap

Externe links

• Public domain RUP test plan template at Sourceforge (templates are currently inaccessible but sample documents can be seen here: DBV Samples)
• Testplannen en testcases