Planning en urenbegroting............................................................................ 14 8.1 8.2
9
Test organisatiestructuur ....................................................................................12 Testrollen/functies...............................................................................................12 Overleg en Rapportage ......................................................................................12
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.
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:
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
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.
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.
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 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; o 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; o 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.
Hoge faalkans, wordt in cruciale processen 1 en 2 gebruikt Gemiddelde faalkans, slechts beperkt gebruikt in cruciale proces 2 Als deelsys 1 en 2 goed werken, is de kans op integratiefouten laag
Performance -online
B
-batch
C
Beveiliging
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 Functionaliteit A -deelsys 1 B -deelsys 2 C -totaal B Gebr.vriendelijkheid Performance B -online C -batch A Beveiliging … . PRA-RK Toetsen Ontwikkeltest ST GAT PAT ● ●● ●●● S I
Toetsen
Ontwikkeltest ST
GAT
● ●
●● ●
●●
●
●
●● ●● ● I
S
PAT
● ●●
●
● ●● ●●●
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
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.
Eventueel wordt ook aangegeven wat de rol van welke functionaris is bij ieder product, zoals in onderstaand voorbeeld. Producten MasterTestPlan Testevaluatierapport ....
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
6.3 Overleg en Rapportage 6.3.1 Overlegstructuur Opsomming van de overlegvormen waarin de diverse testmedewerkers participeren Soort overleg Testprojectoverleg
Doel Hierin wordt door de testmanager mededeling gedaan over de voortgang van het testproces.
Frequentie 1 x p/2wk
Deelnemers …
6.3.2 Rapportagestructuur Beschrijving van de inhoud en verzendlijsten van de diverse rapportages Soort rapportage voortgangsrapportage
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.
8 Planning en urenbegroting 8.1 Globale tijdsplanning Globale tijdsplanning per testsoort met eventueel de belangrijkste mijlpalen Testsoort Unittest Systeemtest …
Start
Einde
Te besteden tijd
Of Testsoort Start Einde Gebruikersacceptatietest - Testplan - Testspecificatie - Testrapportage … 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
Of Testsoort Gebruikersacceptatietest - Testplan - Testspecificatie - Testrapportage …
Inspanning
SYSQA beschikt over ervaringscijfers om begrotingen op te baseren, de globale begrotingen worden nader uitgewerkt in de detailtestplannen.
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: Geplande startdatum test Werkelijke startdatum test Geplande einddatum test Werkelijke einddatum test Status test Geplande uren Bestede uren Nog te besteden uren Verschil in uren
UT x x x x x x x x x
UIT x x x x x x x x x
ST x x x x x x x x x
FAT x x x x x x x x x
GAT x x x x x x x x x
PAT x x x 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: Aantal bevindingen per ernstcategorie Aantal opgeloste bevindingen per ernstcategorie Aantal openstaande bevindingen per ernstcategorie (momentopname) Aantal hertests Aantal bevindingen per ernstcategorie per week Aantal bevindingen in de testbasis Aantal bevindingen a.g.v. testomgevingen
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.
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
