1 Sjabloon detailtestplan SYSQA B.V. Almere Datum : Status : > Opgesteld door : 2 Organisatie SYSQA B.V. Pagina 2 van 18 Inhoudsopgave 1 Managements...
Testfasering en activiteiten ...................................................................................8 Testproducten.......................................................................................................9 Vrijgaveadvies en eindrapportage ......................................................................10
1 Managementsamenvatting In dit hoofdstuk worden de kernpunten van het testplan weergegeven: de doelstelling; samenvatting van de teststrategie; de onderkende bedreigingen en risico’s; de planning.
2 Opdrachtformulering 2.1 Inleiding Geef een korte beschrijving van hetgeen in dit hoofdstuk beschreven zal worden. Geef daarbij aan wat de aanleiding is geweest voor het opstarten van het testtraject.
2.2 Opdrachtomschrijving Formele en nauwkeurige omschrijving van de opdracht, bijvoorbeeld: Voor het project is de volgende testopdracht opgesteld: SYSQA BV, hierna te noemen SYSQA, voert in opdracht van het …., hierna te noemen het … de acceptatietest van het uit ….. (Deze formulering wordt alleen gehanteerd als SYSQA resultaat verantwoordelijkheid draagt.)
2.3 Opdrachtgever Beschrijf hier wie de opdrachtgever van de testopdracht is en welke rol hij/zij vervult binnen de opdrachtgever. De opdrachtgever is eveneens de persoon aan wie de opdrachtnemer rapporteert.
2.4 Opdrachtnemer Identificatie van de opdrachtnemer, compleet met naam en functie. Indien een SYSQAmedewerker dit testplan maakt in een detacheringsopdracht is niet SYSQA de opdrachtnemer, maar de medewerker in zijn functie bij de klant.
2.5 Doelstelling Beschrijving van het doel van de test. Hier staat wat met het testtraject beoogd wordt.
2.6 Beschouwingsgebied Beschrijf hier wat gerekend wordt tot de scope van het testtraject. Geef duidelijk de begrenzing aan van wat er getest gaat worden. Geef tevens aan wat niet tot de scope van het testtraject behoort.
2.7 Randvoorwaarden en uitgangspunten Randvoorwaarden zijn voorwaarden die het testproject oplegt aan haar omgeving, uitgangspunten zijn voorwaarden die de omgeving oplegt aan het testproject. Om het testtraject tot een succes te laten verlopen bestaan een aantal randvoorwaarden en uitgangspunten waar aan voldaan dient te worden. Bijvoorbeeld: - Producten (testplan, testvoorbereiding, uitvoering, database en eindrapportage); - Faciliteiten (aparte testruimte, werkplekken, autorisatie, het inrichten van een testomgeving); - Versiebeheer (release procedures); - Beschikbaarheid medewerkers; - Beschikbaarheid ontwikkelteam.
2.8 Wijzigingsprocedure Tijdens projecten wijzigen er regelmatig zaken, soms ook zaken die van invloed zijn op het testtraject. In voorkomende gevallen dient dit tot wijzigingen in het testplan te leiden. Als dat zo is wordt hier beschreven wie deze wijzigingen doorvoert en wie het nieuwe testplan goedkeurt.
3 Testbasis en acceptatiecriteria 3.1 Uitgangsdocumentatie Beschrijven wat de testbasis per testsoort is. Titel <mastertestplan>
Versie 1.2
Datum Dd-mm-yyyy
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 en de verantwoordelijkheden van acceptatie.
4 Teststrategie 4.1 Kwaliteitskenmerken Op basis van de productrisicoanalyse (zie bijlage) worden de deelobjecten en kenmerken van het te testen systeem bepaald. Als de teststrategie niet gedefinieerd is in het mastertestplan wordt deze hier bepaald. Als deze in het mastertestplan niet genoeg gespecificeerd is, wordt deze hier verder gespecificeerd. Als de teststrategie in het mastertestplan compleet is, wordt deze hier overgenomen. Als er gekozen wordt om af te wijken van de zwaarte die is opgenomen in het mastertestplan wordt dit als volgt aangegeven. Voor een verzwaring van een onderdeel, voor een verlichting van een onderdeel. Als er afgeweken wordt moet dit voorzien worden van een duidelijke motivering. Kenmerk
RisicoKlasse Mastertestplan zwaarte van het onderdeel als in Mastertestplan Beperkte dynamische test Gemiddelde dynamische test Zwarte dynamische test Statisch testen Impliciet testen Geen aandacht voor dit kenmerk
4.2 Testtechnieken Beschrijf de gekozen testeenheden en kwaliteitsattributen/kenmerken en deelsystemen. KENMERK Functionaliteit Functionaliteit Functionaliteit
Technieken Te1:DCT Te2:SYN,SEM Te3:selectie uit te1 en te2 Te4:exploratory testing Te5:SYN,SEM Te6:GCT ST Te7: Error guessing
Test, beheerst en verbetert ICT
Organisatie Titel Onderwerp
SYSQA B.V. Sjabloon detailtestplan
Pagina Versie Datum
8 van 18 1.2 08-01-2009
5 Testaanpak 5.1 Testfasering en activiteiten Hieronder staat de SYSQA standaard, indien de klant een eigen standaard heeft dient deze gevolgd te worden. Teneinde deze testopdracht naar voldoening van [opdrachtgever] te kunnen uitvoeren, wordt tewerk gegaan conform het volgende faseringsmodel:
De in het faseringsmodel genoemde fasen en bijbehorende activiteiten worden hierna volgend toegelicht. Fase Beheer Deze fase begint tegelijkertijd met de fase Planning en bepaalt de voortgang en informatievoorziening van het hele proces. In deze fase worden rapportages opgeleverd en wordt sturing gegeven aan het algehele proces. Fase Inrichting en Beheer Infrastructuur In deze fase komt de zorg voor de infrastructuur naar voren. Het afspreken, regelen, beheren van de infrastructuur en alles wat daar mee te maken heeft komen hier naar voren. Fase Planning Het opstellen van het plan van aanpak, het uiteindelijke testplan, wordt op basis van de opdrachtformulering als eerste activiteit na de opdrachtverstrekking uitgevoerd in de fase Testplan. Het testplan, waarin in detail wordt aangegeven hoe deze opdracht wordt uitgevoerd, dient na goedkeuring door [opdrachtgever] als uitgangspunt voor de verder te verrichten werkzaamheden. Een van de mijlpalen producten van deze fase is het testplan voor het project. Het beheer (voortgangsbewaking) loopt gedurende het gehele project door. Fase Voorbereiding De activiteit welke wordt gedaan in de voorbereiding is de detail-intake. Het doel van de detail-intake is het beoordelen van de testbaarheid van de testbasis. Met de testbaarheid wordt hier de volledigheid en consistentie van de documentatie (de testbasis) bedoeld, zover
die benodigd is voor het voorbereiden en uitvoeren van de tests. In hoofdstuk 3 is de testbasis voor [opdrachtgever] nader gedefinieerd. Fase Specificatie In deze fase worden per testeenheid testspecificaties, testscripts en steekproeven gespecificeerd met behulp van in de teststrategie bepaalde testtechnieken. Deze testgevallen worden primair gebaseerd op de functionele specificaties van [naam programmatuur]. In het testdraaiboek worden de testscripts, testbestanden en steekproeven zodanig samengesteld dat de verschillende tests een minimale onderlinge afhankelijkheid hebben en dat het draaiboek helder en eenduidig door acceptatietesters kan worden uitgevoerd. Hergebruik van de ontwikkelde testware bij nieuwe releases van [naam programmatuur] wordt hierdoor gemakkelijk gemaakt. Parallel hieraan wordt de algemene beschrijving van de testinfrastructuur uit het testplan verder in detail uitgewerkt opdat in de volgende fase direct met testen kan worden begonnen. Fase Testuitvoering Na alle voorgaande activiteiten volgt nu de uitvoering van de acceptatietest bestaande uit testgevallen en steekproeven. Deze worden conform het draaiboek uitgevoerd. Naast het uitvoeren van de testcases worden de resultaten van de testen geanalyseerd en de verschillen worden vastgelegd in rapportages en gemeld aan de [naam opdrachtgever]. Besprekingen met de bouwer van [naam programmatuur] over de gevonden resultaten worden uitgevoerd door middel van een projectvergadering. Indien nodig vindt na oplevering van verbeterde programmatuur een hertest plaats. Fase Testafronding Na uitvoering van de voorgenomen tests en nadat het [naam opdrachtgever] in staat is gesteld om tot een vrijgavebeslissing te komen op basis van de (eind)rapportage(s) en advies van de testcoördinator, wordt het testproject afgerond. Met behulp van de opgeleverde testware kunnen, gepaard gaande met kennis van het systeem en kennis overdracht, de relevante tests door derden worden herhaald. De resultaten van de procesevaluatie kunnen worden gebruikt bij het aanscherpen van de in ontwikkeling zijnde [naam opdrachtgever]methodiek. Verder wordt in deze testfase het testproces geëvalueerd om te leren van opgedane ervaringen en leerpunten toe te kunnen passen in een volgende testsituatie.
5.2 Testproducten Het testtraject levert testdocumentatie op die na het project gebruikt wordt voor onderhoudsdoeleinden en derhalve overdraagbaar en onderhoudbaar moet zijn. De volgende documenten kunnen opgeleverd worden: - Testspecificaties; - Testscripts; - Testdraaiboek; - Uitgangsbestanden. Hier. aangegeven te worden aan welke eisen de testproducten dienen te voldoen, zodanig dat de producten onderhoudbaar en overdraagbaar zijn, alsmede wie verantwoordelijk is voor het beheer van de testproducten.
5.3 Vrijgaveadvies en eindrapportage Aan het eind van het testtraject wordt een vrijgaveadvies opgesteld waarin de resultaten van het testtraject worden beschreven. In het vrijgaveadvies is een advies over het al dan niet in productie nemen van de applicatie opgenomen. Dit advies wordt onderbouwd met een overzicht van de openstaande bevindingen en weergave van het testtraject. De risico’s van een eventuele implementatie worden benoemd. Een positief advies voor het accepteren van de programmatuur zal gegeven worden als: 1. De programmatuur na de testronde geen blokkerende bevindingen bevat. 2. De programmatuur na de testronde geen ernstige bevindingen bevat. 3. De programmatuur na de testronde geen kleine bevindingen bevat. De eindrapportage is een acceptatiedocument waarmee opdracht officieel wordt afgesloten en door ondertekening van het document wordt de inhoud en beschreven bevindingen van het testresultaat geaccepteerd en het testteam decharge verleent.
6 Testorganisatie 6.1 Test organisatiestructuur Beschrijving van de testorganisatiestructuur, mits niet opgenomen in MasterTestPlan
6.2 Testrollen/functies & personele invulling Beschrijf van elke rol/functie wie daarvoor is ingepland, voor hoeveel tijd zij zijn ingepland (in uren) voor dit project, enzovoort. Rol / Functie
6.3 Overleg en Rapportage 6.3.1 Overlegstructuren Geef een beschrijving van de overlegvormen die tijdens het testtraject zullen plaatsvinden. 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 Maak een schema waarin de relaties en rapportagelijnen zowel binnen het testteam als daarbuiten worden weergegeven. Soort rapportage voortgangsrapportage ...
7.2 Testtools Beschrijf welke tools gebruikt (gaan) worden tijdens het testtraject. Denk hierbij aan: - Record- en playback-tools; - Registratietool voor bevindingen (denk hierbij aan het gebruiken van het SYSQA bevindingenbeheer tool); - Tool waarmee met de systeemdatum geschoven kan worden; - Elektronische vergelijkingstools.
7.3 Kantoorinrichting Beschrijf de kantoorinrichting en de overige benodigdheden die voor het testtraject nodig zijn.
8.1 Planning Geef per fase of per activiteit aan wanneer deze uitgevoerd wordt en wie die uitvoert, bijvoorbeeld met behulp van onderstaande tabel. Fase Start Einde TC TS1 TS2 Intake - Globale intake - Benoemen testcoördinator Inrichten en beheer infrastructuur - Vaststellen benodigde infrastructuur - Opstellen detailspecificatie infrastructuur Planning - Vaststellen teststrategie - Verzamelen testbasis - Bepalen testorganisatie - Opstellen globale planning - Detailplanning volgende fase - Opstellen testplan - Goedkeuring testplan Voorbereiding - Vaststellen testbaarheid - Bepalen van de testeenheden - Toewijzen van de testtechnieken Specificatie - Defniëren van de testgevallen - Vaststellen initiële gegevensverzameling - Opstellen van de testscripts - Opstellen testdraaiboek - Controle aflevering testobject Uitvoering - Controle op aflevering infrastructuur - Testen van de back up procedures - Installatie en pre test - Opbouw van de uitgangsbestanden - Uitvoeren van de scripts - Bevindingen registratie en communicatie - Correcties door het ontwikkelteam Beheer - Metriekenrapportage - Bijwerken metriekenrapportage - Invullen definitieve metrieken rapportage Afronding - Opstellen vrijgave advies - Conserveren van de testware - Overdracht van ‘known errors’ - Opstellen testverslag - Vrijgave en decharge testteam
Indien het gaat om een relatief klein testtraject volstaat het plannen op basis van fases in plaats van op activiteiten. Bovenstaande uitgangspunten resulteren tot de volgende inspanning: Functionaris Fase Testplan Testvoorbereiding Testuitvoering Testafronding
Functienaam
Functienaam Functienaam
doorlooptijd
… Dagen/Uur … Dagen/Uur … Dagen/Uur … Dagen/Uur
…Dagen\Uur …Dagen\Uur …Dagen\Uur …Dagen\Uur
…Dagen\Uur …Dagen\Uur …Dagen\Uur …Dagen\Uur
…Dagen\Uur …Dagen\Uur …Dagen\Uur …Dagen\Uur
Neem de start- en einddatum over in een Gantt Chart naar onderstaand voorbeeld. wk 1
8.2 Begroting Geef een overzicht van alle kosten van het testtraject. De kosten bestaan uit inspanning maar ook uit kosten voor bijvoorbeeld tools en dergelijke.
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 fase worden de volgende gegevens bijgehouden: Activiteit - - -
startdatum
einddatum
Urenverbruik
Rest uren
9.1.2 Kwaliteitsindicatoren Onderstaande kwaliteitsindicatoren kunnen worden bijgehouden: - Aantal openstaande bevindingen per ernstcategorie op een bepaald moment (dit is een momentopname van de kwaliteit van het product); - Aantal opgeloste bevindingen per ernstcategorie in een bepaalde periode; - Stabiliteit van het systeem (gebaseerd op het aantal opgeloste versus het aantal aangemelde bevindingen per ernstcategorie); - Aantal aangemelde bevindingen per ernstcategorie per dag of per week testen; - Aantal hertests; - Hersteltijd per bevinding; - Testbasisbevindingen per onderdeel van het deelsysteem; - Verlies- en leegloopuren; - Voorspelling aantal nog niet gedane bevindingen.
9.1.3 Metrieken De metrieken kunnen worden samengesteld op het niveau van testeenheid (onderdeel van het deelsysteem, functie, programma). Als voorbeeld is hieronder een set te verzamelen metrieken opgenomen: - Hertests per testeenheid: testeenheid, periode, aantal hertests, aantal uren per hertest; - Bevindingen per testeenheid: testeenheid, periode, aantal en status per ernstcategorie; - Bevindingen en oorzaak per soort functie: testeenheid, periode, aantal per soort functie; - Aantal per soort fout: testeenheid, periode, aantal per soort fout; - Hersteltijd bevindingen: testeenheid, bevinding, ernstcategorie, hoeveelste test, tijdstip melding, tijdstip herstel; bevindingen per functiepunt; - Testeenheid, functiepunten, aantal bevindingen per ernstcategorie.
9.2 Bevindingenbeheer De resultaten van het testtraject worden vastgelegd in de testrapportages. Afwijkingen in de respons van het systeem ten opzichte van de verwachting wordt vastgelegd in een bevindingenrapport. In het bevindingenrapport wordt onder meer de urgentie vastgelegd. Om deze urgentie per bevinding te kunnen prioriteren is een verdeling gemaakt namelijk: 1. Testblokkerende bevinding = testwerkzaamheden kunnen niet worden gecontinueerd, bijvoorbeeld de database functioneert niet naar behoren 2. Ernstige bevinding = testwerkzaamheden kunnen worden gecontinueerd het systeem kan met deze bevinding niet in productie 3. Kleine bevinding = het systeem werkt niet conform de testbasis, maar met een beperkt aantal van deze bevindingen kan in productie worden gegaan. Per bevinding wordt een duidelijke omschrijving van de afwijking gegeven. Hierin wordt gemeld in welke situatie de fout optreedt, wat de fout exact is en wat de verwachte respons van het systeem is. Bevindingen kunnen van allerlei aard zijn en kunnen betrekking hebben op: 1. de testbasis; 2. het testobject (verschillen tussen specificaties en testresultaten); 3. de testomgeving (netwerkstoringen, computerstoringen, verkeerde versie software staat klaar, databestanden kloppen niet ); 4. de testspecificaties zelf (de eigen testgevallen zijn niet correct). De bevindingen worden naar aanleiding van hun urgentie regelmatig gerapporteerd aan de projectleider van het [naam] project.
9.3 Beheer infrastructuur Beschrijf hier welke functionaris welk onderdeel van de infrastructuur beheerd.
9.4 Testproductbeheer 9.4.1 Reviews Ten behoeve van de bewaking van de kwaliteit van testproducten kunnen deze door middel van (collegiale) reviews beoordeeld worden. Geef in deze paragraaf aan welke testproducten door wie wordt beoordeeld. Testproduct
Criteria
Reviewtechniek
Reviewer(s)
9.4.2 Testproducten Aangeven wie er verantwoordelijk is voor het beheer van de testproducten en waar de conservering van de testware plaats vindt.
10 Bedreigingen, 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
Bijlage: Productrisicoanalyse In deze bijlage komen de resultaten van de productrisicoanalyse, overgenomen uit het Mastertestplan.
Schade bij falen
Kans op Falen Hoog A B C
Hoog Midden Laag
Midden B B C
Laag B C C
Risicoclassificatie
Kenmerk Functionaliteit
Risicoklasse Argumentatie
-deelsys 1
A
-deelsys 2
B
-totaal
C
Gebr.vriendelijkheid
B
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
