Mastertestplan <<Naam project>> <<Organisatie>>

Mastertestplan <<Naam project>> <<Organisatie>> SYSQA B.V. Almere Datum : <<datum>> Status : <<status>> Opgesteld door : <<naam>>

Organisatie <<Organisatienaam>> Pagina 2 van 17 Inhoudsopgave 1 Management Samenvatting... 4 2 Inleiding... 5 2.1 Algemeen...5 2.2 Opdracht...5 2.3 Opdrachtgever...5 2.4 Opdrachtnemer...5 2.5 Doel van het mastertestplan...5 2.6 Beschouwingsgebied...5 2.7 Randvoorwaarden en uitgangspunten...6 2.8 Decharge...6 2.9 Wijzigingsprocedure...6 3 Testbasis en acceptatiecriteria... 7 3.1 Uitgangsdocumentatie...7 3.2 Acceptatiecriteria...7 3.3 Acceptatieproces...7 4 Testproces... 8 4.1 Testsoorten...8 4.2 Product Risico Analyse...8 4.3 Teststrategie...9 5 Testaanpak per testsoort... 10 5.1 <Testsoort 1>...10 5.2 <Testsoort 2>...10 5.3 Testproducten...10 6 Testorganisatie... 12 6.1 Test organisatiestructuur...12 6.2 Testrollen/functies...12 6.3 Overleg en Rapportage...12 7 Infrastructuur... 13 7.1 Testinfrastructuur...13 7.2 Testtools...13 7.3 Faciliteiten...13 8 Planning en urenbegroting... 14 8.1 Globale tijdsplanning...14 8.2 Globale begroting...14 9 Beheer... 15 9.1 Testprocesbeheer...15 9.2 Bevindingenbeheer...15 9.3 Beheer infrastructuur...16 9.4 Testproductbeheer...16 10 Risico s en maatregelen... 17

Organisatie <<Organisatienaam>> Pagina 3 van 17 Versiebeheer Versie Datum Opmerkingen Auteur Verzendlijst Versie Ontvanger

Organisatie <<Organisatienaam>> Pagina 4 van 17 1 Management Samenvatting In dit hoofdstuk worden de kernpunten van het mastertestplan weergegeven: - de doelstelling; - samenvatting van de teststrategie; - de onderkende bedreigingen en risico s; - de planning.

Organisatie <<Organisatienaam>> Pagina 5 van 17 2 Inleiding 2.1 Algemeen Korte beschrijving van het project en de plaats van het mastertestplan 2.2 Opdracht Opdrachtomschrijving voor de testmanager. Dit is niet de opdracht voor het schrijven van het mastertestplan maar voor het uitvoeren van het testtraject 2.3 Opdrachtgever Identificatie van de opdrachtgever, compleet met naam en functie 2.4 Opdrachtnemer Identificatie van de opdrachtnemer, compleet met naam en functie. Indien een SYSQAmedewerker dit MTP maakt in een detacheringsopdracht is niet SYSQA de opdrachtnemer, maar de medewerker in zijn functie bij de klant. 2.5 Doel van het mastertestplan Korte beschrijving van het doel en de plaats van het mastertestplan in het project. Onderstaande visualisatie kan hierbij helpen: Mastertestplan Programmatestplan Systeemtestplan Acceptatietestplan 2.6 Beschouwingsgebied Aangeven wat wel en wat niet bij de opdracht hoort. Als bepaalde tests niet bij het testtraject horen dient dit aangegeven te worden. Ook dient aangegeven te worden of reviews en inspecties tot het testproces horen. Binnen gebied: Systemen, Conversies, Administratieve organisatie procedures, interfaces met aangrenzende systemen Buiten gebied: Systeemwijzigingen die niet in het project worden meegenomen, Testactiviteiten die door andere partijen worden uitgevoerd, Reorganisaties, Mogelijke toekomstige projecten

Organisatie <<Organisatienaam>> Pagina 6 van 17 2.7 Randvoorwaarden en uitgangspunten 2.7.1 Opsomming van de randvoorwaarden die gelden. Onder randvoorwaarden worden die voorwaarden beschreven die extern aan het testproces worden opgelegd. Enkele voorbeelden zijn: Een vastgelegde einddatum; Het plan van aanpak van het project; Eisen aan de testomgeving; Eisen aan de afscherming testomgevingen in verband met beveiliging 2.7.2 Opsomming van de uitgangspunten die gelden. Uitgangspunten worden door het testteam zelf bepaald en opgelegd aan derden. Enkele voorbeelden zijn: De bouwtest is uitgevoerd voordat de functionele test begint; De software wordt werkend opgeleverd en geïnstalleerd door het bouwteam; De testomgeving en de benodigde infrastructuur zijn conform planning beschikbaar; De installatie van nieuwe of herstelde programmatuur in de testomgeving vindt alleen plaats na toestemming van het testteam De projectleider houdt het testteam op de hoogte van de planning van doorgevoerde wijzigingen in de testbasis; De basis voor de systeemtest en acceptatietesten is een bevroren vorm van de testbasis die conform de planning aan de leden van het testteam ter beschikking wordt gesteld De basis voor de systeemtest en acceptatietesten is een bevroren vorm van de programmatuur die conform planning aan de leden van het testteam ter beschikking wordt gesteld; Over (geplande) wijzigingen in de systeemsoftware dient het testteam structureel te worden ingelicht. 2.8 Decharge Beschrijf op welke gronden het testtraject formeel wordt beëindigd en het testteam wordt ontbonden. In het Mastertestplan moet worden gekwantificeerd waaraan de uit te voeren testsoorten moeten voldoen om over te kunnen gaan naar de volgende fase (testsoort) van het testtraject, de zogeheten entry- en exitcriteria. 2.9 Wijzigingsprocedure Tijdens IT-projecten wijzigen er regelmatig zaken, soms ook zaken die van invloed zijn op het testtraject. In voorkomende gevallen dient dit tot wijzigingen in het mastertestplan te leiden. Als dat zo is wordt hier beschreven wie deze wijzigingen doorvoert en wie het nieuwe mastertestplan goedkeurt.

Organisatie <<Organisatienaam>> Pagina 7 van 17 3 Testbasis en acceptatiecriteria 3.1 Uitgangsdocumentatie Beschrijven wat de testbasis per testsoort is. Titel Versie Datum Auteur Definitief J/N 3.2 Acceptatiecriteria Een beschrijving van de acceptatiecriteria, een verwijzing naar een ander document met de acceptatiecriteria of een beschrijving van het proces van het inventariseren en meetbaar maken van de acceptatiecriteria 3.3 Acceptatieproces Beschrijving van de wijze, personen en verantwoordelijkheden van acceptatie; wie zijn er waarvoor, op welk moment verantwoordelijk.

Organisatie <<Organisatienaam>> Pagina 8 van 17 4 Testproces 4.1 Testsoorten In deze paragraaf worden de testsoorten gedefinieerd. Iedere organisatie kent haar eigen definitie van testsoorten, TMap Next onderkent de volgende testsoorten: Ontwikkeltest: een test waarin de ontwikkelende partij aantoont dat het product voldoet aan met name de technische specificaties. Deze is onder te verdelen in: o Unittest: een test welke moet aantonen dat een unit aan de in de technische specificaties gestelde eisen voldoet; o Unitintegratietest: een test welke moet aantonen dat een logische groep units aan de in de technische specificaties gestelde eisen voldoet; Systeemtest: een test waarin de leverende partij aantoont dat het product voldoet aan met name de functionele- en niet-functionele specificaties en aan het technisch ontwerp; Acceptatietest: een test waarin de accepterende partij vaststelt dat het product voldoet aan met name de verwachtingen. De acceptatietest wordt soms onderverdeeld in de volgende deeltestsoorten: o o o Functionele acceptatietest: een test welke door de toekomstige gebruikers in een zoveel mogelijk als het ware productieomgeving uitgevoerd wordt, die moet aantonen dat het ontwikkelde systeem aan de functionele eisen voldoet; Gebruikersacceptatietest; een test welke door de toekomstige gebruikers in een zoveel mogelijk als het ware productieomgeving uitgevoerd wordt, die moet aantonen dat het ontwikkelde systeem aan de weinsen/eisen van de gebruiker voldoet; Productieacceptatietest: een test welke door de toekomstige beheerders in een zoveel mogelijk als het ware productieomgeving uitgevoerd wordt, die moet aantonen dat het ontwikkelde systeem aan de van uit beheer gestelde eisen voldoet. Soms wordt ook de ketentest onderscheiden: een test gericht op de integratie van systemen en onderdelen en op koppelingen naar externe organisaties. Deze testsoort kan door zowel ontwikkelorganisatie als gebruikersorganisatie uitgevoerd worden. Deze testsoort wordt in TMap Next ook wel aangeduid als systeem integratietest. 4.2 Product Risico Analyse Definitie productrisico: een productrisico is de kans dat het product faalt in relatie tot de verwachte schade wanneer dit optreedt. Faalkans * Schade, waarbij Faalkans = Foutkans * Frequentie van gebruik. In dit stuk komen de resultaten van en degenen die meegewerkt hebben aan de productrisico analyse. Deze kan alleen zinvol uitgevoerd worden als het beschouwingsgebied en de business requirements duidelijk zijn. Ontwerpen en acceptatiecriteria moeten al invulling hebben gekregen. Hier kan ook de verzameling PRA s van de individuele testsoorten komen. Kans op Falen Hoog Midden Laag Schade bij falen Hoog A B B Midden B B C Laag C C C Risicoclassificatie

Organisatie <<Organisatienaam>> Pagina 9 van 17 Kenmerk Risicoklasse Argumentatie Functionaliteit -deelsys 1 A Hoge faalkans, wordt in cruciale processen 1 en 2 gebruikt -deelsys 2 B Gemiddelde faalkans, slechts beperkt gebruikt in cruciale proces 2 -totaal C Als deelsys 1 en 2 goed werken, is de kans op integratiefouten laag Gebr.vriendelijkheid B Performance -online -batch Beveiliging B C A 4.3 Teststrategie Aan de hand van kwaliteitsattributen, kenmerken en deelobjecten uit de PRA wordt de teststrategie gedefinieerd. In matrixvorm wordt aangegeven welke testsoort zich op welk kwaliteitsattribuut zich richt en met welke zwaarte. Kenmerk PRA-RK Toetsen Ontwikkeltest ST GAT PAT Functionaliteit -deelsys 1 A -deelsys 2 B -totaal C Gebr.vriendelijkheid B I Performance -online B -batch C Beveiliging A S. PRA-RK Toetsen Ontwikkeltest ST GAT PAT S I <leeg> ProductRisicoAnalyse Risicoklasse (A hoog, B gemiddeld, C laag) Toetsing/review van de verschillende tussenproducten Unittest + Unitintegratietest Systeemtest Gebruikersacceptatietest Productacceptatietest Beperkte dynamische test Gemiddelde dynamische test Zware dynamische test Statisch testen Impliciet testen geen aandacht in deze testsoort voor dit kenmerk

Organisatie <<Organisatienaam>> Pagina 10 van 17 Indien relevant wordt aangegeven welke kwaliteitsattributen niet zijn meegenomen en waarom niet. 5 Testaanpak per testsoort Korte beschrijving van de fases, activiteiten en eventuele entry- en exitcriteria per testsoort. Hier kunnen ook de verantwoordelijken per testsoort worden opgenomen. 5.1 <Testsoort 1> Planning: Voorbereiding: Specificatie: Uitvoering: Afronding: Beheer: Inrichting en beheer infrastructuur: 5.2 <Testsoort 2> Planning: Voorbereiding: Specificatie: Uitvoering: Afronding: Beheer: Inrichting en beheer infrastructuur: 5.3 Testproducten Opsomming van de producten die worden gemaakt zoals detailtestplannen, testspecificaties, testscripts, databasevullingen et cetera. Ook aangeven waar welk product uit bestaat.

Organisatie <<Organisatienaam>> Pagina 11 van 17 Product Inhoud Gemaakt door Opgeleverd aan Eventueel wordt ook aangegeven wat de rol van welke functionaris is bij ieder product, zoals in onderstaand voorbeeld. Producten OG ON PM PL GO FO TO BE QA PB DB MasterTestPlan Testevaluatierapport... Legenda: R Review OG Opdrachtgever G Goedkeuring ON Opdrachtnemer K Kennisgeving PM Projectmanager PL Projectleider GO Gebruikersorganisatie FO Functionele ondersteuning TO Technische ondersteuning BE Beheer & Exploitatie QA QA-groep PB Project Bureau DB Database administrator

Organisatie <<Organisatienaam>> Pagina 12 van 17 6 Testorganisatie 6.1 Test organisatiestructuur Beschrijving van de testorganisatiestructuur 6.2 Testrollen/functies Uitwerking van de testorganisatiestructuur met een beschrijving van de taken per rol/functie. In TMap Next wordt alleen gesproken over rollen, er kan een distinctie gemaakt worden tussen de functie in een organisatie en de rol in testverband. Rol /Functie Taken Bevoegdheden <Rol /Functie> <Taken> <Bevoegdheden> <Rol /Functie> <Taken> <Bevoegdheden> 6.3 Overleg en Rapportage 6.3.1 Overlegstructuur Opsomming van de overlegvormen waarin de diverse testmedewerkers participeren 6.3.2 Rapportagestructuur Beschrijving van de inhoud en verzendlijsten van de diverse rapportages Soort overleg Doel Frequentie Deelnemers Testprojectoverleg Hierin wordt door de testmanager mededeling gedaan over de voortgang van het testproces. 1 x p/2wk Soort rapportage Door Aan Vorm Frequentie voortgangsrapportage testmanager opdrachtgever schriftelijk 1 x p/wk.

Organisatie <<Organisatienaam>> Pagina 13 van 17 7 Infrastructuur 7.1 Testinfrastructuur Opsomming van de benodigde testomgevingen en de eisen daaraan 7.2 Testtools Opsomming en beschrijving van de benodigde testtools, alsmede aangeven wie verantwoordelijk is voor het beheer van die tools 7.3 Faciliteiten Opsomming van de benodigde faciliteiten om te testen. Eventueel kunnen hier gemaakte afspraken vastgelegd worden voor infrastructuur. Wie er verantwoordelijk is op welk moment.

Organisatie <<Organisatienaam>> Pagina 14 van 17 8 Planning en urenbegroting 8.1 Globale tijdsplanning Globale tijdsplanning per testsoort met eventueel de belangrijkste mijlpalen Testsoort Start Einde Te besteden tijd Unittest <datum> <datum> <uren> Systeemtest <datum> <datum> <uren> Of Testsoort Start Einde Gebruikersacceptatietest - Testplan <datum> - Testspecificatie <datum> - Testrapportage <datum> <datum> <datum> <datum> De uit te voeren activiteiten (op faseniveau per testsoort), eventuele relaties en afhankelijkheden van andere activiteiten, benodigde en beschikbare resources en doorlooptijd en de op te leveren producten kunnen hier opgenomen worden. 8.2 Globale begroting Globale begroting per testsoort, in uren of in Euro s Testsoort Systeemtest Inspanning <uren> Of Testsoort Gebruikersacceptatietest - Testplan - Testspecificatie - Testrapportage Inspanning <uren> <uren> <uren> SYSQA beschikt over ervaringscijfers om begrotingen op te baseren, de globale begrotingen worden nader uitgewerkt in de detailtestplannen.

Organisatie <<Organisatienaam>> Pagina 15 van 17 9 Beheer 9.1 Testprocesbeheer Testprocesbeheer richt zich op het beheersen van het testproces en de kwaliteit van het testobject. 9.1.1 Voortgang en de besteding van budget en tijd: Per testsoort worden de volgende gegevens bijgehouden: UT UIT ST FAT GAT PAT Geplande startdatum test x x x x x x Werkelijke startdatum test x x x x x x Geplande einddatum test x x x x x x Werkelijke einddatum test x x x x x x Status test x x x x x x Geplande uren x x x x x x Bestede uren x x x x x x Nog te besteden uren x x x x x x Verschil in uren x x x x x x De gegevens worden per testsoort en per testteam bijgehouden waarna ze worden gecumuleerd door de testmanagers. Zie ook paragraaf Rapportage 9.1.2 Metrieken De volgende gegevens worden bijgehouden per testsoort: UT UIT ST FAT GAT PAT Aantal bevindingen per ernstcategorie x x x x x x Aantal opgeloste bevindingen per ernstcategorie x x x x x x Aantal openstaande bevindingen per x x x x x x ernstcategorie (momentopname) Aantal hertests x x x x x x Aantal bevindingen per ernstcategorie per week x x x x x x Aantal bevindingen in de testbasis x x x x x x Aantal bevindingen a.g.v. testomgevingen x x x x x x 9.2 Bevindingenbeheer Per testsoort wordt in hoofdlijnen beschreven hoe bevindingen worden vastgelegd, geprioriteerd en gerapporteerd. Over het algemeen worden minimaal de volgende statussen onderkent: Open: Alle bevindingen waarvoor geldt dat deze nog niet zijn opgelost, niet zijn uitgesteld en nog niet zijn vervallen. Opgelost: alle bevindingen waarvoor geldt dat ze zijn opgelost (omdat een wijziging in de testbasis, testobject of testware is gemaakt) en succesvol een hertest hebben ondergaan (de oplossing is goedgekeurd). Vervallen: Alle bevindingen waarvoor geldt dat ze onterecht zijn gedaan, bijvoorbeeld door een testersfout. Alle bevindingen die wel terecht zijn gedaan, maar geringe impact hebben, geen vervolg kennen en worden geaccepteerd. Alle bevindingen die

Organisatie <<Organisatienaam>> Pagina 16 van 17 wel gevolg hebben, zijn hersteld, maar niet meer hertest hoeven te worden. Vervallen uitsluitend na akkoord van de opdrachtgever. Uitgesteld: Alle bevindingen waarvoor geldt dat ze niet binnen het project worden opgelost (waaronder known-errors). Voorbeeld: een lichte bevinding, waarbij oplossen veel impact op een applicatie kan hebben. Later oplossen geeft meer mogelijkheid tot regressietesten. Mogelijke andere statussen zijn: Ingediend; Geen bevinding; Corrigeren; Analyseren; Correctie gereed; Analyse gereed; Hertesten; Hertest akkoord; Hertest akkoord maar nok; Bekende fout; Wens; Gesloten. Het is aanbevelingswaardig om het aantal statussen zo veel mogelijk te beperken en generiek vast te stellen. Ook wordt aangegeven welke categorieën onderkent worden, een mogelijke indeling is: Testblokkerend: Er is geen mogelijkheid om de test voort te zetten. Hierdoor kan het testobject niet of onvoldoende worden beoordeeld, en is er dus sprake van een productrisico. Productieblokkerend: De opgeleverde functionaliteit kan niet voldoende succesvol worden geïmplementeerd, gebruikt of beheerd in productie. Aanpassing van de opgeleverde functionaliteit is noodzakelijk. Ernstig: De opgeleverde functionaliteit kan slechts door aanvullende maatregelen in enige mate succesvol worden geïmplementeerd, gebruikt en beheerd. Aanpassing van de opgeleverde functionaliteit is wenselijk en op termijn noodzakelijk. Niet ernstig: Er wordt een bevinding gedaan maar deze heeft geen grote invloed op de bruikbaarheid van de opgeleverde functionaliteit in productie, en geen grote invloed op het verloop van de test. In de detailtestplannen worden de bevindingenprocedures nader uitgewerkt. SYSQA heeft een bevindingenbeheertool ontwikkeld dat SYSQA-medewerkers vrij mogen gebruiken 9.3 Beheer infrastructuur Naast algemene beheertaken wordt hier neergezet hoe het beheer geregeld is van gedeelde omgevingen en/of testtools tussen testsoorten. Afstemming tussen afzonderlijke infrastructuurplanningen, verantwoordelijkheden etc. 9.4 Testproductbeheer Aangeven wie er verantwoordelijk is voor het beheer van welke testproducten. Ook de eventuele conservering van testproducten wordt hier gespecificeerd.

Organisatie <<Organisatienaam>> Pagina 17 van 17 10 Risico s en maatregelen Opsomming van de risico s die van toepassing zijn op het testproject en de maatregelen die genomen kunnen worden om deze risico s te verminderen. Risico Maatregel Verantwoordelijke