Testplan <NAAM INFORMATIESYSTEEM/PROJECT>

Transcriptie

1 Testplan <NAAM INFORMATIESYSTEEM/PROJECT> é 2000 Pag. 1

2 Inhoud 1. DOCUMENTGEGEVENS WIJZIGINGSHISTORIE DISTRIBUTIE OPENSTAANDE PUNTEN ACCORDERING WIJZIGINGSPROCEDURE OPDRACHT OPDRACHTGEVER OPDRACHTNEMER HISTORIE EN DOEL PROJECT OPDRACHT TESTOBJECT AFBAKENING VAN DE OPDRACHT POSITIE TEN OPZICHTE VAN ANDERE TESTTRAJECTEN RANDVOORWAARDEN UITGANGSPUNTEN UITGANGSDOCUMENTATIE TESTBASIS NORMEN EN STANDAARDS GERAADPLEEGDE DOCUMENTATIE TESTSTRATEGIE INLEIDING KRITISCHE FUNCTIONALITEITEN DEKKINGSGRAAD TE TESTEN KWALITEITSATTRIBUTEN TE GEBRUIKEN TESTTECHNIEKEN RELATIEF BELANG DEELSYSTEMEN STOP EN HERVATTINGS-CRITERIA STRATEGIE T.A.V. HERTESTEN TESTPRODUCTEN INLEIDING TESTWARE PROJECTDOCUMENTATIE BEHEER TESTPRODUCTEN GOEDKEURING PRODUCTEN FASERING VAN HET TESTPROCES FASERING BIJZONDERE ASPECTEN ORGANISATIE EN COMMUNICATIE ORGANISATIESTRUCTUUR TAAKVERDELING INZETBAARHEID MEDEWERKERS OVERLEGVORMEN COMMUNICATIEMATRIX RAPPORTAGES OPLEIDINGEN WIJZE VAN OVERDRACHT ESCALATIE TESTINFRASTRUCTUUR INLEIDING é 2000 Pag. 2

3 8.2 TESTOMGEVING Hardware Software KANTOORINRICHTING BEHEER TESTOMGEVING INFRASTRUCTUURPLANNING ENTRY- EN EXIT-CRITERIA INLEIDING ENTRY- EN EXIT-CRITERIA Entry-criteria Exit-criteria ACCEPTATIE ACCEPTATIECRITERIA ACCEPTERENDE PARTIJEN RISICO S EN BEHEERSINGSMAATREGELEN PLANNING MIJLPALENPLANNING GLOBALE DOORLOOPPLANNING DETAILPLANNING FASE VOORBEREIDING CAPACITEITSPLANNING TEST Onderbouwing uren fase Planning en beheer Onderbouwing uren Voorbereidingsfase Onderbouwing uren Specificatiefase Onderbouwing uren Uitvoeringsfase Onderbouwing uren Afrondingsfase Margin of error BEGROTING é 2000 Pag. 3

4 1. Documentgegevens 1.1 Wijzigingshistorie Versie Datum Wijziging Auteur 1.2 Distributie Dit document wordt verzonden aan: Organisatie/afdeling Naam Functie Telefoon/mail DE DISTRIBUTIE KAN PER VERSIE VERSCHILLEN. 1.3 Openstaande punten Versie VERSIENUMMER van dit testplan bevat de volgende openstaande punten: Paragraaf Openstaande issue Actie door 1.4 Accordering BESCHRIJF WIE BESLIST OMTRENT ACCORDERING VAN HET TESTPLAN EN OP WELKE WIJZE ACCOORDVERKLARING PLAATSVIND. 1.5 Wijzigingsprocedure BESCHRIJF WIE BESLIST OMTRENT WIJZIGINGEN IN HET TESTPLAN/DE OPDRACHT, WIE AANPASSINGEN VERRICHT EN OP WELKE WIJZE WIJZIGINGEN WORDEN GE- COMMUNICEERD MET BETROKKENEN. é 2000 Pag. 4

5 2. Opdracht 2.1 Opdrachtgever De opdrachtgever is NAAM FUNCTIONARIS, FUNCTIE bij de OPDRACHTGEVER. 2.2 Opdrachtnemer De opdrachtnemer is NAAM PROFESSIONAL, FUNCTIE PROFESSIONAL BIJ DE OP- DRACHTGEVER. 2.3 Historie en doel project KORTE BESCHRIJVING VAN DE ACHTERGROND EN HET DOEL VAN HET PROJECT. 2.4 Opdracht BESCHRIJVING VAN DE OPDRACHT. OPDRACHTEN WORDEN BIJ VOORKEUR SMART GEFORMULEERD. DIT BETEKENT DAT DE OPDRACHTOMSCHRIJVING DE VOLGENDE KENMERKEN HEEFT: DE OPDRACHT IS SPECIFIEK VOOR WAT BETREFT HET DOEL EN TE BEREIKEN RESULTAAT HET RESULTAAT IS MEETBAAR EN ER IS AFGESPROKEN HOE METING PLAATS ZAL VINDEN DE OPDRACHT IS ACCEPTABEL VOOR DE BETROKKEN PARTIJEN DE OPDRACHT IS REALISTISCH (DENK OOK AAN HAALBAARHEID) DE OPDRACHT IS TIJDGEBONDEN, MET ANDERE WOORDEN, HET IS DUIDELIJK WANNEER BEPAALDE RESULTATEN BEREIKT MOETEN ZIJN 2.5 Testobject OMSCHRIJVING VAN HET TE TESTEN OBJECT. 2.6 Afbakening van de opdracht Binnen het kader van de opdracht valt: Buiten het kader van de opdracht valt: 2.7 Positie ten opzichte van andere testtrajecten BESCHRIJF DE RELATIE TEN OPZICHTE VAN EVENTUELE UNIT-, INTEGRATIE- EN SYSTEEMTESTEN DOOR DE LEVERANCIER. BESCHRIJF DE RELATIE TEN OPZICHTE VAN ANDERE TESTTRAJECTEN. é 2000 Pag. 5

6 2.8 Randvoorwaarden Door de opdrachtgever zijn de volgende randvoorwaarden gesteld aan het testtraject: 2.9 Uitgangspunten De opdrachtnemer hanteert de volgende uitgangspunten bij aanvaarding van de opdracht: De OPDRACHTGEVER levert de in dit plan begrote (gebruikers)inzet ten behoeve van ondersteuning van het testtraject Door LEVERANCIER worden naar behoren een unit-, programma- en systeemtest verricht waarin wordt aangetoond dat het systeem NAAM INFORMATIESYSTEEM in overeenstemming met de functionele specificaties is gebouwd. De programmatuur van het systeem NAAM INFORMATIESYSTEEM mag als correct werkend worden beschouwd bij aanvang van de testuitvoering Dit plan gaat uit van e en testronde en maximaal e en hertestronde naar aanleiding van herstelwer...amheden op bevindingen De planning voor de in dit plan behandelde test is gebaseerd op het uitgangspunt dat per dag testuitvoering er maximaal 8 bevindingen worden gedaan. Indien het aantal bevindingen hoger uitvalt, dan wel indien er Blokkerendeöbevindingen worden gedaan, kan de doorlooptijd van de testuitvoering hoger uitvallen De testcoordinator krijgt de beschikking over een projectplanning op basis waarvan de testplanning kan worden geformuleerd. Wijzigingen in de projectplanning worden direct met de testcoordinator gecommuniceerd Voorafgaande aan de start van de voorbereidingsfase worden door de OPDRACHTGE- VER een testbare set systeemspecificaties beschikbaar gesteld. De betreffende documenten dienen compleet, onderling consistent en leesbaar te zijn voor leden van het testteam NAAM VERANTWOORDELIJKE is verantwoordelijk voor het inrichten en beheren van een testomgeving die als het ware productieöis LEVERANCIER verzorgt volgens planning de oplevering van het volledig ingerichte systeem NAAM INFORMATIESYSTEEM in de testomgeving en stemt opleveringen af met de testcoordinator LEVERANCIER levert ondersteuning aan de testteams in de vorm van het beschikbaar stellen van capaciteit voor het beantwoorden van functionele en technisch vragen en het verhelpen van verstoringen in de programmatuur DE GENOEMDE UITGANGSPUNTEN ZIJN VOORBEELDEN. é 2000 Pag. 6

7 3. Uitgangsdocumentatie 3.1 Testbasis De testbasis omvat de documentatie op basis waarvan het mogelijk is testgevallen op te stellen. Voor het systeem NAAM INFORMATIESYSTEEM is de volgende testbasis benodigd: Document Versie Datum Datum beschikbaar Auteur 3.2 Normen en standaards Bij het inrichten van de testwer...amheden wordt zoveel mogelijk aangesloten bij de methode NAAM GEHANTEERDE METHODIEK. 3.3 Geraadpleegde documentatie Bij het opstellen van dit testplan zijn de volgende documenten geraadpleegd: Document Versie Datum Auteur é 2000 Pag. 7

8 4. Teststrategie 4.1 Inleiding De teststrategie beschrijft op welke wijze de kwaliteit van het informatiesysteem NAAM IN- FORMATIESYSTEEM wordt bepaald. De teststrategie is het belangrijkste onderdeel van een testplan, aangezien zij definieert welke aanpak is gekozen voor het testen. LET OP: IN PRINCIPE BESLIST DE OPDRACHTGEVER OVER DE TESTSTRATEGIE. DE TESTCOORDINATOR ONDERSTEUNT BIJ HET MAKEN VAN KEUZES EN VERZORGT DE BESCHRIJVING VAN DE STRATEGIE IN HET TESTPLAN. 4.2 Kritische functionaliteiten Kritische functionaliteiten zijn volgens de opdrachtgever: ë De kans op verstoringen (= het technisch of functioneel niet aan de verwachtingen voldoen) wordt door de opdrachtgever het grootst geacht in: ë 4.3 Dekkingsgraad BESCHRIJVING VAN DE GEWENSTE MATE VAN DIEPGANG VAN DE TEST. De gekozen dekkingsgraad is mede gebaseerd op de aanduiding van de kritische functionaliteiten. BEPAAL OP BASIS VAN EEN TAXATIE VAN DE TE LOPEN RISICOöS WELKE DELEN VAN HET SYTEEM WEL/NIET WORDEN GETEST. 4.4 Te testen kwaliteitsattributen De opdrachtgever heeft een aantal kwaliteitsattributen (= meetbare eigenschappen van een informatiesysteem) vastgesteld waarop de testwer...amheden gericht dienen te zijn. In de onderstaande matrix is aangeven wat de geselecteerde kwaliteitsattributen zijn en welk relatief belang daaraan is toegekend. Kwaliteitsattributen Relatief belang (3 = groot belang, 2= redelijk van belang, 1 = gering belang) 4.5 Te gebruiken testtechnieken Het systeem NAAM INFORMATIESYSTEEM valt uiteen in AANTAL te onderscheiden deelsystemen (testeenheden). Het betreft: ë é 2000 Pag. 8

9 Op basis van het voorgaande zijn de te hanteren testtechnieken bepaald. In de navolgende matrix is aangegeven op welke wijze de geselecteerde kwaliteitsattributen getest gaan worden. Dit onder uitdrukkelijk voorbehoud van de resultaten van de voorbereidingsfase. Daarin zal namelijk moeten blijken of de genoemde technieken toepasbaar zijn, gezien de status en inhoud van de beschikbare testbasis. Deelsystemen TESTEENHEID 1 TESTEENHEID 2 TESTEENHEID 3 TESTEENHEID 4 Kwaliteitsattributen DE BOVENSTAANDE MATRIX WORDT ALS VOLGT GEVULD. LANGS DE HORIZONTALE AS WORDEN DE ONDERSCHEIDEN TESTEENHEDEN BENOEMD EN LANGS DE VER- TICALE AS DE KWALITEITSATTRIBUTEN WAAROP GETEST GAAT WORDEN. VOOR ELKE COMBINATIE VAN EEN TESTEENHEID EN EEN KWALITEITSATTRIBUUT WORDT BEPAALD OF DEZE ONDERWERP VAN TEST IS. ZO JA, DAN WORDT IN DE MATRIX BIJ DE BETREFFENDE COMBINATIE DE TE HANTEREN TESTTECHNIEK BENOEMD. VERMELD EEN ONDERBOUWING VAN DE KEUZE VAN TESTTECHNIEKEN. LEG DAARBIJ EEN RELATIE TUSSEN KWALITEITSATTRIBUTEN EN DE GEKOZEN TEST- TECHNIEKEN. 4.6 Relatief belang deelsystemen Sommige deelsystemen hebben een groter belang dan anderen. Het relatief belang per deelsysteem is in deze paragraaf weergegeven. Deelsysteem Relatief belang TESTTECH- NIEK 1 TESTTECH- NIEK 2 TESTTECH- NIEK 3. TESTEENHEID 1 TESTEENHEID 2 TESTEENHEID 3 ë. Totaal 100% De bovenstaande tabel geeft globaal weer hoe de testinspanning wordt verdeeld over de diverse deelsystemen en de gekozen testtechnieken. Zij dient als richtlijn voor de testers bij het verdelen van hun tijd en als stuurmiddel voor de testcoordinator. 4.7 STOP en hervattings-criteria OMSCHRIJVING WANNEER TESTUITVOERING TIJDELIJK OF PERMANENT GESTAAKT WORDT. BIJVOORBEELD ALS HET SYSTEEM VEEL INSTABIEL GEDRAG TOONT OF ER BLOKKERENDE BEVINDINGEN WORDEN GEDAAN (TIJDELIJK STAKEN). DEFINI- é 2000 Pag. 9

10 TIEF STAKEN IS AAN DE ORDE ALS HET SYSTEEM VAN VOLDOENDE KWALITEITS IS EN HET NIET RENDABEL IS OM DOOR TE GAAN MET TESTEN OMDAT ER NOG MAAR HEEL WEINIG (EN ONBELANGRIJKE) BEVINDINGEN WORDEN GEDAAN). TE DENKEN VALT AAN HET BENOEMEN VAN EEN GRENSWAARDE, ZOALS EEN MEAN TIME BET- WEEN FAILURES, WAAROP DE TESTUITVOERING WORDT GESTAAKT. EEN ANDERE MOGELIJKE MAATSTAF IS DE VERHOUDING TUSSEN HET AANTAL TESTGEVALLEN DAT IS UITGEVOERD ZONDER DAT DAARBIJ BEVINDINGEN WERDEN GEDAAN EN HET TOTAAL AANTAL UITGEVOERDE TESTGEVALLEN. ALS EEN ZEER GROOT DEEL VAN DE UITGEVOERDE TESTGEVALLEN NIET TOT BEVINDINGEN HEEFT GELEID KAN DIT REDEN ZIJN OM DE TESTUITVOERING TE STAKEN. DE HERVATTINGSCRITERIA HEBBEN BETREKKING OP DE SITUATIE DAT EEN TEST TIJDELIJK IS GESTAAKT. BENOEM ONDER WELKE CONDITIES MEN WEER DOOR- GAAT MET TESTUITVOERING. 4.8 Strategie t.a.v. hertesten BESCHRIJVING WELKE AANPAK WORDT GEVOLGD. UITERSTEN ZIJN ENKEL HER- TEST VAN BEVINDINGEN VERSUS VOLLEDIGE REGRESSIETEST. WELLICHT WORDT DE AANPAK PER TESTGEVAL BEPAALD. KEUZE IS AFHANKELIJK VAN ZAKEN ALS BESCHIKBARE TIJD/BUDGET, MATE VAN RISICO, E.D. é 2000 Pag. 10

11 5. Testproducten 5.1 Inleiding In dit hoofdstuk is beschreven welke producten tot de deliverables van het testtraject horen. Daarbij is onderscheid gemaakt tussen testware en projectdocumentatie. 5.2 Testware Onder testware worden alle documenten, bestanden e.d. verstaan die de testgevallen, uitgangssituaties, uitvoervoorspellingen en testresultaten weergeven. De volgende zaken worden opgeleverd als testware: Logische en fysieke testgevallen Testscripts voor de NAMEN GEHANTEERDE TESTTECHNIEKEN Testdraaiboek Checklist intake testobject & testinfrastructuur Uitgangsbestanden ë 5.3 Projectdocumentatie Onder projectdocumentatie worden alle documenten verstaan ten behoeve van het aansturen van het testtraject. De volgende zaken worden opgeleverd als projectdocumentatie: Een testplan waarin de aanpak beschreven wordt voor het inrichten en uitvoeren van de test Rapport testbaarheid (document waarin een oordeel wordt geveld over de bruikbaarheid van de testbasis als informatiebron ten behoeve van het opstellen van testgevallen) Testeenhedenmatrix Specificatie gewenste infrastructuur Voortgangsrapportages Evaluatierapport ten aanzien van de testaanpak en het geteste informatiesysteem Metrieken t.a.v. het testproces en het testobject ë VOOR EEN AANTAL VAN DEZE DOCUMENTEN ZIJN TEMPLATES/CASCOöS AANWEZIG IN DE KENNISBIBLIOTHEEK. Niet tot de op te leveren testproducten behoren: ë VERMELD EXPLICIET WAT VOOR ZAKEN NIET WORDEN OPGELEVERD. ZEKER ALS HET RISICO BESTAAT DAT ER MISVERSTANDEN ONTSTAAN. 5.4 Beheer testproducten De testproducten worden gedurende het testtraject opgeslagen op een centrale locatie. De testcoordinator voert het beheer over de testproducten. Onderdeel daarvan is het bewaken van een consistente naamgeving van documenten, het voorkomen van redundanties en het waarborgen van de compleetheid van de testproducten. é 2000 Pag. 11

12 Er wordt onderscheid gemaakt tussen externe en interne testproducten. Externe testproducten zijn zaken die zijn opgesteld door personen buiten het testteam (ontwikkelaars, opdrachtgever, projectleiding, et cetera), doch die het testteam nodig heeft ten behoeve van het inrichten van de test. Te denken valt aan zaken als projectplannen, ontwerpen, planningen en dergelijke. Deze producten dienen toegankelijk te zijn voor het testteam, zodat zij haar plannen, testgevallen en dergelijke daarop kan afstemmen. Onder interne testproducten worden zaken verstaan die door leden van het testteam worden geproduceerd. De testproducten zijn opgeslagen op de navolgende locatie: LOCATIE TESTPRODUCTEN. BESCHRIJF DE STANDAARD NAAMGEVING DOCUMENTEN. EEN STANDAARDNAAM- GEVING BEVAT BIJVOORBEELD EEN OMSCHRIJVING VAN HET DOCUMENT, EEN VERSIENUMMER EN DE DATUM VAN UITGAVE. 5.5 Goedkeuring producten De in dit hoofdstuk genoemde testproducten worden ter goedkeuring voorgelegd aan XXXX. BESCHRIJVING VAN DE WIJZE VAN GOEDKEURING, TERMIJN WAARBINNEN BE- SLUITVORMING PLAATS DIENT TE VINDEN EN DE WIJZE VAN VASTLEGGING BE- SLUIT. é 2000 Pag. 12

13 6. Fasering van het testproces 6.1 Fasering Het testen van NAAM INFORMATIESYSTEEM vindt gefaseerd plaats. De onderscheiden fasen zijn: Planning & beheer Voorbereiding Specificatie Uitvoering Afronding Deze fasen worden hieronder nader omschreven. Planning & beheer Het doel van de fase 'Planning en beheer' is tweeledig, namelijk: 1. het vastleggen van een goedgekeurd testplan over de wijze waarop, en de randvoorwaarden en uitgangspunten waaronder, de test verricht zal worden; 2. beheren van het testproces, testcoordinatie en de bewaking van de voortgang. De fase Planning en beheer blijft parallel aan de overige fasen tot het eind van het testtraject doorlopen. Vervolgens worden achter elkaar de fasen Voorbereiding, Specificatie, Uitvoering en Afronding doorlopen. Voorbereiding Specificatie Uitvoering Afronding Doel van de fase Voorbereiding is inzicht te krijgen in de testbaarheid van de testbasis, het opstellen van een testeenhedenmatrix en het specificeren van de eisen aan de testinfrastructuur. Doel van de fase Specificatie is de vervaardiging van testgevallen, alsmede de realisatie van een gespecificeerde infrastructuur. Doel van de fase Uitvoering is de confrontatie van het informatiesysteem met het testdraaiboek en de vervaardiging van testresultaten. Het doel van de fase Afronding is tweeledig: 1. inzicht verschaffen in de kwaliteit van het testobject en de kwaliteit van het testproces; 2. conserveren van testware ten behoeve van toekomstig onderhoud. In hoofdstuk 12 is een globale doorloopplanning opgenomen die weergeeft hoe de verschillende fasen in de tijd zijn geplaatst. 6.2 Bijzondere aspecten BESCHRIJVING VAN EVENTUELE BIJZONDERE ASPECTEN VAN HET TESTTRAJECT. é 2000 Pag. 13

14 7. Organisatie en communicatie 7.1 Organisatiestructuur Het onderstaande schema geeft weer hoe de organisatiestructuur ten behoeve van de testwer...amheden eruit ziet. OPNEMEN ORGANOGRAM. 7.2 Taakverdeling DE ONDERSTAANDE ROLVERDELING IS TER ILLUSTRATIE OPGENOMEN EN IS NIET MAATGEVEND BIJ HET OPSTELLEN VAN TESTPLANNEN. Binnen het testtraject bestaan de navolgende rollen met de bijgenoemde taken/verantwoordelijkheden: De rol "Projectleider" De projectleider is verantwoordelijk voor de opdrachtformulering, het goedkeuren van het testplan en de aansturing van de testcoordinator. De projectleider legt verantwoording af aan XXXXXXXXXXX. De projectleider voert in relatie tot het testtraject de onderstaande taken uit: Formuleren van de opdracht; Beslissen omtrent goed- of afkeuring van het testplan; Aansturen van de testcoordinator; Beschikbaar stellen van informatie die benodigd is ten behoeve van het testtraject (zoals planningen en de testbasis); Beslissen omtrent aanvang en be indiging van test. ë. De rol projectleider wordt vervuld door NAAM PROJECTLEIDER. De rol Testcoordinator De testcoordinator is verantwoordelijk voor de coordinatie van de test en richt deze in. De testcoordinator voert de onderstaande taken uit: Opstellen, verkrijgen van goedkeuring voor en onderhouden van het testplan; Uitvoeren van het testplan binnen planning en budget; Beoordelen van de testbaarheid van de testbasis (intake testbasis); Beheren testproces en testproducten; é 2000 Pag. 14

15 Opstellen van templates ten behoeve van de specificatie van testgevallen (inrichten testtechnieken) en checklists; Specificeren eisen aan de testomgeving; Voorbereiden intakes van het testobject; Aansturen, begeleiden en ondersteunen van het testteam; Rapporteren aan de projectleider over voortgang van het testproces en de kwaliteit van het testobject; Intake testomgeving en testobject; Deelnemen aan evaluaties van het testproces en de kwaliteit van het informatiesysteem NAAM INFORMATIESYSTEEM en opstellen evaluatierapport. De rol testcoordinator wordt vervuld door NAAM PROFESSIONAL, FUNCTIE PROFESSIO- NAL. De rol "Beheerder testomgeving" De beheerder van de testomgeving is verantwoordelijk voor het beheer en onderhoud van de testomgeving. Deze functionaris bewerkstelligt dat de testteams kunnen beschikken over een testomgeving die voldoet aan de eisen die daaromtrent in dit testplan zijn geformuleerd. De beheerder van de testomgeving voert de onderstaande taken uit: Inrichting en beheer testomgeving (inclusief versiebeheer); Fysiek configuratiemanagement; Oplossing van technische problemen met de testinfrastructuur; Vullen en laden uitgangsbestanden. De rol Beheerder testomgeving wordt vervuld door NAAM BEHEERDER TESTOMGEVING. De rol "Tester" De testers zijn primair verantwoordelijk voor het opstellen van testscripts en een testdraaiboek op basis van de in dit testplan geformuleerde teststrategie en het uitvoeren van testgevallen. Tevens ondersteunen zij de testcoordinator bij de uitvoering van diens taak. De testers voeren de onderstaande taken uit: Specificatie van logische en fysieke testgevallen en initi le gegevens; Ondersteunen van de testcoordinator bij uiteenlopende wer...amheden. Uitvoeren van testgevallen (= dynamisch testen); Uitvoeren van onderzoeken aan de hand van checklists (= statisch testen); Registreren van bevindingen. De rol tester wordt vervuld door NAMEN TESTERS De rol "Problem Manager" De Problem Manager is verantwoordelijk voor het opstellen en bewaken van de procedures rondom afhandeling van bevindingen en het leveren van kwaliteitsrapportages ten behoeve van de projectleider en de testcoordinator. De Problem Manager voert de onderstaande taken uit: Opstellen procedure voor Problem Management; Toezien op naleving van de procedures rondom het registreren, beoordelen en afhandelen van bevindingen; é 2000 Pag. 15

16 Organiseren en voorzitten bevindingenoverleg; Communiceren met de bouwteams omtrent de interpretatie van bevindingen, eventuele oplossingen en afhandelingtermijnen (linking-pin naar de gebruikersorganisatie); Opstellen van kwaliteitsrapportages (aantallen bevindingen ingedeeld naar status, ernst, kwaliteitsattribuut, e.d.). De rol Problem Manager wordt vervuld door NAAM PROBLEM MANAGER. ALS DE ROL PROBLEM MANAGER NIET APART IS BELEGD, WORDT DEZE GEWOON- LIJK BIJ DE TESTCOORDINATOR BELEGD. De rol "Functionele ondersteuning" De functioneel ondersteuner is verantwoordelijk voor het beantwoorden van vragen omtrent de functionaliteit van het informatiesysteem NAAM INFORMATIESYSTEEM Beantwoorden van vragen van de testcoordinator en testers voor wat betreft geboden functionaliteiten. De rol functionele ondersteuning wordt vervuld door NAAM FUNCTIONELE ONDERSTEU- NER. De rol "Technische ondersteuning" De technisch ondersteuner is verantwoordelijk voor het beantwoorden van vragen omtrent de technische aspecten van het informatiesysteem NAAM INFORMATIESYSTEEM Beantwoorden van vragen van de testcoordinator en testers voor wat betreft technische aspecten. De rol technische ondersteuning wordt vervuld door NAAM TECHNISCH ONDERSTEUNER. 7.3 Inzetbaarheid medewerkers BESCHRIJF PER PERSOON WAT DIENS BESCHIKBAARHEID TEN BEHOEVE VAN TESTEN IS (AANTAL UREN PER WEEK, PERIODE). 7.4 Overlegvormen Binnen het testtraject bestaan diverse overlegvormen. BESCHRIJVEN WELKE OVERLEGVORMEN ER ZIJN, WIE DAARBIJ BETROKKEN ZIJN, WAT DE MOGELIJKE GESPREKSONDERWERPEN ZIJN EN DE WIJZE VAN VERSLAG- LEGGING. 7.5 Communicatiematrix EEN COMMUNICATIEMATRIX BESCHRIJFT MET WIE ER WORDT GECOMMUNICEERD EN OM WAT VOOR SOORT COMMUNICATIE HET GAAT (INFORMATIEF, PROBLEEM- OPLOSSEND, ET CETERA). TEVENS WORDT DE FREQUENTIE VAN DE COMMUNICA- TIE AANGEGEVEN. é 2000 Pag. 16

17 Communicatiemiddelen Vergaderingen Rapportages Communicatiepartners Informatief Probleemoplossend Besluitvormend Voortgang Kwaliteit Directie x-1 Opdrachtgever x-4 x-2 x-2 Stuurgroep x-1 Projectgroep x-12 Lijnmanagement x-2 Projectleider x-12 x-24 x-6 Testteam x-24 Rekencentrum x-1 x-4 Bouwteam x-1 x-8 Projectleider implementatie x-2 Beheerafdeling x-1 Eindgebruikers x-2 x-2 DE BOVENSTAANDE MATRIX IS GEVULD MET FICTIEVE WAARDEN. BIJ GEBRUIK VAN DE COMMUNICATIEMATRIX DEZE VULLEN MET DE FEITELIJKE COMMUNICATIE- PARTNERS EN PER PARTNER AANGEVEN WELKE COMMUNICATIEMIDDELEN WOR- DEN INGEZET. DE CIJFERS ACHTER DE Xö-EN GEVEN DE FREQUENTIE VAN COM- MUNICATIE AAN. HET GAAT DAARBIJ OM HET AANTAL MALEN DAT GEDURENDE HET PROJECT COMMUNICATIE PLAATSVINDT. DE FEITELIJKE INVULLING ZAL PER PRO- JECT ANDERS ZIJN. 7.6 Rapportages BESCHRIJVING VAN DE RAPPORTAGES DIE WORDEN UITGEBRACHT. DAARBIJ WORDT VERMELD WIE DE RAPPORTAGE OPSTELT, AAN WIE DIE IS GERICHT, HET DOEL VAN DE RAPPORTAGE, DE RAPPORTAGEFREQUENTIE, DE RAPPORTAGE- VORM EN WAT HET RESULTAAT VAN DE RAPPORTAGES KAN ZIJN. VOORBEELDEN VAN MOGELIJKE RAPPORTEN: VOORTGANGSRAPPORT EVALUATIE/EINDRAPPORT KWALITEITSRAPPORTAGES RAPPORT TESTBAARHEID MOGELIJKE ONDERWERPEN VOOR EEN VOORTGANGSRAPPORT ZIJN: BESTEDE UREN VERSUS GEPLANDE UREN VOORTGANG VAN DE TEST KWALITEIT VAN HET GETESTE SYSTEEM KNELPUNTEN BIJ DE TEST PLANNING VOOR DE KOMENDE PERIODE MOGELIJKE ONDERWERPEN VAN EEN EVALUATIERAPPORT ZIJN: é 2000 Pag. 17

18 MANAGEMENTSAMENVATTING VERLOOP VAN HET TESTPROJECT EVALUATIE VAN DE GEKOZEN TESTSTRATEGIE EVALUATIE VAN DE PLANNING (VERSUS REALISATIE) EVALUATIE VAN DE TESTORGANISATIE EVALUATIE VAN DE TESTINFRASTRUCTUUR EVALUATIE VAN HET TESTOBJECT BEVINDINGEN IN RELATIE MET DE KWALITEITSATTRIBUTEN WAAROP IS GE- TEST RISICOöS GEPAARD GAANDE MET IMPLEMENTATIE AANBEVELINGEN M.B.T. IMPLEMENTATIE EN BEHEERSING RISICOöS MOGELIJKE ONDERWERPEN VAN EEN KWALITEITSRAPPORT ZIJN: TOTAAL AANTAL BEVINDINGEN AANTAL BEVINDINGEN PER WEEK TESTUITVOERING AANTALLEN BEVINDINGEN PER VERSIE VAN DE SOFTWARE AANTALLEN BEVINDINGEN INGEDEELD NAAR STATUS AANTALLEN BEVINDINGEN INGEDEELD NAAR ERNST AANTALLEN BEVINDINGEN INGEDEELD NAAR KWALITEITSATTRIBUTEN WAAR ZIJ BETREKKING OP HEBBEN UITERAARD ZIJN OOK ANDERE VARIANTEN DENKBAAR. IN OVERLEG MET DE OP- DRACHTGEVER VAST TE STELLEN WAT RELEVANT IS. Omtrent de wijze waarop bevindingen worden geregistreerd en afgehandeld, rollen die daarbij door diverse partijen worden vervuld en statussen en classificatie van bevindingen biedt de procedure Problem management nadere informatie. Gedurende het testproces kan in overleg besloten worden de rapportagefrequenties te wijzigen. 7.7 Opleidingen BESCHRIJVING VAN EVENTUEEL BENODIGDE OPLEIDINGEN VOOR LEDEN TEST- TEAM. 7.8 Wijze van overdracht BESCHRIJF DE WIJZE WAAROP DOCUMENTEN, SOFTWARE, EN ONDERDELEN VAN DE TESTINFRASTRUCTUUR AAN HET TESTTEAM TER BESCHIKKING WORDEN GE- STELD EN DE WIJZE WAAROP HET TESTTEAM TESTPRODUCTEN OVERDRAAGT AAN DE ORGANISATIE. 7.9 Escalatie Indien zich bij de uitvoering van dit testplan verschillen van inzicht voordoen tussen personen of partijen die niet onderling opgelost kunnen worden, stellen de betrokkenen de opdrachtgever hiervan op de hoogte. Deze laat zich door de betrokken partijen informeren en neemt een beslissing. é 2000 Pag. 18

19 8. Testinfrastructuur 8.1 Inleiding De testinfrastructuur omvat alle faciliteiten en middelen die nodig zijn om adequaat te kunnen testen. Er wordt onderscheid gemaakt tussen faciliteiten voor de testuitvoering (de testomgeving) en de kantoorinrichting die benodigd is voor het testteam. Tijdens de fase voorbereiding vindt waar nodig een detaillering plaats van de eisen en wensen. 8.2 Testomgeving Om de testuitvoering naar behoren te kunnen verrichten, dient voor de testteams een testomgeving beschikbaar te zijn die qua inrichting zoveel mogelijk als ware het productie is. Deze testomgeving wordt opgeleverd door LEVERANCIER voor wat betreft de software van NAAM INFORMATIESYSTEEM. De OPDRACHTGEVER zorgt voor de noodzakelijke hardware en software die standaard beschikbaar is op een werkplek bij de OPDRACHTGE- VER Hardware CONCRETE BESCHRIJVING VAN DE BENODIGDE HARDWARE. DENK O.A. AAN: SERVERS PCöS NETWERKKOPPELINGEN PRINTERS OPSLAGCAPACITEIT Software Qua software is een volledig ingericht systeem NAAM INFORMATIESYSTEEM benodigd met minimaal AANTAL testomgeving(en). De testomgeving(en) is voorzien van user idös/passwords voor alle leden van de testteams. Eveneens dienen de test PCös voorzien te zijn van alle software die standaard onderdeel uitmaakt van de werkplek van de betrokken gebruikersorganisaties, teneinde een zo realistisch mogelijke omgeving te cre ren. 8.3 Kantoorinrichting Onderstaande kantoorinrichting is nodig om een adequate test te faciliteren: BESCHRIJVING BENODIGDE KANTOORINRICHTING. DENK BIJVOORBEELD AAN: WERKRUIMTE MET BUREAUöS, STOELEN EN PCöS OPBERGRUIMTE TELEFOON/FAX FLIPOVER 8.4 Beheer testomgeving BESCHRIJVING BIJ WIE HET BEHEER VAN DE TESTOMGEVING IS BELEGD EN VAN DE BEHEERPROCEDURE. DE ONDERSTAANDE TEKSTEN ZIJN ILLUSTRATIEF. é 2000 Pag. 19

20 De beheerder van de testomgeving stelt een procedure voor configuratiemanagement op. Aan testen onderhavige versies mogen niet verwisseld of overschreven worden door andere versies zonder uitdrukkelijk overleg met de testcoordinator. De Beheerder testomgeving zorgt dagelijks buiten kantoortijden voor back-up van de in de testomgeving(en) aanwezige testbestanden. Voorafgaande aan oplevering van componenten vindt overleg plaats met de testcoordinator. In dit overleg worden afspraken gemaakt omtrent het moment van oplevering. Dit overleg is erop gericht verstoringen in de voortgang van de testactiviteiten te minimaliseren. In het geval dat er nieuwe releases worden opgeleverd, controleert de beheerder van de testomgeving of de oplevering compleet is en of NAAM INFORMATIESYSTEEM na installatie van de nieuwe software nog correct functioneert. Eventuele bestanden met initi le gegevens die benodigd zijn ten behoeve van het uitvoeren van testgevallen, worden door de Beheerder van de testomgeving op verzoek van de testcoordinator aangemaakt. 8.5 Infrastructuurplanning Onderstaand is weergegeven wie verantwoordelijk is voor de selectie, verwerving en installatie van onderdelen van de testinfrastructuur. Tevens is een planning opgenomen waaruit blijkt wanneer welke onderdelen van de testinfrastructuur gerealiseerd dienen te zijn. VOORBEELDEN VAN ONDERDELEN ZIJN ZAKEN ALS PCöS, SOFTWARE, DATABASE INRICHTING, ET CETERA. Onderdeel Verantwoordelijke Datum gepland Benodigd tot (datum) Bijzonderheden é 2000 Pag. 20

21 9. Entry- en exit-criteria 9.1 Inleiding Dit hoofdstuk beschrijft op welke wijze getoetst wordt of aan alle voorwaarden om met de uitvoering van test te starten is voldaan (entry criteria) en hoe getoetst wordt of de testuitvoering kan worden afgerond (exit criteria). De werkwijze is als volgt. Aan de hand van de checklists die navolgend zijn opgenomen stelt de testcoordinator voorafgaande aan start en be indiging van testuitvoering een entry- of exitrapport op. In deze rapportages wordt tevens een advies gegeven omtrent het al dan niet starten/staken van de testuitvoering. De projectmanager neemt na ontvangst van het rapport van de testcoordinator een beslissing omtrent aanvang c.q. be indiging van de testuitvoering. 9.2 Entry- en exit-criteria Entry-criteria ONDERSTAAND ZIJN EEN AANTAL VOORBEELDEN VAN ENTRY-CRITERIA OPGENO- MEN. Nr. Criteria Voldaan J/N Opmerkingen 1. Het testplan en de bijbehorende testprocedures zijn geaccordeerd door de opdrachtgever 2. De checklists, testspecificaties en het testdraaiboek voor de test (die zijn opgesteld op basis van de testbasis) zijn gereed 3. De vereiste inzet van mensen en middelen is geregeld, evenals het beheer van de testomgeving 4. Het systeem is door LEVERAN- CIER opgeleverd in de testomgeving 5. De testomgeving voldoet aan de eisen die daaraan zijn gesteld 6. Er heeft een intake plaatsgevonden van de testinfrastructuur en het testobject (NAAM INFORMA- TIESYSTEEM) en naar aanleiding hiervan staan er geen blokkerende bevindingen open Exit-criteria NAVOLGEND ZIJN EEN AANTAL VOORBEELDEN VAN EXIT-CRITERIA OPGENOMEN. é 2000 Pag. 21

22 Nr. Criteria 1. Alle geplande tests zijn uitgevoerd 2. Ten aanzien van het systeem staan geen Blokkerendeöof Majoröbevindingen open 3. Minimaal XX% van de testgevallen is uitgevoerd met een positief resultaat 4. De Mean Time Between Failures ten tijde van het be indigen van de testuitvoering bedraagt minimaal XXX Voldaan J/N Opmerkingen é 2000 Pag. 22

23 10. Acceptatie 10.1 Acceptatiecriteria Testen is een activiteit die voorafgaat aan de feitelijke acceptatie van NAAM INFORMATIE- SYSTEEM. Een van de resultaten van het uitvoeren van tests, kan zijn dat bevindingen worden gedaan ten aanzien van de programmatuur. Deze bevindingen worden ingedeeld in categorie n. Het soort en aantal bevindingen dat openstaat na afloop van de testuitvoering is mede bepalend voor de vraag of het systeem geaccepteerd kan worden. AANDUIDING WAAR DE ACCEPTATIECRITERIA BESCHREVEN ZIJN. INDIEN GEEN ACCEPTATIECRITERIA BEKEND DIT VERMELDEN Accepterende partijen EEN BETROKKEN PARTIJ IS BIJVOORBEELD EEN AFDELING OF UNIT. ZIJ WORDT VERTEGENWOORDIGD DOOR EEN PERSOON. BIJ SCOPE ACCEPTATIEöWORDT AANGEGEVEN WELK DEEL DE PARTIJ IN KWESTIE ACCEPTEERT. DIT KAN HET GE- HEEL ZIJN, MAAR KAN OOK EEN DEEL VAN HET SYSTEEM BETREFFEN. TOT SLOT WORDT IN DE ONDERSTAANDE TABEL AANGEGEVEN OF DE PARTIJ IN KWESTIE BESLIST OMTRENT ACCEPTATIE, DAN WEL SLECHTS EEN ADVIES GEEFT. Betrokken partij Vertegenwoordiger Scope acceptatie Advies of beslissing é 2000 Pag. 23

24 11. Risico,s en beheersingsmaatregelen Op basis van de verzamelde en bestudeerde informatie ten aanzien van het project NAAM PROJECT is een risico-taxatie opgesteld. Deze is hieronder weergegeven. Per risico is beschreven welke maatregel wordt voorgesteld om het risico nader in beeld te brengen, dan wel te minimaliseren. BIJ HET INVENTARISEREN VAN RISICOöS KAN GEDACHT WORDEN AAN ZAKEN ALS UITVOERBAARHEID VAN DE TESTSTRATEGIE, ONDERDELEN DIE NIET OF MET MIN- DER DIEPGANG WORDEN GETEST, HAALBAARHEID (VAN DE PLANNING), TEST- BAARHEID, RISICOöS GEPAARD GAANDE MET WIJZIGINGEN IN DE TESTBASIS, BE- SCHIKBARE TIJD EN MANKRACHT, TIJDIGE BESCHIKBAARHEID INFORMATIE EN ON- DERSTEUNING, BESCHIKBAARHEID EN WERKING VAN DE TESTINFRASTRUCTUUR, RISICO VAN UITLOOP VAN SYSTEEMONTWIKKELING, KANS DAT OMVANG SYSTEEM TOENEEMT TEN OPZICHTE VAN HETGEEN WAAROP TESTBEGROTING IS GEBA- SEERD, ET CETERA. BEPAAL WELKE RISICOöS VAN TOEPASSING ZIJN OP HET TESTTRAJECT, HOE GROOT DE KANS EN IMPACT IS EN STEL ZO MOGELIJK MAATREGELEN VOOR TER BEHEERSING. Nr. Risico Gevolg (kans * impact) Maatregel Actie door Uiterlijk gereed é 2000 Pag. 24

25 12. Planning 12.1 Mijlpalenplanning DE MIJLPALENPLANNING BEVAT EEN OPSOMMING VAN MIJLPALEN IN HET TEST- TRAJECT. VOORBEELDEN VAN MIJLPALEN ZIJN: GEACCORDEERD TESTPLAN, RAP- PORT TESTBAARHEID, TESTSCRIPTS EN DRAAIBOEK GEREED, TEST UITGEVOERD, TEST AFGEROND. Mijlpaal Eindverantwoordelijke Datum gereed (gepland) Bijzonderheden Bij het opstellen van deze mijlpalenplanning is uitgegaan van de uitgangspunten zoals verwoord in paragraaf 2.7 van dit testplan. Het niet voldoen aan e en of meerdere uitgangspunten kan consequenties hebben voor de voortgang van de test Globale doorloopplanning Fase Start Gereed Planning en beheer Voorbereiding Specificatie Uitvoering Afronding VUISTREGEL BIJ VERDELEN TESTINSPANNING (DUS VARIATIE MOGELIJK): PLANNING EN BEHEER : 15% VOORBEREIDING : 8% SPECIFICATIE : 32% UITVOERING : 40% AFRONDING : 5% 12.3 Detailplanning fase Voorbereiding Activiteiten Start Eind Wie Product Afhankelijkheden é 2000 Pag. 25

26 12.4 Capaciteitsplanning test Rol Fase Planning & beheer Voorbereiding Specificatie Uitvoering Afronding Totaal uren Projectleider Testcoordinator Testers Problem Manager Beheerder testomgeving Functionele ondersteuning Inzet bouwteam Totaal uren (margin of error: 15%) -/- 15% (minimaal) + 15% (maximaal) Onderbouwing uren fase Planning en beheer Onderbouwing uren Voorbereidingsfase Onderbouwing uren Specificatiefase Onderbouwing uren Uitvoeringsfase Onderbouwing uren Afrondingsfase Margin of error Aangezien testen (nog) geen exacte wetenschap is, dient rekening te worden gehouden met een margin of error bij het begroten van de benodigde capaciteit. In dit plan wordt rekening gehouden met een margin of error van 15%. Dit betekent dat de totaal benodigde ureninspanning ligt tussen LAAGSTE SCHATTING en HOOGSTE SCHATTING uur. Tijdens de specificatiefase zal naar gelang de voortgang duidelijk worden aan welke kant van deze bandbreedte de benodigde inspanning uit zal komen. é 2000 Pag. 26

27 Bij het opstellen van deze capaciteitsplanning is uitgegaan van de uitgangspunten zoals verwoord in paragraaf 2.7 van dit testplan. Het niet voldoen aan e en of meerdere uitgangspunten kan consequenties hebben voor de benodigde capaciteit. é 2000 Pag. 27

28 13. Begroting In dit hoofdstuk zijn de kosten van het in dit testplan beschreven testtraject weergegeven. FACTOREN DIE KOSTENBEPALEND ZIJN: UREN INZET EXTERNEN (EN INTERNEN INDIEN ALS KOSTENPOST GEBOEKT) KOSTEN TESTOMGEVING (HARDWARE-, SOFTWARE-, TOOLS EN KANTOORINRICHTING) Onderstaand treft u een overzicht aan van de benodigde uitgaven. HET OPNEMEN VAN EEN BEGROTING ZAL NIET BIJ ELK TESTPROJECT AAN DE OR- DE ZIJN. INDIEN DE OPDRACHTGEVER WEL EEN BEGROTING VERWACHT, KAN DE ONDERSTAANDE OPZET WORDEN GEHANTEERD. POSTöSTAAT VOOR ZAKEN WAAR GELD AAN WORDT UITGEGEVEN (ZOALS DE IN- HUUR VAN PERSONEEL). DE EENHEIDSPRIJS IS BIJVOORBEELD EEN UURTARIEF OF DE KOSTEN PER LICENTIE VAN EEN SOFTWARE PROGRAMMA. DE KOSTEN WORDEN BEPAALT DOOR DE EENHEIDSPRIJZEN TE VERMENIGVULDIGEN MET HET AANTAL EENHEDEN (BIJVOORBEELD AANTAL UREN INZET). Post Eenheidsprijs Aantal eenheden Kosten Totale kosten Fl. xxxx é 2000 Pag. 28

29 BIJLAGE 1. PROCEDURE PROBLEM MANAGEMENT BESCHRIJVING VAN DE PROCEDURE PROBLEM MANAGEMENT. ZIE DE... KENNISBI- BLIOTHEEK VOOR VOORBEELDEN. é 2000 Pag. 29