Implementatieplan ten behoeve van een testtool

Implementatieplan ten behoeve van een testtool

Algemene informatie voor medewerkers van SYSQA B.V.

Datum : 11-4-2011 Status : Definitief Opgesteld door : SYSQA

Organisatie Titel Onderwerp

SYSQA BV Implementatieplan ten behoeve van een testtool Implementatieplan testtool

Pagina Versie Datum

2 van 21 1.7 11-04-2011

Inhoudsopgave 1

Managementsamenvatting .............................................................................. 4

2

Inleiding ............................................................................................................ 5

3

Toepassingsgebieden testtools...................................................................... 6

4

Voorbereiden van het implementatietraject ................................................... 8 4.1 4.2 4.3 4.4 4.5

Randvoorwaarden voor implementatie ..................................................................8 Beheer en techniek ...............................................................................................8 Dienstverlening ...................................................................................................10 Communicatie .....................................................................................................11 Opleiding ............................................................................................................13

5

Organisatie van het implementatietraject .................................................... 14

6

Nazorg van het implementatietraject ............................................................ 16 6.1 6.2 6.3 6.4

7

Tijdsbalk voor het implementatietraject ....................................................... 18 7.1 7.2 7.3 7.4 7.5 7.6

8

Beheer en techniek .............................................................................................16 Dienstverlening ...................................................................................................16 Communicatie .....................................................................................................17 Opleiding ............................................................................................................17

Gebruik tijdsbalk .................................................................................................18 Initiatiefase .........................................................................................................18 Voorbereiding .....................................................................................................18 Implementatie .....................................................................................................19 Beheer van het gebruik .......................................................................................19 Nazorg van de implementatie .............................................................................19

Checklist voor het implementatietraject ..................................................... 20 8.1 8.2 8.3 8.4 8.5 8.6

Gebruik checklist ................................................................................................20 Beheer en techniek ter voorbereiding van de implementatie ...............................20 Beheer en techniek na de initiële implementatie .................................................20 Organisatie .........................................................................................................20 Communicatie .....................................................................................................21 Opleiding ............................................................................................................21

Almere © 2011

Proud of it



Pagina Versie Datum

3 van 21 1.7 11-04-2011

Versiebeheer Versie Datum Opmerkingen 1.3 05-12-2009 Aanpassen bestaande document naar uitkomsten expertisegroep 1.4 15-02-2009 Correcties n.a.v. review Expertisegroep 1.5 13-04-2009 Correcties n.a.v. review SYSQA 1.6 20-04-2009 Definitieve versie in juiste opmaak geplaatst 1.7 11-04-2011 Aangepast aan nieuwe huisstijl en versiebeheer bijgewerkt

Auteur SYSQA SYSQA SYSQA SYSQA SYSQA

Verzendlijst Versie 1.3 1.4 1.5 1.6 1.7

Ontvanger Expertisegroep Expertisegroep SYSQA SYSQA SYSQA

Almere © 2011

Proud of it



Pagina Versie Datum

4 van 21 1.7 11-04-2011

1 Managementsamenvatting Steeds meer organisaties realiseren zich dat wanneer in een vroegtijdig stadium wordt begonnen met het testen van software de totale ontwikkelingskosten van de software worden gereduceerd. Om de testers in hun werk te ondersteunen worden testtools toegepast. Er zijn tegenwoordig dan ook legio testtools op de markt verkrijgbaar. Testtools zijn daarbij niet ontwikkeld om het testtraject te ontwikkelen of te structureren, maar om het testtraject te ondersteunen. Wel kan het gebruik van een testtool er toe leiden dat het testtraject veranderd moet worden. Het is echter noodzakelijk deze veranderingen te onderkennen en te beheren. Veel organisaties realiseren zich in eerste instantie niet dat het implementeren van een testtool binnen de organisatie initieel extra werk met zich meebrengt. Daarbij komen veelal tijdens of na de implementatie problemen naar voren die reeds aan het begin van de implementatie voorzien hadden kunnen worden. Het is dus essentieel dat nog vóór de daadwerkelijke implementatie de problemen worden onderkend en aangepakt. Wanneer er wordt gekeken naar de aandachtsgebieden die gelden bij een implementatie, kunnen deze worden onderverdeeld in vier categorieën: Beheer en Techniek, Dienstverlening, Communicatie en Opleiding. Binnen het aandachtsgebied Beheer en Techniek wordt gekeken naar de eisen die de testtool stelt aan de systeemomgeving waarbinnen het wordt toegepast. Men dient er voor te waken dat men een testtool aanschaft die niet binnen de systeemomgeving kan functioneren. Het aandachtsgebied Dienstverlening richt zich op de wijze waarop de gebruikersondersteuning binnen de organisatie is geregeld. Welke personen zijn te benaderen voor vragen over de werking van de testtool en voor het oplossen van technische problemen. De rol van de leverancier is hierbij ook van belang. Het is van belang dat zodra men de beslissing heeft genomen om een testtool te gaan implementeren, dit kenbaar gemaakt wordt binnen de organisatie. Hiervoor zijn verschillende communicatiemethoden beschikbaar. Deze komt naar voren in het aandachtsgebied Communicatie. Om zeker te zijn dat de personen die met de testtool gaan werken hiervoor voldoende kennis hebben, worden opleidingen georganiseerd. Daarnaast kan gekozen worden voor een meer uitgebreide opleiding voor een beperkte groep personen die een rol zullen gaan spelen bij de dienstverlening binnen de organisatie. Ook hierbij kan de leverancier een belangrijke rol spelen. In het laatste aandachtsgebied, Opleiding, wordt hier meer aandacht aan besteed. De verschillende aandachtsgebieden kennen een aantal aspecten die tijdsafhankelijk van elkaar zijn. Het is daarom ook van belang om van tevoren te bepalen welke aspecten van toepassing zijn binnen een organisatie. Het implementeren van een testtool beperkt zich dus niet alleen tot het installeren van de verkregen software en het distribueren van de bijgeleverde handboeken, maar raakt vele aspecten.

Almere © 2011

Proud of it



Pagina Versie Datum

5 van 21 1.7 11-04-2011

2 Inleiding Dit document biedt ondersteuning aan medewerkers die betrokken worden bij een implementatietraject van een testtool. De toepassingsgebieden waarop de in dit document onderscheiden testtools worden ingezet worden beschreven in hoofdstuk 3. In hoofdstuk 4 worden de aandachtsgebieden beschreven ter voorbereiding op de implementatie van een testtool. De organisatorische opzet voor de projectgroep “Implementatie” wordt in hoofdstuk 5 beschreven. Hoofdstuk 6 beschrijft de verschillende aandachtsgebieden die van toepassing zijn zodra de testtool geïmplementeerd is. De in de hoofdstukken 4 tot en met 6 beschreven gebieden worden in hoofdstuk 7 met behulp van een tijdsbalk in een volgtijdelijkheid aangegeven. In hoofdstuk 8 is een checklist voor de implementatie toegevoegd. Hoofdstuk 9 bevat een woordenlijst met termen die regelmatig in het document gebruikt worden.

Almere © 2011

Proud of it



Pagina Versie Datum

6 van 21 1.7 11-04-2011

3 Toepassingsgebieden testtools Binnen de systeemontwikkeling wordt steeds meer aandacht besteed aan de kwaliteit van software en het terugdringen van de ontwikkelingskosten. Een van deze aandachtsgebieden is het (functioneel) testen van de software. Men wordt zich steeds bewuster van het feit dat het ontdekken en aanpassen van “onvolkomenheden” in de ontwikkelingsfase minder kosten met zich meebrengt dan wanneer deze aangepast dienen te worden in de productiefase. Om het werk van een tester in de ontwikkelingsfase te ondersteunen wordt steeds meer gebruik gemaakt van testtools. Dit document is opgezet met als uitgangspunt dat men reeds gekozen heeft om als project of organisatie een testtool te gebruiken. Dit document geeft een overzicht van de relevante aandachtsgebieden bij een implementatietraject voor een testtool. Testtools zijn al dan niet geautomatiseerde hulpmiddelen die ondersteuning verlenen tijdens het testtraject. Deze hulpmiddelen lopen uiteen van een checklist, via macro’s tot en met volledige software-pakketten1. Zoals de definitie al aangeeft worden de testtools gebruikt gedurende het testtraject. Er is een onderverdeling te maken in: Ø Testmanagementtools: Hulpmidddelen die toegepast worden om het managen en de planning van het testtraject te ondersteunen. Hierbij kan worden gedacht aan softwarepakketten die worden toegepast om de voortgang van het testtraject te bewaken; Ø Requirementstools: Hulpmiddelen waarbij het mogelijk is om Requirement Engineering en Requirement Development processen te ondersteunen. Met een dergelijke tool zijn de requirements (wensen en eisen) vast te leggen en te bewaken. Een tester zal deze tool vooral gebruiken om de testbaarheid van de requirements te toetsen; Ø Bevindingenbeheertools: Hulpmiddelen die de testers kunnen gebruiken om bevindingen van het testobject te registreren en historie vast te leggen; Ø Testontwerptools: Hulpmiddelen die de testers kunnen gebruiken om het testontwerp (logische en eventueel fysieke testgevallen) te maken, waarmee de basis voor de testuitvoer gelegd wordt; Ø Uitvoeringstools: Hulpmiddelen waarbij de uitvoeringsfase van het testtraject wordt ondersteund. Hier zijn momenteel totale software-pakketen voor aanwezig. Met deze pakketten is het mogelijk om in de ontwikkelfase productie-like te testen. Uitvoeringstools zijn grofweg in 2 categorieën onder te verdelen: Ø Record & Playback tools: Hulpmiddelen waarbij een testscenario eenmalig wordt opgenomen en vervolgens talloze keren kan worden afgespeeld. Een Record & Playback tool wordt veelal ingezet bij regressietesten; Ø Load & Stress tools: Hulpmiddelen waarbij een (deel)systeem op performance wordt getest. Daarbij wordt gekeken naar het volume (load) en de piekbelasting (stress). In beide situaties behoort het systeem goed te blijven functioneren. Niet alleen functionele aspecten als acceptabele responsetijd worden geanalyseerd, maar vooral ook niet-functionele aspecten als geheugen- en schijfgebruik. De vier aandachtsgebieden Beheer en techniek, Dienstverlening, Communicatie Opleiding, die in hoofdstuk Fout! Verwijzingsbron niet gevonden. worden besproken, an toepassing op alle genoemde categorieën testtools. Afhankelijk van het soort testtool aspecten binnen deze aandachtsgebieden in meer of mindere mate van toepassing.

en zijn zijn De

1 De standaard pakketten zoals tekstverwerkers en spreadsheet programma’s worden niet als testtools beschouwd. Dit vanwege het feit dat deze pakketten gezien worden als de normale en standaard software binnen organisaties, en niet specifiek voor het testtraject ontwikkeld zijn. Macro’s binnen deze pakketten worden wel als testtools beschouwd.

Almere © 2011

Proud of it



Pagina Versie Datum

7 van 21 1.7 11-04-2011

beslissing of een aspect relevant is, ligt bij de persoon of projectgroep welke uiteindelijk verantwoordelijk is voor de implementatie.

Almere © 2011

Proud of it



Pagina Versie Datum

8 van 21 1.7 11-04-2011

4 Voorbereiden van het implementatietraject In dit hoofdstuk worden de aandachtspunten beschreven die van belang zijn voordat de daadwerkelijke implementatie van de testtool plaatsvindt. Tijdens de implementatie moet aandacht worden besteed aan de randvoorwaarden om de testtool te implementeren. De testtool zal eisen stellen aan de omgeving waarin deze opereert en het beheer daarvan wordt in hoofdstuk 4.2 behandeld. De implementatie is niet afgerond voordat een terugvalbasis voor de gebruiker is gecreëerd waar deze met vragen terecht kan. Te denken valt aan een interne helpdesk of servicecenter, maar ook een servicecenter van de leverancier. Dit wordt behandeld in paragraaf 4.3 ’Dienstverlening’. Het succes van een implementatie is voor een groot deel afhankelijk van de communicatie, het creëren van draagvlak is daarin een belangrijke factor. Hierover meer in paragraaf 4.4 ‘Communicatie’ Voor het goed leren omgaan met de testtool is het van belang dat de gebruikers worden opgeleid om goed met de tool om te gaan. Hier wordt in de laatste paragraaf 4.5 op ingegaan.

4.1 Randvoorwaarden voor implementatie Voordat een organisatie een testtool gaat implementeren moet aan een aantal randvoorwaarden worden voldaan. Met de Sysqa Quick scan testtools kan worden vastgesteld of de organisatie aan de belangrijkste randvoorwaarden voldoet om testtools succesvol te implementeren en in te zetten.

4.2 Beheer en techniek Voor de implementatie van een testtool is expliciet aandacht nodig voor de wensen en eisen die de testtool stelt aan zijn omgeving. Hierbij kan de omgeving onderverdeeld worden in een: Ø Technische omgeving: de omgeving waarin de testtool moet functioneren; Ø Productieomgeving: de wijze waarop op beheerniveau met de testtool wordt omgesprongen.

4.2.1 Technische omgeving Voor de technische omgeving kan de volgende onderverdeling naar wensen en eisen worden gemaakt: Ø Hardware (inclusief het netwerk); Ø Software, zoals platform, gerelateerde software; Ø Databases; Ø Back-up en recovery; Ø Procedures technisch beheer. Hardware (inclusief het netwerk) Testtools stellen, evenals ieder ander softwarepakket, configuratie-eisen om de installatie technisch gezien haalbaar te maken. Voldoet de hardware niet aan deze eisen dan zal de installatie niet verricht kunnen worden. Het is noodzakelijk om nog voor de implementatie na te gaan of de testtool op de beschikbare hardware zal kunnen functioneren. Software De testtool dient te kunnen draaien met aanwezige besturingssoftware. Ook hierbij is het noodzakelijk dat dit gecontroleerd wordt voordat de testtool geïnstalleerd zal gaan worden.

Almere © 2011

Proud of it



Pagina Versie Datum

9 van 21 1.7 11-04-2011

Databases De meeste testtools maken gebruik van databases om hun gegevens in op te slaan. Nog voordat de implementatie van de testtool plaatsvindt zullen maatregelen op het gebied van het beheer van de databases geregeld moeten zijn. Back-up en recovery Het is noodzakelijk dat er back-up- en recovery-voorschriften aanwezig zijn om te voorkomen dat gegevens bij eventuele calamiteiten verloren gaan. Procedures technisch beheer Procedures voor het implementeren alsmede het technische beheer van de testtool moeten in lijn met de bij de gebruikersorganisatie aanwezige technische procedures worden opgezet en worden gevolgd.

4.2.2 Productieomgeving De beheeraspecten die in de productieomgeving naar voren komen, zijn gerelateerd aan het beheer van de testtool zelf. Het beheer van de testtool wordt belegd bij een toepassingsbeheerder, een beheerder die verantwoordelijk is voor het beheer van de testtool. Eenmaal operationeel vormen testtools kritische schakels in het testtraject. Daarom is het noodzakelijk dat invulling gegeven wordt aan het beheer van de testtool voor de volgende onderwerpen: Ø Licentiebeheer; Ø Versiebeheer; Ø Ontwerp inrichting van de testtool; Ø Autorisatie; Ø Gebruikersdocumentatie; Ø Procedures voor het gebruik; Ø Incidentmanagement. Licentiebeheer Vastlegging van waar en wanneer de inzet van de testtool mogelijk en geoorloofd is zal geregeld en bewaakt moeten worden. Behalve voor het interne overzicht, is het doel hiervan om gemaakte afspraken ten opzichte van de testtool leverancier te bewaken. Er zijn verschillende type licenties: · named user: op basis van user/werkplek · concurrent users: op basis van aantal gelijktijdige gebruikers Versiebeheer De testtool zal naar aanleiding van productevaluaties worden aangepast en verbeterd. De registratie van wanneer welke versie is ingezet en wat de specifieke verschillen met de vorige versie zijn, is van groot belang. Naast het inzicht dat wordt verschaft in de ontwikkeling van het product, kan met deze registratie achterhaald worden met welke versie van de testtool de testresultaten zijn behaald. Naast een goede registratie van het versiebeheer, is een actief versiebeleid binnen de organisatie noodzakelijk. De organisatie zal bij het beschikbaar komen van een nieuwe versie van de testtool moeten besluiten wanneer deze binnen de organisatie geïnstalleerd en gebruikt gaat worden. Aandachtspunt daarbij is dat oudere versies van de testtool op termijn niet meer zullen worden ondersteund door de leverancier. Indien binnen de organisatie gebruik wordt gemaakt van CMDB of helpdesktools, dan zijn die geschikt om het versiebeheer in uit te voeren.

Almere © 2011

Proud of it



Pagina Versie Datum

10 van 21 1.7 11-04-2011

Ontwerp inrichting van de testtool De omgeving waarin de testtool wordt ingezet vraagt om een specifieke inrichting van de tool. Deze inrichting moet aansluiten bij de eigenschappen van de technische omgeving. Verder kunnen de opzet van de (test)organisatie, de standaardprocessen in de organisatie en de ingezette testmethodiek onderwerpen zijn die van invloed zijn op de inrichting van de testtool. Autorisatie Testtools op de juiste manier inzetten betekent tevens dat de gebruikers van de testtool geïdentificeerd moeten worden. Daarnaast dienen de gebruikers ook te worden ingedeeld in een gebruikersgroep. Per groep kunnen dan de autorisaties met betrekking tot de testtool geregeld worden. Iedere gebruiker zal dan alleen toegang krijgen tot de delen van de testtool die nodig zijn voor het optimaal uitvoeren van zijn of haar taak. Gebruikersdocumentatie Duidelijke documentatie is belangrijk om de testtools optimaal te kunnen gebruiken. Hierbij dient bewaakt te worden dat de documentatie is afgestemd op het actuele gebruik. Denk hierbij onder andere aan de dynamiek van de testprocessen en de actuele versie van de testtool. Procedures voor het gebruik Het gebruik van een testtool betekent een verandering van, of aanvulling op de werkwijze. Naast het optimaal toegankelijk maken van de nieuwe werkwijze in de vorm van gebruikersdocumentatie, dienen ook strak omlijnde gebruikersprocedures te worden opgezet. Met formele procedures wordt de werkwijze strikt en niet-vrijblijvend opgezet om het gebruik organisatiebreed en eenduidig door te voeren. Om dit te kunnen realiseren moet het testproces reeds gestructureerd zijn. Het is niet de bedoeling om de testtool te gebruiken om het testen te structureren. Incidentmanagement Binnen het versiebeheer is er aandacht voor de specifieke kenmerken van de testtool binnen elke versie. Incidentmanagement dient ervoor om de bevindingen van de gebruikers binnen de eigen organisatie met betrekking tot de testtool te registreren en te bewaken. Op basis hiervan kan op een effectieve manier met de testtool leverancier worden gecommuniceerd om incidenten opgelost te krijgen. Het incidentmanagement kan tevens input leveren voor de evaluatie van de testtool. Hierbij dient het pakket van eisen en afspraken, op basis waarvan de testtool is geselecteerd, als referentiekader. Ook hiermee kan terugkoppeling richting de leverancier plaatsvinden. Hierbij zal het voornamelijk gaan of afgesproken dan wel gewekte verwachtingen daadwerkelijk gerealiseerd zijn.

4.3 Dienstverlening Zodra de testtool geselecteerd en aangeschaft is, is de relatie met de leverancier niet ten einde. Eigenlijk begint de samenwerking dan pas. Zoals reeds in de vorige paragraaf is aangegeven, is het noodzakelijk bevindingen (incidenten) terug te koppelen met de leverancier. In deze paragraaf wordt dieper ingegaan op de rol die de leverancier heeft in het dienstverleningsproces. De dienstverlening kan worden onderverdeeld in drie categorieën: Ø Eerstelijns dienstverlening; Ø Tweedelijns dienstverlening; Ø Derdelijns dienstverlening.

Almere © 2011

Proud of it



Pagina Versie Datum

11 van 21 1.7 11-04-2011

Onderstaande is een vorm waarin de dienstverlening kan worden vormgegeven, er zijn ook andere vormen mogelijk waarbij bijvoorbeeld de superuser de eerstelijns servicedesk invult en een helpdesk de tweedelijns verzorgt. Dit bepaalt iedere organisatie voor zichzelf.

4.3.1 Eerstelijns dienstverlening De eerstelijns dienstverlening is de dienstverlening binnen het project waarin de testtool gebruikt wordt. Wanneer een gebruiker met een vraag zit, legt hij deze in eerste instantie voor aan de medegebruikers van de testtool. Het kan best zijn dat deze het antwoord op de vraag weten. Mocht binnen de organisatie een Intranet bestaan, dan kan hierop een kennispagina worden ingericht. Op zo’n kennispagina komen dan antwoorden op regelmatig gestelde vragen (FAQs: Frequently Asked Questions) te staan.

4.3.2 Tweedelijns dienstverlening Tweedelijns dienstverlening wordt geleverd door een ‘super-user’. Een super-user is een gebruiker van de testtool, welke meer kennis van en ervaring met de testtool heeft dan een gemiddelde gebruiker. Heeft een gebruiker een vraag, en levert de Eerstelijns dienstverlening geen uitkomst, dan kan een super-user benaderd worden. De super-user zal in eerste instantie nagaan of het probleem eerder voorgekomen is. Hierbij kan hij gebruik maken van het incidentmanagement. Mocht dit niet het geval zijn, dan zal de super-user nagaan wat de oorzaak van het probleem is. Wanneer blijkt dat een probleem zich vaker voordoet, dan kan hij besluiten de vraag met het bijbehorende antwoord te laten plaatsen op het Intranet. Dit gebeurt via het op de hoogte te brengen van de toepassingsbeheerder, de persoon welke verantwoordelijk is voor de testtool. Als ook hij geen antwoord op het probleem weet, zal hij dit doorgeven aan de leverancier. Dit resulteert in de derdelijns dienstverlening.

4.3.3 Derdelijns dienstverlening Bij deze graad van dienstverlening komt de leverancier weer in beeld. Vragen die niet beantwoord kunnen worden door de organisatie dienen aan de leverancier te worden voorgelegd. Om te voorkomen dat een ieder de leverancier zal benaderen (of desnoods een helpdesk van de leverancier) zal deze communicatie plaatsvinden via de toepassingsbeheerder. Dit om te voorkomen dat de leverancier continu wordt belast met vragen waarop het antwoord reeds binnen de organisatie bekend is. In het geval van een medium zoals het Intranet binnen de organisatie, zal ook de toepassingsbeheerder de aangewezen persoon zijn om dit te bewaken. Te meer om te voorkomen dat alles op het Intranet komt. Het is natuurlijk zaak dat alleen de meest voorkomende en urgente vragen via dit medium beantwoord worden. De keuzes ten aanzien van de inrichting van de interne dienstverlening zijn afhankelijk van de grootte van de organisatie. Het is echter van belang te weten wie de aanspreekpunten zijn, en wat de kennis en kunde van deze personen zijn.

4.4 Communicatie Om te komen tot een succesvolle implementatie van een testtool in een organisatie zal voor iedereen binnen deze organisatie duidelijk moeten zijn wat de voordelen van de testtool zijn. Hiervoor moet men de betrokken partijen goed informeren over het gebruik en de voordelen van de testtool.

Almere © 2011

Proud of it



Pagina Versie Datum

12 van 21 1.7 11-04-2011

In de voorbereidingsfase zal men zich moeten richten op het creëren van draagvlak in de organisatie. Als de beslissing voor het inzetten van een testtool genomen is, is het belangrijk om in de juiste communicatievorm de juiste doelgroepen met doeltreffende informatie te bereiken.

4.4.1 Communicatievormen De beslissing tot het implementeren van een testtool en het implementatieplan kunnen op diverse wijzen bekend worden gemaakt binnen de organisatie. Welke communicatievorm hiervoor gebruikt moet worden is afhankelijk van wie, wat, waar, wanneer en hoe er geïnformeerd dient te worden. Binnen de diverse organisatie behoren onder andere tot de mogelijkheden: Ø Direct mail of presentaties voor een gedefinieerde doelgroep. Ø Bedrijfsbrede distributiekanalen (zoals bedrijfsbladen en Intranet) zodat de gehele organisatie hiermee bereikt wordt.

4.4.2 Doelgroepen Op twee manieren kan het begrip doelgroep beschouwd worden: Ø Onderscheid naar projecten; Ø Onderscheid naar gebruikersgroepen: Onderscheid naar projecten Dit is relevant als verschillende projecten betrokken zijn bij de implementatie van de testtool. Ieder project kan daarbij door zijn specifieke eigenschappen andere informatiewensen t.a.v. de testtool hebben. Onderscheid naar gebruikersgroepen Ø Projectmanagers: Een projectmanager is geïnteresseerd in het versnellen en verbeteren van het testproces. Daarnaast zal de projectmanager willen weten hoe de testtool kan voorzien in zijn behoefte aan meet- en stuurinformatie. Het implementatieteam zal uiteraard de mogelijkheden die de testtool biedt in deze richtingen moeten benadrukken. Ø Testers: Testers vormen de voornaamste groep die daadwerkelijk met de testtool zullen moeten werken. Het succes van een testtool valt of staat met de acceptatie van de testers van de testtool. Benadruk bij hen vooral het gemak van werken en de uitgebreide functionaliteit van de testtool. Dit vooral ook in vergelijking met de situatie waarbij deze testtool nog niet beschikbaar was. Ø Bouwers: Mogelijk zal de testtool ook door bouwers gebruikt worden, of anders zullen de bouwers in ieder geval geconfronteerd worden met een veranderende werkwijze van de testers. Dus ook de bouwers zijn een doelgroep die doeltreffend geïnformeerd dient te worden. De relevante doelgroepen zullen dus eerst geïdentificeerd moeten worden en per doelgroep zal er een communicatiestrategie ontwikkeld moeten worden om de testtool zo goed mogelijk te implementeren. Voor de bewaking van de uitvoering van deze strategie wordt bijvoorbeeld in een logboek bijgehouden welke doelgroepen benaderd zijn en welke vervolgafspraken er gemaakt zijn.

4.4.3 Doeltreffende informatie Allereerst moet duidelijk zijn wat voor de gekozen testtools de verbeteringsmogelijkheden en de voordelen zijn en voor wie deze voordelen van belang kunnen zijn. Om te beoordelen welke informatie in welke situatie relevant is kan men een gebruikersprofiel opstellen. Met behulp van het gebruikersprofiel kan worden bepaald welke informatie relevant is voor een gebruikersgroep (zie paragraaf 3.4.2).

Almere © 2011

Proud of it



Pagina Versie Datum

13 van 21 1.7 11-04-2011

De benodigde informatie kan volgens een opgesteld communicatieplan bij de betreffende gebruikersgroepen of projecten worden bekend gemaakt. Een communicatieplan geeft het verloop van alle geplande communicatiemomenten en -punten in het invoeringstraject aan.

4.5 Opleiding De implementatie van een testtool heeft als doel dat medewerkers met de testtool aan het werk gaan. Om de acceptatie van de testtool te bevorderen is het noodzakelijk dat de verschillende medewerkers bekend raken met de testtool en weten wat de testtool kan. Het is daarom noodzakelijk dat alle medewerkers in het begin een introductie van de testtool krijgen. De beste manier is om de medewerkers zelf met de testtool te laten werken. Een basisopleiding is hiervoor een uitstekende methode. In de meeste gevallen zal een leverancier van een testtool in staat zijn om een basisopleiding te geven. Doordat het gedurende een basisopleiding mogelijk is om zelf het een en ander uit te proberen, zal men ook eerder met vragen naar voren komen wanneer men tegen problemen aanloopt. Mocht de situatie zich voordoen dat verschillende medewerkers meer dan gemiddelde kennis van de testtool moeten hebben, dan dient er een vervolgcursus gevolgd te worden. Ook hierbij zal de leverancier van dienst kunnen zijn. Een onderdeel van het implementatieplan is daardoor vaak een opleidingsplan, in dit plan wordt aangegeven welke gebruikersgroepen of gebruikers welk type opleiding moeten volgen om het gebruik van de testtool te optimaliseren. Het opleiden van gebruikers is tevens op te nemen in het communicatieplan. Het verzorgen van opleidingen is naar de rest van de organisatie een signaal dat er serieus aandacht aan wordt besteed.

Almere © 2011

Proud of it



Pagina Versie Datum

14 van 21 1.7 11-04-2011

5 Organisatie van het implementatietraject Om de implementatie succesvol te maken is het noodzakelijk om hiervoor een implementatieproject in te richten. Onderstaand model geeft schematisch weer hoe zo’n project er uit zou kunnen zien.

Opdrachtnemer

Teamleden

Gebruikersorganisat ie

Referentiekader

Opdrachtgever

Binnen dit model heeft elke discipline zijn eigen taken en verantwoordelijkheden. Deze worden onderstaand beschreven. Opdrachtgever De opdrachtgever is de persoon binnen de organisatie die de implementatie van de testtool heeft geïnitieerd. Hij is tevens de persoon die er voor dient te zorgen dat er budget en capaciteit beschikbaar komt om de testtool te implementeren. Opdrachtnemer De opdrachtnemer is de eindverantwoordelijke welke belast is met de uitvoering van het implementatietraject. Hij zorgt ervoor dat de projectorganisatie wordt ingericht. Bij de inrichting dient gedacht te worden aan aspecten zoals het aantrekken van teamleden en het coördineren van hun activiteiten, het creëren van draagvlak binnen de organisatie en het ondersteunen van de teamleden. Daarnaast zal de opdrachtnemer de gebruikersorganisatie raadplegen en de resultaten afspiegelen aan het referentiekader. Tevens zal de opdrachtnemer de voortgang rapporteren aan de opdrachtgever en is hij verantwoordelijk voor de kostenbewaking van het project. Teamleden De teamleden zorgen voor het uitvoeren van de activiteiten om de implementatie mogelijk te maken. Van de teamleden wordt verwacht dat zij hun vorderingen aan de opdrachtnemer doorgeven zodat deze de voortgang van de implementatie in de hand heeft. Referentiekader Het referentiekader is het voorbeeld waaraan men eigenlijk de gehele implementatie wil afspiegelen. Voorbeelden van een referentiekader zijn bijvoorbeeld de documenten die tot de beslissing van de aangeschafte testtool hebben geleid, het document ‘Vragen keuze testtools’. Door regelmatig de realiteit met het referentiekader te vergelijken kan men bepalen waar de implementatie zich bevindt. Dit is noodzakelijk om op een vroeg tijdstip te kunnen signaleren of het beeld wat in het begin geschetst is, nu nog haalbaar is.

Almere © 2011

Proud of it



Pagina Versie Datum

15 van 21 1.7 11-04-2011

Gebruikersorganisatie De gebruikersorganisatie wordt gevormd door de personen uit de organisatie die uiteindelijk met de testtool dienen te gaan werken. Door deze personen tijdig, tijdens het uitvoeren van de requirementsanalyse door middel van het document ‘Vragen keuze testtools’, bij de implementatie te betrekken, worden in een vroeg stadium hun wensen gehoord. Dit bevordert de acceptatie van de testtool vanuit gebruikersoogpunt. Hun taak is dus eigenlijk het voorzien van de teamleden van de gewenste informatie zodat de teamleden hun activiteiten kunnen uitvoeren.

Almere © 2011

Proud of it



Pagina Versie Datum

16 van 21 1.7 11-04-2011

6 Nazorg van het implementatietraject Wanneer de testtool binnen de organisatie geïmplementeerd is, is het noodzakelijk dat de organisatie ook daadwerkelijk de testtool gaat gebruiken en blijft gebruiken. Men moet ervoor zorgen dat de betrokken personen bereid blijven om de testtool te gebruiken. Dezelfde aandachtsgebieden als in de voorbereidingsfase dienen daarom beschouwd te worden, hoewel de aspecten nu op een ander vlak liggen.

6.1 Beheer en techniek In de nazorgfase van de implementatie ligt het accent van dit aandachtsgebied op het gebruik van de testtool. Er dienen maatregelen met betrekking tot het gebruik van de testtool genomen te worden om het (juiste) gebruik van de testtool te realiseren. Hierbij dienen de onderstaande aspecten meegenomen te worden: Ø Evaluatie van het toolgebruik; Ø Veranderende omgeving. Evaluatie van het toolgebruik In de praktijk blijkt vaak dat het gebruik van een testtool zich binnen een testorganisatie ontwikkelt als een specialisme. Om grip te kunnen krijgen op de vaardigheden is het verkrijgen van ervaringscijfers essentieel. Daarnaast is het voor de continuïteit na een implementatie noodzakelijk dat kennis en kunde met betrekking tot de testtool breed gedragen worden binnen een testorganisatie. Tevens moet aandacht worden besteed aan de overdraagbaarheid van deze kennis en kunde. Het ingerichte incidentmanagement binnen de organisatie kan voor de benodigde input zorgen (zie paragraaf 4.2.2). Veranderende omgeving Ingebruikname van testtools zal effect hebben op de organisatie, het ontwikkelproces en het testtraject. De omgeving waarin de testtool wordt gebruikt blijft zich ook ontwikkelen. Deze ontwikkeling kan zich vertalen in het toepassen van andere technieken of componenten. Zaak hierbij is dat deze ontwikkelingen worden erkend en vastgelegd. Hierbij is het van belang om te controleren of de testtool hierdoor nog steeds optimaal ingezet kan worden.

6.2 Dienstverlening Zodra de testtool geïmplementeerd is, zal het in een onderhoudsfase komen. Via de leverancier zullen nieuwe releases van de testtool aan de organisatie worden aangeboden. Hierbij is het noodzakelijk dat er wordt vastgesteld of de nieuwe release toegevoegde waarde heeft voor de organisatie. Daarnaast is het ook van belang dat er wordt gekeken op welke manier de nieuwe release geïmplementeerd gaat worden. Een ander punt waarbij de leverancier een grote rol speelt is de opleiding van de toekomstige gebruikers, en “bijscholing” van de huidige gebruikers. De leverancier levert niet alleen de testtool, maar beschikt meestal ook over een gedegen cursus om te leren omgaan met de testtool. In eerste instantie zal een beperkte groep gebruikers deze opleiding volgen nog voordat de testtool binnen de organisatie wordt geïmplementeerd. Echter zodra men zal gaan werken met de testtool, zal de gehele groep medewerkers opgeleid moeten worden. Hierbij kan gebruik worden gemaakt van de expertise van de leverancier, maar wellicht ook van superusers, toepassingsbeheerders of andere ervaren gebruikers om de kosten van de opleiding te beperken.

Almere © 2011

Proud of it



Pagina Versie Datum

17 van 21 1.7 11-04-2011

6.3 Communicatie Verwachtingen en eisen van de gebruikers van de testtool zullen na implementatie in de tijd veranderen. Dit betekent dat de toepassingsbeheerder van het product geregeld zal moeten onderzoeken hoe de testtool ervaren wordt binnen de organisatie en hij zal daaruit zijn conclusies moeten trekken over het bestaansrecht van de testtool: moet er uitbreiding of vervanging van de testtool plaatsvinden?

6.3.1 Kennismanagement Na de initiële implementatie wordt het gebruik van de testtool veelal opgenomen binnen de taken van een beheerorganisatie. Deze is gericht op het beschikbaar stellen van het product en alle verdere informatie die voor een gebruiker interessant kan zijn. De opgebouwde kennis binnen het project moet daarom worden overgedragen aan de beheerorganisatie om er voor te zorgen dat de opgebouwde kennis niet verloren gaat.

6.3.2 Life-cyclemanagement Om als (beheer)organisatie feeling te houden met de gebruikers van het testtool over het functioneren van de tool dient regelmatig geëvalueerd te worden of de testtool nog voldoet. Een zogenaamd Klant Tevredenheids Onderzoek (KTO) is hiervoor een uitgelezen methode. Met een KTO wordt gemeten in welke fase van de levenscyclus de testtool zich bevindt en wat de voor- en nadelen van het gebruik zijn. Op basis van de resultaten van een KTO kan bijvoorbeeld besloten worden om de testtool functioneel uit te breiden (aanschaffen van add-ons of een aansluitend testtool),te vervangen door een andere testtool, of te besluiten om voorlopig niets te doen. Al in de implementatiefase kan een plan ontwikkeld worden voor het houden van een KTO. Er zal gedefinieerd moeten worden welke meetcriteria noodzakelijk zijn om de levensfase van de testtool te kunnen bepalen. Daarnaast is het noodzakelijk om op voorhand vast te stellen welke actie er ondernomen dient te worden als de testtool zich in een bepaald stadium van de levenscyclus bevindt. Het resultaat van een KTO moet informatie geven over de “volwassenheid” van de testtool zodat er, indien noodzakelijk, actie ondernomen kan worden.

6.4 Opleiding Nadat de testtool is geïmplementeerd is het noodzakelijk dat ook het opleidingstraject in stand wordt gehouden. Nieuwe medewerkers dienen een basisopleiding te krijgen. Huidige medewerkers zouden een vervolgopleiding kunnen volgen. Ook dient er rekening te worden gehouden met aanpassingen in de testtool als gevolg van een nieuwe versie. Daarnaast kan de algemene opleiding van de leverancier worden omgezet in een organisatie-specifieke opleiding. Het voordeel hierbij is dat de opleiding zich alleen toelegt op de toepassing van de testtool binnen de organisatie. Daarnaast kan procedureel beter vastgelegd worden op welke methode de testtool binnen de organisatie wordt toegepast. Tevens leidt dit tot een uniform gebruik van de testtool.

Almere © 2011

Proud of it



Pagina Versie Datum

18 van 21 1.7 11-04-2011

7 Tijdsbalk voor het implementatietraject Wanneer de testtool binnen de organisatie geïmplementeerd is, is het noodzakelijk dat de organisatie ook daadwerkelijk de testtool gaat gebruiken en blijft gebruiken. Men moet ervoor zorgen dat de betrokken personen bereid blijven om de testtool te gebruiken. Dezelfde aandachtsgebieden als in de voorbereidingsfase dienen daarom beschouwd te worden, hoewel de aspecten nu op een ander vlak liggen.

7.1 Gebruik tijdsbalk De tijdsbalk die in dit hoofdstuk wordt beschreven is een belangrijk hulpmiddel voor het succesvol implementeren van een testtool. Op een betrekkelijke eenvoudige wijze geeft deze tijdsbalk de volgorde aan waarin de gedefinieerde activiteiten uitgevoerd dienen te worden voor een doeltreffende en doelmatige implementatie. Door de variatie in soorten testtools is een implementatie niet in een bepaald vast tijdsbestek te plannen. In deze tijdsbalk geven we om deze reden alleen de volgtijdelijkheid aan. In de tijdsbalk wordt het implementatietraject in vijf fasen verdeeld: Ø Initiatiefase; Ø Voorbereiding; Ø Implementatie; Ø Beheer van het gebruik; Ø Nazorg van de implementatie. In de volgende paragraaf worden bij de verschillende fasen ook de mijlpalen benoemd. De mijlpalen lopen uiteen van producten tot vaststelling van specifieke stakeholders.

7.2 Initiatiefase Aandachtsgebied Organisatie

Mijlpaal Opdrachtgever bekend

Opdrachtnemer bekend Beheer en techniek Hardware configuratie eisen Besturingssoftware

7.3 Voorbereiding Aandachtsgebied Organisatie

Mijlpaal Teamleden bekend Inrichten derdelijns dienstverlening

Communicatie Informeren betrokken partijen

Beheer en techniek Gedocumenteerde procedures implementatie Integratie technisch beheer met de bestaande technische procedures Inrichten back-up en recovery procedures Inrichten database Opstellen gebruikersdocumentatie Opstellen gebruiksprocedures Opleiding Opleidingsplan uitgewerkt

Almere © 2011

Proud of it



Pagina Versie Datum

19 van 21 1.7 11-04-2011

7.4 Implementatie Aandachtsgebied Organisatie

Mijlpaal Inrichten tweedelijns dienstverlening Inrichten Eerstelijns dienstverlening

Communicatie Kennismanagement

Beheer en techniek Licentie en versiebeheer Inrichten van de testtool Autorisaties Incidentenmanagement Opleiding Opleidingsplan uitvoeren

7.5 Beheer van het gebruik Aandachtsgebied Beheer en techniek

Mijlpaal Continueren licentie- en versiebeheer Continueren incidentenmanagement Continueren gebruikersdocumentatie

7.6 Nazorg van de implementatie Aandachtsgebied Beheer en techniek

Mijlpaal Evaluatie van toolgebruik

Communicatie Life-cycle management Opleiding Opleidingsplan generiek maken

Almere © 2011

Proud of it



Pagina Versie Datum

20 van 21 1.7 11-04-2011

8 Checklist voor het implementatietraject 8.1 Gebruik checklist Deze checklist is een belangrijk hulpmiddel voor het succesvol implementeren van een testtool. Op een betrekkelijke eenvoudige wijze geeft deze checklist een overzicht van de noodzakelijke aandachtsgebieden voor een doeltreffende en doelmatige implementatie. De checklist is niet chronologisch opgezet. Door de variatie in soorten testtools zullen niet alle onderdelen van de checklist relevant zijn voor iedere testtool. Als in een specifieke situatie een aandachtsgebied niet relevant is, vul dan ‘niet van toepassing’ in.

8.2 Beheer en techniek ter voorbereiding van de implementatie Hardware Software Databases

Databases Back-up en recovery Technisch beheer Integratie technisch beheer Licentieversiebeheer Inrichting van testtool

en de

Incidentenmanagement

Voldoet de hardware aan de configuratie-eisen t.b.v. de installatie van de testtool op het moment van de implementatie? Kan de testtool draaien met de beschikbare besturingssoftware op het moment van de implementatie? Is er een database ingericht waarmee alle noodzakelijke gegevens ter beschikking staan die noodzakelijk zijn om de testtool te laten functioneren? Is er een database ingericht waarin de gegevens kunnen worden opgeslagen die gegenereerd worden door de testtool? Zijn er back-up- en recovery procedures opgesteld op het moment van implementatie? Zijn er gedocumenteerde procedures voor de implementatie en het technisch beheer van de testtool? Zijn de procedures voor de implementatie en het technisch beheer van de testtool geïntegreerd met de bestaande technische procedures? Worden vanaf de start van de implementatie de installaties en de updates van de tools geregistreerd en bewaakt? Wordt vanaf de start van de implementatie de inrichting vastgelegd die noodzakelijk is om de tool operationeel in te zetten? Worden vanaf de start van de implementatie de bevindingen met betrekking tot de tools geregistreerd en bewaakt?

8.3 Beheer en techniek na de initiële implementatie Autorisatie

Zijn voor iedere gebruiker de autorisaties bepaald en doorgevoerd? GebruikersIs duidelijke gebruikersdocumentatie opgesteld, beschikbaar documentatie voor de gebruikers en wordt deze actueel gehouden? Gebruiksprocedures Zijn er binnen de totale testwerkwijze procedures met betrekking tot de testtool opgenomen? Evaluatie Wordt het gebruik van de testtools geëvalueerd?

8.4 Organisatie Eerstelijns dienstverlening Tweedelijns dienstverlening

Is de eerstelijns dienstverlening ingericht? (medegebruikers, algemeen beschikbare media) Is de tweedelijns dienstverlening ingericht? (gecentraliseerde gebruikers kennis)

Almere © 2011

Proud of it



Derdelijns dienstverlening Opdrachtgever Opdrachtnemer Teamleden

Pagina Versie Datum

21 van 21 1.7 11-04-2011

Is de derdelijns dienstverlening ingericht? (leverancier, producent) Is de opdrachtgever met de gestelde wensen en eisen bekend? Zijn voor de opdrachtnemer de (eind)verantwoordelijkheden bekend? Zijn voor de teamleden de uit te voeren activiteiten bekend?

8.5 Communicatie Informeren betrokken partijen Kennismanagement Life-cycle management

Worden de verschillende groepen betrokkenen onderscheiden? Wordt per groep doelgerichte informatie ter beschikking gesteld? Is er voldoende kennisoverdracht om de implementatie van de testtool te continueren? Wordt na implementatie het gebruik van de testtool gemeten?

8.6 Opleiding Opleidingsplan Leverancier

Is er binnen de organisatie een opleidingsplan aanwezig voor het gebruik van de testtool? Is de leverancier in staat om opleidingen te geven welke zijn onderkend in het opleidingsplan?

Almere © 2011

Proud of it

Implementatieplan ten behoeve van een testtool

Recommend Documents