EISEN AAN TESTPLANNEN

EISEN AAN TESTPLANNEN <afdeling/project> Auteur : <naam/bedrijf> Datum : <datum> Versie :.. Status :.. Datum overdracht : <datum> Overgedragen aan : <verantwoordelijke persoon>

Inhoudsopgave 1 Inleiding... 2 1.1 DOEL VAN DIT DOCUMENT... 2 1.2 REFERENTIES... 2 2 Eisen... 3 2.1 OPDRACHTFORMULERING... 3 2.2 TESTSTRATEGIE... 4 2.3 TESTAANPAK... 5 2.4 TESTBASIS... 5 2.5 TESTBEOORDELING... 6 2.6 RISICO S... 6 2.7 ORGANISATIE... 7 2.8 INFRASTRUCTUUR... 7 2.9 PLANNING... 8 3 Checklist... 9 4 Bijlage; template testplan... 11 Copyright 1999... 1

1 Inleiding 1.1 Doel van dit document Dit document verschaft voor de lezer ervan een aantal specifieke eisen ten aanzien van de inhoud van testplannen. Zodoende kunnen nieuwe testplannen op een optimale wijze worden opgesteld en kunnen bestaande testplannen op kwaliteit worden beoordeeld. De in dit document genoemde eisen zijn enerzijds afkomstig uit de in 1.2 Referenties genoemde literatuur en anderzijds tot stand gekomen met behulp van ervaringsgegevens van.... Een checklist is toegevoegd in hoofdstuk 3. In de bijlage staat een template voor een testplan. 1.2 Referenties [1] Kwaliteitszorg door acceptatietesten N.P.M.Mors Leiderdorp 1996, ongewijzigde herdruk [2] Testen volgens TMap Pol / Teunissen / Van Veenendaal ös Hertogenbosch 1995, derde druk 1998 Copyright 1999... 2

2 Eisen Bij de nu volgende eisen wordt per eis een verwijzing opgenomen naar de gebruikte literatuur. Waar geen verwijzing is opgenomen, is de eis tot stand gekomen met behulp van ervaringsgegevens van medewerkers van... 2.1 Opdrachtformulering Een goed testplan bevat te allen tijde een eenduidige opdrachtformulering. Binnen deze opdrachtformulering dienen ten minste de volgende items beschreven te zijn: Opdrachtgever voor opstellen van het testplan en uitvoering van de test [1] + [2]; als er meerdere opdrachtgevers zijn, leg eenduidig vast wie welke opdracht geeft, en voor welke zaken je aan wie moet rapporteren. Opdrachtnemer voor opstellen van het testplan en uitvoering van de test [1] + [2]. Doelstelling van het uit te voeren testproces [1] + [2]; bijv. een certificaat behalen (dit komt bijv. bij millennium-projecten voor), de op te leveren produkten tijdens en na afronding van het testproject, de te testen kwaliteitsaspecten voor bepaalde systeemdelen en een onderbouwd advies hieromtrent. De doelstelling moet dermate meetbaar zijn dat tijdens en aan het einde van het testtraject ondubbelzinnig aangegeven kan worden in hoeverre aan de doelstellingen wordt/is voldaan. In de doelstelling komen tevens de acceptatiecriteria tot uitdrukking. Denk hierbij aan meetbare acceptatiecriteria zoals: er mogen geen storingen en abends voorkomen in de laatste hertest, en/of er mogen maximaal 10 bevindingen zijn die betrekking hebben op cosmetische zaken in het systeem. De acceptatiecriteria kan je verdelen naar systeemdelen of functies. Voor bepaalde vitale functies kunnen strengere normen gelden dan voor minder belangrijke functies in een systeem. Opdrachtomschrijving; hierin staat wat je moet doen, wat de opdrachtgever van je verwacht en een omschrijving wanneer je het goed doet. Randvoorwaarden en uitgangspunten met betrekking tot de start en uitvoering van de test [1]; voorbeelden zijn: de positie van het testplan t.o.v. een aanwezig mastertestplan, kwaliteitssysteem of richtlijnen testen; te testen systeemdatums (bij millenniumtrajecten); beschikbare testomgevingen die aan bepaalde eisen voldoen; een aantoonbaar nivo van de voorliggende systeemtest indien er sprake is van een acceptatietest; beschikbaarheid van testcapaciteit op bepaalde momenten in het testtraject; indien specificaties gedurende het testtraject wijzigen moeten daar afspraken over worden gemaakt, bijv. over de besluitvorming welke wel en niet meegomen worden in de test, hoe prioriteiten gesteld worden, hoe specificaties en versiebeheer samengaan e.d.; deadlines, eventueel gesteld aan start (programmatuur klaar, bevroren specificaties, testomgeving klaar) en afronding van het gehele testtraject, bijv. voor een bepaalde datum moeten alle tests achter de rug zijn; ook voor bepaalde hertestrondes kunnen tijdslimieten vooraf gedefinieerd worden [1]; gebruik van bepaalde tools, zoals planningspakketten, compilers, compareprogramma s, tools voor geautomatiseerd testen; etc. Copyright 1999... 3

Afbakening van het te testen object en het beoogde testproces, alsmede de testsoort [1] + [2]; wat wordt getest in welke testsoort (PT, IT, ST, AT, ET), afbakening van te testen systeemdelen, interfaces en functies, afbakening in testtijd voor bepaalde systeemdelen (bijv. systeemdeel X wordt in maximaal 4 werkdagen door 2 fte s getest, incl. hertest). Laat in het testplan duidelijk naar voren komen welke delen je niet test en bij wie wel die verantwoordelijkheid ligt. Een mogelijkheid is in de bijlage van het testplan een opsomming te geven van te testen functies en interfaces. Raakvlakken met overige (lopende) projecten; wat zijn de andere projecten, wat is hun invloed op het testtraject, hoe hangen de projecten met elkaar samen. Positiebepaling testtraject t.o.v. andere testtrajecten binnen het project; met name grootschalige testtrajecten worden in de praktijk ontleed tot meerdere testtrajecten; samenhang en onderlinge afhankelijkheden worden hier benoemd. 2.2 Teststrategie In een testplan dient uiteengezet te zijn, wat de te volgen teststrategie is. Het bepalen van de teststrategie is een onderbouwd keuzeproces, waarbij diverse variabelen een rol spelen in dat keuzeproces. Hieronder volgen de meest belangrijke variabelen. Welke delen van het te testen systeem zijn kritisch voor het bedrijfsproces van de organisatie (bijv. een verzekeringsmaatschappij heeft groot belang bij een correct werkende prolongatie, omdat daarmee het meeste geld wordt verdiend, of bijv. de front office van een call center systeem, waar de schermafhandeling en presentatie vitaal is, omdat een telefonisch verkoopgesprek bijv. maximaal 3 minuten mag duren). Wat zijn de kritische bedrijfseigenschappen en gebruikerswensen, bijv. binnen 1 etmaal ontvangt de klant zijn nota, of het systeem biedt de mogelijkheid voor een time to market van een nieuw bankprodukt van 2 maanden doorlooptijd. Risico s (zie paragraaf 2.6). Time boxing of budget boxing; binnen bepaalde tijd of budgetgrenzen moet een systeem (of systeemdelen) (voor een bepaald percentage dekkingsgraad) getest worden. Welke kwaliteitseisen en normen gelden voor welke systeemdelen, functies en interfaces. Prioriteiten in te testen systeemdelen, functies en interfaces en mate van diepgang waarmee deze delen getest moeten worden. Kwaliteit van de testbasis; in hoeverre bieden de specificaties mogelijkheden om te kunnen testen. Kennis bij de tester(s) en coordinator op het gebied van testen en de materie/het bedrijfsproces. Kunde en persoonlijke vaardigheden bij de tester(s) en coordinator zijn eveneens van belang. Gebruik van een nieuwe testaanpak of het gebruik van nieuwe testtools. Bijv. een organisatie wil gebruik maken van een record en play back tool, echter kennis en ervaring hiermee is er nauwelijks. Dat geeft aanleiding tot keuzes ten aanzien van activiteiten en planning in het testtraject. Omvang van het systeem in functiepunten; op basis van het aantal functiepunten (of bij het ontbreken hiervan het aantal functies, tabellen en entiteiten) per deelsysteem kan een inschatting worden gemaakt voor de testinspanningen. Opdrachtformulering; de aspecten die genoemd zijn in de vorige paragraaf vormen eveneens input voor de teststrategie. De weergave van deze teststrategie dient in ieder geval de volgende items te bevatten: Copyright 1999... 4

Kwaliteitsattributen: er dient te zijn weergegeven op welke kwaliteitsattributen het te testen object wordt getoetst [2]. Definieer op basis van de kwaliteitsattributen kwaliteitseisen. Maak die zoveel mogelijk kwantificeerbaar en meetbaar. Met testen wordt immers getoetst in hoeverre wordt voldaan aan de kwaliteitseisen. De kwaliteitseisen worden gekoppeld aan de systeemdelen. Relatief belang van kwaliteitsattributen: er dient te zijn bepaald wat het relatief belang van de te toetsen kwaliteitsattributen is [2]. Hieruit vloeit de prioriteit voort welke attributen en eisen je test. Relatief belang van deelsystemen: er dient te zijn bepaald wat het relatief belang van de eventuele verschillende deelsystemen, interfaces en functies is [2]. Testtechnieken; er dient te zijn aangegeven wat (per deelsysteem/per kwaliteitsattribuut) de gebruikte testtechniek is [2]. Dekkingsgraad per testtechniek / per deelsysteem / functie / interface; of bijvoorbeeld welke en hoeveel coderegels moeten worden getest (m.n. bij de PT en ST is dit van belang). Verdeling van testtijd/inspanningen over de systeemdelen en kwaliteitseisen. Beredenering; de strategie dient onderbouwd te worden. Het moet voor een projectleider zonder testkennis logisch en helder zijn waarom voor de strategie wordt gekozen. 2.3 Testaanpak Gaf het vorige hoofdstuk aan het hoe en waarom van de test, dit hoofdstuk biedt inzicht in wat je gaat doen. De testaanpak geeft dus aan wat je gaat doen in het testtraject. Dit mag geen algemeen verhaal zijn, maar moet specifiek ingaan op de situatie waar je voor staat. Kom dus niet met theorieen die de opdrachtgever ook terug kan vinden in de gangbare testliteratuur. Dit hoofdstuk ontleent zijn toegevoegde waarde aan het feit dat hier ingegaan wordt op de specifieke situatie en problematiek en hoe je die in het testraject gaat aanpakken. Geef aan welke fasering je kiest, en wat je in die fase doet en wat de op te leveren produkten zijn. Hoe ga je te werk. Wat zijn bijzondere aspecten in de aanpak die nog niet zijn vermeld in de teststrategie. Een voorbeeld kan zijn als getest wordt in onderhoudssituaties, dat gebruik wordt gemaakt van bestaande testware en dat bijzondere aandacht wordt besteed aan regressietesten. Hoe ga je om met deze bijzondere aspecten. 2.4 Testbasis De testbasis is een opsomming van documenten die de basis vormen waarmee het testontwerp en de testgevallen worden gecreeerd. Voorbeelden kunnen zijn: Functionele specificaties (ook wel genoemd Functioneel Ontwerp, Basis Ontwerp, Logisch Detail Ontwerp e.d.). Technisch ontwerp. Business cases. Besluitenlijsten. Werkdocumenten en memo s. Handleidingen, gebruikersdocumentatie. Copyright 1999... 5

Zorg bij gebruik van dit materiaal voor formele goedkeuring door de opdrachtgever. Geef per document aan welke versie gebruikt wordt als testbasis. 2.5 Testbeoordeling Geef in het testplan aan hoe de kwaliteit en risico s tijdens het testproces beoordeeld worden. De volgende criteria worden benoemd in het testplan. Let wel: een aantal punten kan reeds beschreven zijn in een kwaliteitssysteem of master testplan binnen de organisatie. Acceptatiecriteria ten aanzien van eventueel geconstateerde problemen [1]; hoe moet een bevinding omschreven worden, aan welke eisen moet het voldoen qua leesbaarheid (je moet het als tester en coordinator ook later kunnen begrijpen wat precies de bevinding was), traceerbaarheid (om voor de ontwikkelaar aan te geven welke handelingen werden verricht in het systeem dat leidde tot de bevinding), volledigheid (qua omschrijving, prioriteit/urgentie van de bevinding, evt. samenhang met andere bevindingen, betrokken systeemdeel of functie). Bevindingenregistratie; hoe vindt de registratie van bevindingen plaats. Welke hulpmiddelen worden gebruikt om bevindingen vast te leggen, wie mag ze vastleggen, welke autorisaties gelden er voor de bevindingenregistratie, wat moet en mag worden vastgelegd van elke bevinding. Bevindingen kunnen betrekking hebben op: de testbasis; het testobject (verschillen tussen specificaties en testresultaten); de hulpmiddelen, zoals testtools, compareprogramma s e.d.; de testomgeving (netwerkstoringen, computerstoringen, fouten in de JCL of verkeerde versie JCL, verkeerde libraries, verkeerde versie software staat klaar, databestanden kloppen niet, verkeerde versie referentietabellen e.d.); de standaarden en voorschriften (bijv. de standaarden voor schermopbouw, online foutafhandeling etc.); de testspecificaties zelf (de eigen testgevallen zijn niet correct, bijv. verkeerde outputverwachting is gedefinieerd). Acceptatie, beoordeling en klassificatie van geconstateerde testresultaten en bevindingen. Wie pleegt overleg en wanneer, wie is betrokken bij en wie neemt welke beslissing ten aanzien van bevindingen. Een duidelijke scheiding in klasse en prioriteit dient te worden aangegeven tussen verschillende bevindingen. Klasses lopen van hoge prioriteit tot laag. Aflopend zijn dat: storingen en abends, testbelemmerende fouten, geen testbelemmerende fouten, bevindingen van cosmetische aard. Geef eensluidende definties van de verschillende klasses. Handig is hierbij ook meetbare normen te maken, bijv. testbelemmerend wil zeggen dat niet binnen 30 minuten verder kan worden gegaan met een volgende test. Afhandeling van de verschillende soorten bevindingen. Per klasse en prioriteit dient beschreven te zijn hoe de verdere afhandeling van het probleem verloopt. 2.6 Risico s De aan het project verbonden risico s worden opgesomd. Deze opsomming voldoet aan de volgende eisen: Copyright 1999... 6

Risico s bij aanvang van en tijdens het testtraject: er is aangegeven wat de mogelijke risico s voor het beschreven project zijn. Risico s kunnen betrekking hebben op de voortgang en kwaliteit van het testtraject, bijv. beschikbare capaciteit, beschikbare doorlooptijd e.d.). Risico s kunnen ook betrekking hebben op de business dat het te testen systeem ondersteunt. Risico s worden omschreven in termen wat de impact is op de voortgang van het testtraject, maar ook op de business als geen maatregelen worden genomen om het risico te verminderen. Voorkom vage omschrijvingen in risico s, maar kwantificeer risico s en impact zoveel mogelijk. Dat spreekt opdrachtgevers goed aan. Neem een klassificatie op van risico s, opdat voor de opdrachtgever duidelijk is welke risico s de belangrijkste zijn en de meeste impact hebben. Maatregelen: voor elk risico dat is weergegeven dient een te nemen maatregel ter voorkoming zijn opgenomen. 2.7 Organisatie Ten behoeve van de organisatie van de test dienen de volgende zaken beschreven te zijn in een testplan: Betrokken personen: wie is betrokken bij het testproces [1] + [2]. Taken en bevoegdheden van alle betrokken personen [1] + [2]. Escalatiekanalen; bij wie kan je terecht als de test in een impasse verkeert en er niet via de normale lijnen een besluit genomen kan worden. Inzetbaarheid; de totale inzetbaarheid per persoon voor het project [1]. Overleg- en communicatiestructuren; communicatiematrix; wie overlegt met wie en wanneer. Voortgangsrapportage: er is aangegeven hoe, wanneer en met welke frequentie gerapporteerd wordt over de voortgang van het testtraject [1]. Eindrapportage: er is aangegeven hoe de eindrapportage tot stand komt [1]. Ontvangers: er is aangegeven welke personen de rapportage ontvangen [1]. Resultaten: er is aangegeven welke personen de (tussen-) resultaten ontvangen en wanneer [1]. 2.8 Infrastructuur Het testplan dient een beschrijving te bevatten van de benodigde technische infrastructuur. De volgende punten zijn in deze beschrijving minimaal ingevuld: Apparatuur: de specifieke hard- en software die benodigd is voor uitvoering van de test [1] + [2]. Tools en testtools die gebruikt worden voor de verschillende testfasen, w.o. planningstools, record en playback tools. Testomgevingsaspecten; per onderdeel van de omgeving is aangegeven gedurende welke periode het ter beschikking is van de testuitvoerenden [1]. Het kan voorkomen dat de testomgeving ook voor andere doeleinden gebruikt wordt. Machinecapaciteit; hoeveel capaciteit is nodig voor de verschillende fases van de test en hoeveel staat ter beschikking; in hoeverre is het mogelijk een schaduwdatabase te creeren voor de test met het oog op de beschikbare machinecapaciteit. Versiebeheer en overdracht van versies naar de testomgeving. Dit geldt voor alle componenten die een rol spelen bij de test, zoals de software, functionele en technische Copyright 1999... 7

specificaties, testspecificaties en draaiboeken, tussenprodukten, eindprodukten, hardware, besturingssoftware. Voor overdracht van versies naar een testronde is het verstandig oplever- of overdrachtsprocedures te maken en gebruiken. Dit zijn checklists waarmee je voor jezelf en ontwikkelaars zekerstelt dat je de juiste versies van componenten krijgt om te testen. 2.9 Planning In het testplan is een aantal planningen opgenomen. Bij de planningen is duidelijk een samenhang met de testfasering terug te vinden. Onderstaande planningen komen voor in testplannen. Globale doorloop-planning: hier is globaal aangegeven wat per testonderdeel de te verwachten doorlooptijd is. Globale planning (schematisch): hier is schematisch aangegeven wat de planning van het project is (globaal) [1] + [2]; hierin zijn ook de afhankelijkheden met andere trajecten aangegeven. Detailplanning: deze planning bevat alle uit te voeren subactiviteiten en de toegewezen persoon voor de uitvoering van deze activiteit. Deze planning zal leidend zijn voor voortgangscontrole. Mijlpalenplanning: Deze planning bevat uitsluitend de door het project op te leveren mijpalen inclusief de geplande datum. Een mijlpaal dient per definitie akkoord te zijn bevonden. Overzicht van geschatte kosten van het testtraject, i.c. kosten van arbeid en tools en hulpmiddelen. Benodigd aantal mensuren: aangegeven is hoeveel mensuren benodigd zijn om de test volledig (en per activiteit) volgens de gekozen strategie uit te voeren [1]. Benodigde capaciteit van systeem- en functioneel beheer. Copyright 1999... 8

3 Checklist Om een testplan te beoordelen kan de volgende checklist worden gehanteerd. Achter elke criterium wordt een vink gezet als het criterium aanwezig is of niet van toepassing. Staat er geen vink achter het criterium, dan moet dat aspect nog worden opgenomen in het testplan. De checklist geeft niet aan of het criterium op een kwalitatief goede wijze is omschreven in het testplan. Criterium Management samenvatting Opdrachtformulering Opdrachtgever is genoemd Opdrachtnemer is genoemd Doelstelling is beschreven Opdrachtomschrijving is omschreven Randvoorwaarden en uitgnagspunten zijn genoemd Afbakening is aanwezig Raakvlakken met overige (lopende) projecten zijn genoemd Positiebepaling testtraject t.o.v. andere testtrajecten binnen het project Teststrategie Kwaliteitsattributen zijn aangewezen Relatief belang van kwaliteitsattributen is aangegeven Relatief belang van deelsystemen is aangegeven Testtechnieken zijn bepaald Dekkingsgraad per testtechniek / per deelsysteem / functie / interface Verdeling van testtijd/inspanningen over de systeemdelen en kwaliteitseisen Beredenering / onderbouwing strategie is aangegeven Testaanpak Fasering en produkten zijn benoemd Hoe ga je te werk Bijzondere aspecten zijn beschreven Omgang met bijzondere aspecten is omschreven Testbasis Documenten zijn benoemd Testbeoordeling Acceptatiecriteria van geconstateerde bevindingen zijn aangegeven Bevindingenregistratie is georganiseerd Acceptatie, beoordeling en klassificatie van bevindingen is bepaald Afhandeling van bevindingen is bepaald Risico s Risico s bij aanvang van en tijdens testtraject zijn beschreven Maatregelen zijn aangegeven Organisatie Betrokken personen zijn genoemd Taken en bevoegdheden zijn genoemd Escalatiekanalen zijn beschreven Inzetbaarheid is beschreven Overleg- en communicatiestructuren zijn beschreven Voortgangsrapportage is beschreven Eindrapportage is beschreven Check OK NVT Copyright 1999... 9

Ontvangers zijn aangegeven Resultaten rapportage is beschreven Infrastructuur Apparatuur is beschreven Tools en testtools en hun functie in het testproces zijn benoemd Testomgevingsaspecten zijn genoemd Machinecapaciteit is genoemd Versiebeheer en overdracht van versies is geregeld Planning Globale doorloopplanning is beschreven Globale planning (schematisch) is opgenomen, incl. afhankelijkheden Detailplanning is opgenomen Mijlpalenplanning is beschreven Geschatte kosten worden weergegeven Benodigd aantal mensuren is aangegeven Benodigde capaciteit van systeem- en functioneel beheer Copyright 1999... 10