Implementatieplan van een testtool. Een aanpak. Algemene informatie voor medewerkers van SYSQA B.V

Implementatieplan van een testtool Een aanpak

Algemene informatie voor medewerkers van SYSQA B.V.

Organisatie Titel Onderwerp

SYSQA BV Implementatieplan Implementatieplan testtool

Pagina Versie Datum

1 van 19 1.0 27 juni 2006

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 welke reeds aan het begin van de implementatie voorzien hadden kunnen worden. Het is dus zaak dat nog voor de daadwerkelijke implementatie het merendeel van de problemen zijn onderkend en aangepakt. Wanneer er wordt gekeken naar de aandachtsgebieden welke 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 het testtool stelt aan de systeemomgeving waarbinnen het wordt toegepast. Men dient er voor te waken dat men geen testtool aanschaft dat niet binnen de systeem omgeving kan functioneren. Daarnaast gelden vanuit de organisatie eisen op welke met hode het testtool zal worden toegepast. Het aandachtsgebied Dienstverlening richt zich met name op de wijze waarop de gebruikersondersteuning binnen de organisatie is geregeld. Welke personen te benaderen zijn voor vragen omtrent de werking van het testtool en voor het oplossen van technische problemen. De rol van de leverancier is hierbij niet onbelangrijk. Aspecten welke naar voren komen om de implementatie van het testtool binnen de organisatie kenbaar te maken worden binnen het aandachtsgebied Communicatie aangehaald. Het is natuurlijk van belang dat zodra men de beslissing heeft genomen om een testtool te gaan implementeren, het kenbaar te maken binnen de organisatie. Hiervoor zijn verschillende methoden mogelijk om de juiste personen op de juiste manier te benaderen. Opleiding slaat met name op de aspecten waarbij moet worden gedacht dat de personen die met het testtool gaan werken hiervoor voldoende basiskennis meekrijgen. Daarnaast kan gekozen worden voor een meer uitgebreide opleiding voor een beperkte groep personen welke een rol zullen gaan spelen bij de dienstverlening binnen de organisatie. Ook hierbij kan de leverancier een belangrijke rol vertegenwoordigen. De verschillende aandachtsgebieden hebben een aantal aspecten welke tijdsvolgordelijk afhankelijk van elkaar zijn. Het is daarom ook van belang om van te voren te bepalen welke aspecten van toepassing zijn binnen een organisatie. Wanneer dit bekend is kan men aan de gang om de verschillende aspecten te gaan regelen. Het blijkt namelijk dat wanneer men de zaken van te voren goed heeft geregeld er na de implementatie niet of nauwelijks problemen zijn en dat men slechts een beperkt aantal aspecten nog hoeft te regelen. Deze aspecten hebben dan niet zozeer betrekking op het functioneren va n het testtool, maar meer op het actueel houden van het testtool. Het implementeren van een testtool is niet alleen het installeren van de verkregen software en het distribueren van de bijgeleverde handboeken. Wil men uiteindelijk een succesvolle implementatie van het testtool dan komt daarbij nog het een en ander om de hoek kijken. Hierbij is ook van belang in hoeverre de organisatie het belang in schat van de verschillende aspecten.

Almere © 2003

Quality Assurance in ICT



Pagina Versie Datum

2 van 19 1.0 27 juni 2006

Inhoudsopgave MANAGEMENTSAMENVATTING ................................................................................................. 1 1

INLEIDING............................................................................................................................. 3 1.1

INDELING ....................................................................................................................... 3

2

AFBAKENING VAN HET TOEPASSINGSGEBIED .................................................................. 4

3

VOORBEREIDEN VAN HET IMPLEMENTATIETRAJECT ....................................................... 5 3.1 3.1.1 3.1.2 3.1.3 3.2 3.2.1 3.2.2 3.3 3.3.1 3.3.2 3.3.3 3.4 3.4.1 3.4.2 3.4.3 3.5

RANDVOORWAARDEN VOOR IMPLEMENTATIE ........................................................................ 5 Stabiele testorganisatie ............................................................................................. 5 Stabiel testobject....................................................................................................... 5 Duidelijke normen en standaards ............................................................................... 5 BEHEER EN TECHNIEK ...................................................................................................... 5 Technische omgeving................................................................................................ 5 Produkt omgeving ..................................................................................................... 6 D IENSTVERLENING .......................................................................................................... 8 Eerstegraads dienstverlening..................................................................................... 8 Tweedegraads dienstverlening................................................................................... 8 Derdegraads dienstverlening ..................................................................................... 8 COMMUNICATIE ............................................................................................................... 9 Communicatievormen................................................................................................ 9 Doelgroepen ............................................................................................................. 9 Doeltreffende informatie............................................................................................. 9 OPLEIDING ....................................................................................................................10

4

ORGANISATIE VAN HET IMPLEMENTATIETRAJECT ..........................................................11

5

NAZORG VAN HET IMPLEMENTATIETRAJECT ...................................................................12 5.1 5.2 5.3 5.3.1 5.3.2 5.4

6

TIJDBALK VOOR HET IMPLEMENTATIETRAJECT ..............................................................14 6.1 6.2 6.3 6.4 6.5 6.6

7

GEBRUIK TIJDBALK .........................................................................................................14 INITIËLE VOORBEREIDING .................................................................................................14 VOORBEREIDING ............................................................................................................14 INITIËLE IMPLEMENTATIE ..................................................................................................15 BEHEER VAN HET GEBRUIK ...............................................................................................15 NAZORG VAN DE IMPLEMENTATIE ......................................................................................15

CHECKLIST VOOR HET IMPLEMENTATIETRAJECT ..........................................................16 7.1 7.2 7.3 7.4 7.5 7.6 7.7

8

BEHEER EN TECHNIEK .....................................................................................................12 D IENSTVERLENING .........................................................................................................12 COMMUNICATIE ..............................................................................................................12 Kennismanagement .................................................................................................13 Life-cyclemanagement ..............................................................................................13 OPLEIDING ....................................................................................................................13

GEBRUIK CHECKLIST .......................................................................................................16 RANDVOORWAARDEN......................................................................................................16 BEHEER EN TECHNIEK TER VOORBEREIDING VAN DE IMPLEMENTATIE .......................................16 BEHEER EN TECHNIEK NA DE INITIËLE IMPLEMENTATIE ..........................................................17 ORGANISATIE ................................................................................................................17 COMMUNICATIE ..............................................................................................................17 OPLEIDING ....................................................................................................................17

VERKLARENDE WOORDENLIJST .......................................................................................18

Almere © 2003




Pagina Versie Datum

3 van 19 1.0 27 juni 2006

1 Inleiding Dit stuk dient als ondersteuning van medewerkers die geconfronteerd worden met de implementatie van een testtool.

1.1

Indeling

Voordat dit rapport gebruikt zal worden in een implementatietraject zijn er een aantal aannamen gedaan met betrekking tot het toepassingsgebied van dit eindrapport. Deze afbakening van het toepassingsgebied wordt beschreven in hoofdstuk 2. In hoofdstuk 3 staan de aandachtsgebieden beschreven welke van toepassing zijn nog voordat de implementatie van het testtool zal plaatsvinden. Een model voor de projectgroep “Implementatie” wordt in hoofdstuk 4 beschreven, met daarbij de verschillende taken en bevoegdheden van de verschillende projectleden. Hoofdstuk 5 beschrijft de verschillende aandachtsgebieden welke van toepassing zijn zodra het testtool geïmplementeerd is. De aspecten van de hoofdstukken 3 tot en met 5 worden in hoofdstuk 6 met behulp van een tijdsbalk in een volgtijdelijkheid aangegeven. Als hoofdstuk 7 is een checklist voor de implementatie toegevoegd. Hoofstuk 8 is een woordenlijst die termen bevat die regelmatig in het eindrapport gebruikt worden.

Almere © 2003




Pagina Versie Datum

4 van 19 1.0 27 juni 2006

2 Afbakening van het toepassingsgebied 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 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 produktiefase. Om het werk van een tester in de ontwikkelingsfase te ondersteunen wordt steeds meer gebruik gemaakt van testtools. Dit eindrapport is opgezet met als uitgangspunt dat men reeds gekozen heeft om als project of organisatie een testtool te gebruiken. Het is niet de bedoeling om in dit rapport de voor- en nadelen van testtools te bediscussiëren of een specifiek testtool te selecteren. Dit rapport dient er voor om de aandachtsgebieden bij de implementatie zichtbaar te maken, om zo het implementatie traject succesvol te maken. Maar wat zijn testtools nu eigenlijk? Testtools zijn, al dan niet geautomatiseerde, hulpmiddelen welke 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. Om het scala van testtools handelbaar te maken, is een onderverdeling noodzakelijk. Gekozen is voor een onderverdeling die aansluit op de fasering van het testtraject. Concreet gezien is de onderverdeling: Ø Ø Ø Ø

Ø

Planningstools: Hulpmidddelen welke toegepast worden om de planning van het testtraject te ondersteunen. Hierbij kan worden gedacht aan software-pakketten die worden toegepast om de voortgang van het testtraject te bewaken; Voorbereidingstools: Hulpmiddelen waarbij het mogelijk is om een uitspraak te kunnen doen over de testbaarheid van de specificaties. In deze fase wordt dan vooral gebruik gemaakt van checklists; Specificatietools: Hulpmiddelen welke de testers kunnen gebruiken om het testontwerp (logische en eventueel fysieke testgevallen) te vervaardigen, waardoor de basis voor de testuitvoer gelegd wordt; Uitvoeringstools: Hulpmiddelen waarbij de uitvoeringsfase van het testtraject wordt ondersteund. Hiervoor zijn momenteel totale software-pakketen voor aanwezig. Met deze pakketen is het mogelijk om in de ontwikkelfase produktie-like te testen; Afrondingstools: Hulpmiddelen welke de testers ondersteunen om het testtraject te kunnen evalueren, rapportages op te stellen en de testware te kunnen conserveren. Ook hierbij kunnen wederom van checklists gebruik worden, om na te gaan of alle aspecten voor het afronden van het testtraject zijn verricht.

Dit eindrapport richt zich met name op de testtools welke op de markt als een standaard pakket worden aangeboden. Hierbij valt te denken aan Record & Playback software, welke als uitvoeringstool kan worden gebruikt. Management pakketten zullen daarentegen hoofdzakelijk als planningstool worden gebruikt. Daarnaast zijn er reeds pakketten welke zowel een uitvoeringstool als een afrondingstool zijn. Afhankelijk van het soort testtool zijn de aspecten welke in dit eindrapport worden aangehaald in meer of mindere mate van toepassing. De beslissing of een aspect relevant is, ligt bij de persoon welke uiteindelijk verantwoordelijk is voor de implementatie.

1 De standaard pakketen zoals tekstverwerkers en spreadsheet programma’s worden niet als testtools bes chouwd. 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 © 2003




Pagina Versie Datum

5 van 19 1.0 27 juni 2006

3 Voorbereiden van het implementatietraject In dit hoofdstuk worden de aandachtpunten beschreven welke van belang zijn, voordat de daadwerkelijke implementatie van het testtool plaatsvindt.

3.1

Randvoorwaarden voor implementatie

Voordat een organisatie een testtool gaat implementeren moet aan een aantal randvoorwaarden worden voldaan. Onderstaand zijn de meest belangrijke randvoorwaarden vermeld: Ø Stabiele testorganisatie; Ø Stabiel testobject; Ø Duidelijke normen en standaards. In de volgende paragrafen worden deze randvoorwaarden nader toegelicht. 3.1.1

Stabiele testorganisatie

Voordat een organisatie overgaat tot de invoering van een testtool dient er sprake te zijn van een stabiele en volwassen testorganisatie. Hieronder wordt een organisatie verstaan waarbij de processen ten behoeve van het testen worden beheerst. De taak van een testtool is niet het testtraject te structureren maar te ondersteunen. Wanneer blijkt dat de testorganisatie niet voldoende volwassen is, levert het toepassen van een testtool geen ondersteuning. 3.1.2

Stabiel testobject

Het te testen object moet stabiel zijn, met andere woorden: het testobject dient niet continue aan veranderingen onderhevig te zijn. Dit geldt met name voor de functionaliteit als de User-Interface van het testobject. Voor een instabiel object moet de testware elke keer weer worden gecontroleerd en zonodig aangepast. Met name voorbereidings-, specificatie- en uitvoeringstools zullen bij een instabiel testobject niet de gewenst ondersteuning geven, maar eerder leiden tot tegenwerking vanuit de organisatie. Het is dus zaak dat het testobject stabiel is om zo te controleren of aanpassingen op delen van het testobject geen nadelige gevolgen heeft voor de niet aangepaste delen. Pas dan zal het testtool de ondersteuning geven waarvoor het bedoeld is. 3.1.3

Duidelijke normen en standaards

Binnen de testorganisatie is het noodzakelijk dat er duidelijke normen en standaards zijn op het gebied van tussen- en eindprodukten. Het testtool moet de organisatie ondersteunen en niet veranderen. Deze normen en standaards gelden zowel voor produkten welke worden toegepast in het testtraject, alsmede voor de produkten welke in het testtraject worden vervaardigd. Het vastleggen van deze normen en standaards kan plaatsvinden in een testplan, testhandboek of een kwaliteitszorgsysteem. Het te implementeren testtool moet dan ook binnen deze normen en standaards te gebruiken moeten zijn.

3.2

Beheer en techniek

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

Technische omgeving

Voor de technische omgeving kan de volgende onderverdeling naar wensen en eisen worden gemaakt: Ø Hardware (inclusief het netwerk); Ø Software; Ø Databases; Ø Back-up en recovery; Ø Procedures technisch beheer.

Almere © 2003




Pagina Versie Datum

6 van 19 1.0 27 juni 2006

Hardware (inclusief het netwerk) Testtools stellen, evenals ieder ander software-pakket, 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 het testtool op de huidige hardware zal kunnen functioneren. Software Het testtool dient te kunnen draaien met aanwezige besturingssoftware. Deze combinatie is noodzakelijk om het testtool operationeel te maken. Ook hierbij is het noodzakelijk dat dit gecontroleerd wordt voordat het testtool geïnstalleerd zal gaan worden. Databases De meeste testtools maken tegenwoordig gebruik van databases om hun gegevens in op te slaan. Ten eerste zal de database gevuld moeten zijn met gegevens welke noodzakelijk zijn om hun taak te kunnen volbrengen. De gegevens zullen daarbij op de juiste momenten en de juiste plaatsen ter beschikking moeten zijn. Ten tweede genereert het gebruik van testtools gegevens welke gestructureerd opgeslagen dienen te worden. Deze aspecten bepalen op wat voor manier en hoe de databases ingericht dienen te worden om het functioneren van het testtool mogelijk te maken. Nog voordat de implementatie van het testtool plaatsvindt zullen maatregelen op het gebied van het beheer van de databases geregeld moeten zijn. Back-up en recovery Omdat testtools juist zoveel gegevens genereren en beheren, is het noodzakelijk dat er back-up- en recovery -voorschriften aanwezig zijn. Het moet niet zo zijn dat deze gegevens bij eventuele calamiteiten verloren gaan en niet geback-uped zijn. Voor het testtraject zijn dit bedrijfskritische gegevens, en dienen daarom ook zo behandeld te worden. Procedures technisch beheer Procedures voor het implementeren alsmede het technische beheer van de testtool moet geïntegreerd met de totale technische procedures worden opgezet. Echter mag deze integrale opzet niet tot gevolg hebben dat de procedures worden opgeslokt door het geheel. Deze procedures dienen ten allen tijden expliciet en niet-vrijblijvend aanwezig te zijn. 3.2.2

Produkt omgeving

De beheersaspecten welke in de produkt omgeving naar voren komen, zijn gerelateerd aan het produkt zelf. In de praktijk vormen testtools kritische schakels in de testprocedure. Daarom is het noodzakelijk dat invulling gegeven wordt aan de registratie en beheer van het testtool. Hierbij moet aan de volgende onderverdeling worden gedacht: Ø Licentiebeheer; Ø Versiebeheer; Ø Ontwerp inrichting van het testtool; Ø Autorisatie; Ø Gebruikersdocumentatie; Ø Procedures voor het gebruik; Ø Incidentmanagement. Licentiebeheer Vastlegging van waar en wanneer de inzet van het 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 leverancier te bewaken. Versiebeheer Het testtool zal naar aanleiding van produkt-evaluaties worden aangepast en verbeterd. De registratie van wanneer welke versie is ingezet en wat de specifieke verschillen met de volgende versie zijn, is van groot belang. Naast de inzicht die het verschaft in de ontwikkeling van het produkt, kan met deze registratie achterhaald worden met welke versie van het testtool de testresultaten zijn behaald.

Almere © 2003




Pagina Versie Datum

7 van 19 1.0 27 juni 2006

Naast een goede registratie van het versiebeheer, is een actief versiebeleid binnen de organisatie noodzakelijk. Door mee te lopen met de nieuwste versie van het testtool door de gehele organisatie wordt profijt getrokken van elke verbetering van het testtool. Daarnaast hoeft slechts een beperkt aantal versies ondersteund te worden. Tenslotte, wachten met een nieuwe versie van het testtool tot het moment dat de leverancier besluit de gebruikte versie niet meer te ondersteunen, zal men er achter komen dat conversie naar de nieuwste versie meestal niet meer mogelijk is. Ontwerp inrichting van het testtool Doordat een testtool altijd wordt ingezet in een testtraject en binnen een infrastructuur met specifieke eigenschappen kunnen ‘standaard’ aanpassingen noodzakelijk zijn om het testtool ook operationeel in te zetten. Het is daarbij dus noodzakelijk dat deze ‘customization’ actief geregistreerd en beheerd dient te worden. Autorisatie Testtools op de juiste manier inzetten betekent tevens dat de gebruikers van het testtool geidentificeerd moeten worden. Daarnaast dienen de gebruikers ook te worden ingedeeld in een gebruikersgroep. Per groep kunnen dan de autorisaties met betrekking tot het testtool geregeld worden. Iedere gebruiker zal dan alleen toegang krijgen tot de delen van het testtool wat nodig is voor het optimaal uitvoeren van zijn taak. Gebruikersdocumentatie Duidelijke documentatie is een belangrijk instrument om het optimale gebruik van de testtools te realiseren. 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 versie van het testtool. Procedures voor het gebruik Het gebruik van een testtool betekent een verandering van 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 veranderde werkwijze strikt en niet-vrijblijvend opgezet. Dit is vaak de enige methode om verandering organisatiebreed en eenduidig door te voeren. Om dit te kunnen realiseren moet het testproject reeds gestructureerd zijn. Het is nogmaals niet de bedoeling om het testtool te gebruiken om het testen te structureren. Het veranderen van de werkwijze heeft in deze situatie niets te maken met structurering van het testproces. Incidentmanagement Binnen het versiebeheer is er aandacht voor de specifieke kenmerken van het testtool binnen elke versie. Incidentmanagement dient ervoor om de bevindingen van de gebruikers binnen de eigen organisatie met betrekking tot het testtool te registreren en te bewaken. Met deze interne registratie kan een intensieve en interactieve communicatie met de leverancier worden opgezet. Het doel van het incidentmanagement is om een actuele evaluatie van het testtool tijdens het gebruik uit te voeren. Hierbij dient het pakket van eisen en afspraken, op basis waarvan het 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.

Almere © 2003



3.3


Pagina Versie Datum

8 van 19 1.0 27 juni 2006

Dienstverlening

Zodra het 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 moet leveren op basis van de interne dienstverlening. Deze dienstverlening kan worden onderverdeeld in drie categorieën: Ø Eerstegraads dienstverlening; Ø Tweedegraads dienstverlening; Ø Derdegraads dienstverlening. 3.3.1

Eerstegraads dienstverlening

De eerstegraads dienstverlening is de dienstverlening binnen het project waarin het testtool gebruikt wordt. Wanneer een gebruiker met een vraag zit, legt hij deze in eerste instantie voor aan zijn medegebruikers van het testtool. Het kan best zijn dat deze het antwoord op de vraag weten. Mocht binnen de organisatie een Intranet bestaan, dan kan hierop een kennis-pagina worden ingericht. Op zo’n kennispagina komen dan antwoorden op regelmatig gestelde vragen (FAQs: Frequently Asked Questions) te staan. Mocht een medegebruiker het antwoord niet weten, dan kan de gebruiker deze Intranet-pagina benaderen. De tot stand brenging van zo’n Intranet-pagina vindt plaats via de tweedegraads dienstverlening. 3.3.2

Tweedegraads dienstverlening

Tweedegraads dienstverlening wordt geleverd door een ‘super-user’. Een super-user is een gebruiker van het testtool, welke meer kennis van en ervaring met het testtool heeft dan een gemiddelde gebruiker. Heeft een gebruiker een vraag, en levert de eerstegraads 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 het testtool. Ook als hij geen antwoord op het probleem weet, dan zal hij dit doorgeven aan de leverancier. Dit resulteert in de derdegraads dienstverlening. 3.3.3

Derdegraads dienstverlening

Bij deze graad van dienstverlening komt de leverancier weer in beeld. Vragen welke niet beantwoord kunnen worden door de organisatie dienen aan de leverancier te worden voor gelegd. Dit heeft tot doel de grenzen van het testtool te leren kennen. Om juist te voorkomen dat een ieder de leverancier zal benaderen (of desnoods een helpdesk van de leverancier) zal deze communicatie plaatsvinden via de toepassingsbeheerder. Dit te meer om er voor te waken dat de leverancier continue wordt “lastig” gevallen 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. Dit ter voorkoming van versnippering van kennis omtrent het testtool.

Almere © 2003



3.4


Pagina Versie Datum

9 van 19 1.0 27 juni 2006

Communicatie

Om te komen tot een succesvolle implementatie van een testtool in een staande organisatie zal voor iedereen in deze organisatie duidelijk moeten zijn wat de voordelen van dit testtool zijn. Hiervoor moet men de betrokken partijen goed informeren over het gebruik en de mogelijke voordelen van het testtool. 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. 3.4.1

Communicatievormen

De beslissing tot het implementeren van een testtool en de implementatieplannen kunnen op diverse wijze bekend worden gemaakt aan de organisatie. Welke communicatievorm hiervoor gebruikt moet worden is afhankelijk van wat, wanneer en wie 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. 3.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 over 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 het testtool kan voorzien in zijn behoefte aan meet- en stuurinformatie. Het implementatieteam zal uiteraard de mogelijkheden die het testtool biedt in deze richtingen moeten benadrukken. Ø Testers: Testers vormen de voornaamste groep die daadwerkelijk met het testtool zullen moeten werken. Het succes van een testtool valt of staat met de acceptatie van de testers van het testtool. Benadruk bij hun vooral het gemak van werken en de uitgebreide functionaliteit van het testtool. Dit vooral ook in vergelijking met de situatie waarbij dit testtool nog niet beschikbaar was. Ø Bouwers: Mogelijk zal het 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 voorname 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 ten einde het 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. 3.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 zogenaamd klantprofiel opstellen. Hierin staat een aantal parameters waaraan een juiste ‘klant’ (project-gebruikersgroep combinatie) herkend kan worden voor een betreffende testtool. Vervolgens wordt er aan elke parameter een waarde geassocieerd welke als norm fungeert of een klant wel of niet succesvol met het testtool aan de slag zal kunnen gaan. De informatie omtrent deze parameters en hun normen is per klantprofiel relevant om informatie over te verschaffen.

Almere © 2003



3.5


Pagina Versie Datum

10 van 19 1.0 27 juni 2006

Opleiding

De implementatie van een testtool brengt met zich mee dat medewerkers dagelijks met het testtool aan het werk zijn. Om de acceptatie van het testtool te bevorderen is het noodzakelijk dat de verschillende medewerkers bekend raken met het testtool en weten wat het testtool kan. Het is daarom noodzakelijk dat alle medewerkers in het begin een korte introductie van het testtool krijgen. De beste manier is om de medewerkers zelf met het 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 korte basisopleiding te geven. Doordat het gedurende een basisopleiding mogelijk is om zelf het een en ander uit te proberen, zal men eerder met vragen naar voren komen wanneer men tegen problemen aanloopt. Mocht de situatie zich voordoen dat verschillende medewerkers meer dan gemiddelde kennis van het testtool moeten hebben, dan dient er een vervolg cursus gevolgd te worden. Ook hierbij zal de leverancier van dienst kunnen zijn. Eventueel kan de producent van het testtool hierbij ingeschakeld kunnen worden.

Almere © 2003




Pagina Versie Datum

11 van 19 1.0 27 juni 2006

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

Opdrachtnemer

Teamleden

Gebruikersorganisatie

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 welke de implementatie van het testtool heeft geïnitieerd. Hij is tevens de persoon die er voor dient te zorgen dat er budget en capaciteit beschikbaar komt om het 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 hun activiteiten coördineren, 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. Tevens ondersteunen ze de opdrachtnemer in de voortgang van de implementatie en dienen zij hun vorderingen te melden aan de opdrachtnemer. Referentiekader Het referentiekader is het voorbeeld waaraan men eigenlijk de gehele implementatie wil afspiegelen. 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. Gebruikersorganisatie De gebruikersorganisatie wordt gevormd door personen uit de organisatie welke uiteindelijk met het testtool dienen te gaan werken. Door deze personen in een vroeg stadium bij de implementatie te betrekken, worden in een vroeg stadium hun wensen gehoord. Dit bevorderd het commitment van het 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 © 2003




Pagina Versie Datum

12 van 19 1.0 27 juni 2006

5 Nazorg van het implementatietraject Nu het testtool binnen de organisatie geïmplementeerd is, is het noodzakelijk dat de organisatie ook daadwerkelijk het testtool gaat gebruiken en blijft gebruiken. Men moet ervoor zorgen dat de betrokken personen, ondanks alles, toch bereid om het testtool te gebruiken. Veelal haken de meeste voorstanders af op het moment dat men met het testtool moet gaan werken. Ook hier dienen dus een aantal aandachtsgebieden in ogenschouw genomen te worden. Dit zijn dezelfde aandachtsgebieden als in de voorbereidingsfase, echter liggen de aspecten nu op een ander vlak.

5.1

Beheer en techniek

In de nazorgfase van de implementatie ligt het accent van dit aandachtsgebied op het gebruik van het testtool. Er dienen maatregelen met betrekking tot het gebruik van het testtool genomen te worden om het (juiste) gebruik van het testtool te realiseren. Hierbij dienen de onderstaande aspecten meegenomen te worden: Ø Evaluatie van het toolgebruik; Ø Innovatieve effecten. Evaluatie van het toolgebruik In de praktijk blijkt vaak dat het gebruik van een testtool zich binnen een testorganisatie ontwikkeld als een specialisme. Om grip te kunnen krijgen op de vaardigheden is het verkrijgen van ervaringscijfers essentieel. Daarnaast is het voor de continuïteit van een implementatie noodzakelijk dat kennis en kunde met betrekking tot het testtool breed gedragen wordt binnen een testorganisatie. Tevens moet aandacht worden besteed aan de overdraagbaarheid van deze kennis en kunde. Innovatieve effecten Ingebruikname van testtools zal ten allen tijden effecten hebben op de organisatie, het ontwikkelproces en het testtraject. Al reeds voor de implementatie van het testtool dienen hiervoor maatregelen genomen te worden. Afhankelijk van de specifieke aard van het testtool zijn er veranderingsscenario’s op te zetten, waarop tijdens de implementatie accuraat mee omgegaan moet worden. Tevens zal de omgeving waarin het testtool wordt gebruikt zich gaan 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 of deze verandering is ontstaan door het gebruik van het testtool, en of het testtool hierdoor nog steeds optimaal ingezet kan worden.

5.2

Dienstverlening

Zodra het testtool geïmplementeerd is, zal het in een onderhoudsfase komen. Via de leverancier zullen nieuwe releases van het 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 het testtool, maar beschikt meestal ook over een gedegen cursus om te leren omgaan met het testtool. In eerste instantie zal een beperkte groep gebruikers deze opleiding volgen nog voordat het testtool binnen de organisatie is geïmplementeerd. Echter zodra men zal gaan werken met het testtool, zal de gehele groep medewerkers de cursus dienen te volgen.

5.3

Communicatie

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

Almere © 2003



5.3.1


Pagina Versie Datum

13 van 19 1.0 27 juni 2006

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. Denk hierbij bijvoorbeeld aan implementatiegrootheden en ervaringscijfers. Deze activiteiten hebben als voornaamste doelstelling de implementatie succesvol te continueren. Ten einde de gebruikers van een testtool en andere doelgroepen te voorzien van de gewenste informatie zijn er twee zeer krachtige mogelijkheden: 5.3.2

Life-cyclemanagement

Om als (beheers)organisatie feeling te houden met de gebruikers van het testtool over het functioneren ervan. Er dient dus regelmatig geëvalueerd te worden of het testtool nog voldoet. Een zogenaamd KlantTevredenheidsOnderzoek (KTO) is hiervoor een uitgelezen methode. Met een KTO wordt gemeten in welke fase in de levenscyclus van een produkt het testtool zich bevindt en wat de voor- en nadelen van het gebruik zijn. Op basis van de resultaten van een KTO kan besloten worden het testtool functioneel uit te breiden (aanschaffen van add-ons of een aansluitend testtool) of dat het vervangen dient te worden door een ander testtool. Een derde optie is dat er voorlopig niets aan innovatie gedaan behoeft te worden. Reeds in de implementatie fase kan een plan ontwikkeld worden op welke manier een KTO het beste gehouden kan worden. Er zal gedefinieerd moeten worden op basis van welke meetcriteria noodzakelijk zijn om de levensfase van het testtool te kunnen bepalen. Daarnaast is het noodzakelijk om op voorhand vast te stellen welke actie er ondernomen dient te worden als het testtool zich in een bepaalde levenscyclus bevindt. Het resultaat van een KTO moet informatie geven over de “volwassenheid” van het testtool zodat er, indien noodzakelijk, actie ondernomen kan worden.

5.4

Opleiding

Nadat het 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 vervolg opleiding kunnen volgen. Ook dient er rekening te worden gehouden met aanpassingen in het 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 het testtool binnen de organisatie. Daarnaast kan procedureel beter vastgelegd worden op welke methode het testtool binnen de organisatie wordt toegepast. Tevens leidt dit tot een uniform gebruik van het testtool.

Almere © 2003




Pagina Versie Datum

14 van 19 1.0 27 juni 2006

6 Tijdbalk voor het implementatietraject 6.1

Gebruik tijdbalk

De tijdbalk welke in dit hoofdstuk wordt beschreven is een belangrijk hulpmiddel voor het succesvol implementeren van een testtool. Op een betrekkelijke eenvoudige wijze geeft deze tijdbalk de volgorde aan waarin de gedefinieerde activiteiten uitgevoerd dienen te worden voor een doeltreffende en efficiënte implementatie. De tijdbalk bevat per activiteit slechts enkele trefwoorden, en zullen enkele aandachtsgebieden om een nadere toelichting vragen. Hiervoor wordt verwezen naar de voorgaande hoofdstukken van dit eindrapport. Door het uiteen lopen van de testtools is een implementatie niet in een bepaald tijdsbestek te plannen. In deze tijdbalk geven we om deze reden alleen de volgtijdelijkheid aan. In de tijdbalk wordt het implementatietraject in vijf fasen verdeeld: Ø Initiële voorbereiding; Ø Voorbereiding; Ø Implementatie; Ø Beheer van het gebruik; Ø Nazorg van de implementatie.

6.2

Initiële voorbereiding

Aandachtsgebied Organisatie

Activiteit Opdrachtgever bekend Opdrachtnemer bekend

Beheer en techniek Hardware configuratie eisen Besturingssoftware Randvoorwaarden Stabiele testorganisatie Normen, standaards testproces

6.3

Voorbereiding


Activiteit Teamleden bekend Inrichten derdegraads dienstverlening

Communicatie Informeren betrokken partijen Beheer en techniek Gedocumenteerde procedures implementatie Integratie technisch beheer met de totale technische procedures Inrichten back-up en recovery procedures Inrichten database voor functioneren testtool Inrichten database voor opslaan van de te genereren data Inrichten gebruikersdocumentatie Inrichten gebruiksprocedures Opleiding Opleidingsplan uitgewerkt

Almere © 2003



6.4


Pagina Versie Datum

15 van 19 1.0 27 juni 2006

Initiële implementatie


Activiteit Inrichten tweedegraads dienstverlening Inrichten eerstegraads dienstverlening

Communicatie Kennismanagement Randvoorwaarden Stabiel testobject Normen en standaards testobject Beheer en techniek Licentie en versiebeheer Inrichten van het testtool Autorisatie Incidentenmanagement Opleiding Opleidingsplan actief

6.5

Beheer van het gebruik

Aandachtsgebied Beheer en techniek

Activiteit Continueren licentieen versiebeheer Continueren incidentenmanagement Continueren gebruikersdocumentatie

6.6

Nazorg van de implementatie

Aandachtsgebied Beheer en techniek

Activiteit Evaluatie van toolgebruik

Communicatie Life-cycle management Opleiding Opleidingsplan specifiek maken

Almere © 2003




Pagina Versie Datum

16 van 19 1.0 27 juni 2006

7 Checklist voor het implementatietraject 7.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 efficiënte implementatie. Deze checklist bevat geen bewuste chronologische volgorde van aandachtsgebieden, en zullen enkele aandachtsgebieden om meer omschrijving vragen. Hiervoor wordt verwezen naar eerder hoofdstukken van dit eindrapport. Door het uiteenlopen van de verschillende testtools zullen niet alle onderdelen van de checklist relevant zijn voor de betreffende testtool. Als in een specifieke situatie een aandachtsgebied niet relevant is, biedt een expliciete ‘niet van toepassing’-vermelding concrete duidelijkheid.

7.2

Randvoorwaarden

Testorganisatie

Is er voorafgaand aan de implementatie sprake van een stabiele en volwassen testorganisatie? Testobject Is op het moment van het inzetten van de testtool sprake van een beheersbaar en stabiel testobject? Normen en standaards Zijn normen en standaards gedocumenteerd met betrekking tot het te testen object op het moment van het inzetten van de testtool? Normen en standaards Zijn normen en standaards gedocumenteerd met betrekking tot alle tools en hulpmiddelen die ingezet worden tijdens het testtraject?

7.3

Beheer en techniek ter voorbereiding van de implementatie

Hardware

Kunnen de configuratie-eisen om de installatie van de testtool hardware technisch gezien beantwoord worden op het moment van de implementatie? Software Kan de testtool draaien met de beschikbare besturingssoftware op het moment van de implementatie? Databases Is er een database ingericht waarmee alle noodzakelijke gegevens ter beschikking staan die noodzakelijk zijn om de testtool te laten functioneren? Databases Is er een database ingericht waarin de gegevens kunnen worden opgeslagen die gegenereerd door de testtool? Back-up en recovery Zijn er back-up- en recovery procedures opgesteld op het moment van implementatie? Technisch beheer Zijn er gedocumenteerde procedures voor de implementatie alsmede het technisch beheer van de testtool? Integratie technisch Zijn de procedures voor de implementatie alsmede het technisch beheer beheer van de testtool geïntegreerd met de totale technische procedures? Licentieen Worden vanaf de start van de implementatie de installaties en de versiebeheer updates van de tools geregistreerd en bewaakt? Inrichting van het Worden vanaf de start van de implementatie de maatregelen en testtool aanpassingen geregistreerd die noodzakelijk zijn om de tool operationeel in te zetten? IncidentenWorden vanaf de start van de implementatie de bevindingen met management betrekking tot de tools geregistreerd en bewaakt?

Almere © 2003



7.4


Evaluatie

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

Organisatie

Eerstegraads dienstverlening Tweedegraads dienstverlening Derdegraads dienstverlening Opdrachtgever Opdrachtnemer Teamleden

7.6

17 van 19 1.0 27 juni 2006

Beheer en techniek na de initiële implementatie

Autorisatie Gebruikersdocumentatie Gebruiksprocedures

7.5

Pagina Versie Datum

Is de eerstegraads dienstverlening ingericht? (medegebruikers, algemeen beschikbare media) Is de tweedegraads dienstverlening ingericht? (gecentraliseerde gebruikers kennis) Is de derdegraads dienstverlening ingericht? (leverancier, producent) Is de opdrachtgever met de gestelde wensen en eisen bekend? Zijn voor de opdrachtnemer met de (eind)verantwoordelijkheden bekend? Zijn voor de teamleden de uit te voeren activiteiten bekend?

Communicatie

Informeren betrokken Worden de verschillende groepen betrokkenen onderscheiden? Wordt partijen per groep doeltreffende informatie ter beschikking gesteld? Kennismanagement Is er voldoende kennisoverdracht om de implementatie van de testtool te continueren? Life-cycle Wordt na implementatie het gebruik van de testtool gemeten? management

7.7

Opleiding

Opleidingsplan Leverancier Specificering opleiding

Almere © 2003

Is er binnen de organisatie een opleidingsplan aanwezig voor het gebruik van het testtool? Is de leverancier in staat om opleidingen te geven welke zijn onderkend in het opleidingsplan? Is de organisatie geïnteresseerd en gebaad bij een aangepaste opleiding welke aansluit op het gebruik van de testtool binnen de organisatie?




Pagina Versie Datum

18 van 19 1.0 27 juni 2006

8 Verklarende woordenlijst Functionaliteit

De zekerheid dat de verwerking van de gegevens juist en volledig geschiedt, conform de beschrijving in de volledige specificaties.

Functionele test

Een test, waarbij getest wordt op functionaliteit

Gestructureerd testproces

Een testproces volgens een vastgelegde methode

Implementatie

Het operationeel maken (met behulp van computerprogramma's, systeemsoftware, hardware gebruikershandleiding) van een testtool

Implementatietraject

Het traject waarbij het testtool operationeel gemaakt wordt

Testbaarheid

Het gemak en de snelheid waarmee de functionaliteit en het prestatieniveau van het systeem (na iedere aanpassing) getest kunnen worden

beschikbare en de

Testomgeving/ testinfra De omgeving waarin de test wordt uitgevoerd, bestaande uit apparatuur, structuur systeemsoftware, testtools, procedures, kantoorruimte enz. Testobject

Het te testen (deel van het ) informatiesysteem

Testontwerp

Een beschrijving van wat en volgens welke methode getest wordt

Testtool

Al dan niet geautomatiseerde hulpmiddelen welke ondersteuning ve rlenen tijdens het testtraject. Deze hulpmiddelen lopen uiteen van een checklist, via macro’s tot en met volledige software-pakketten

Testtraject

Het proces vanaf de intake van de testopdracht tot de goedkeuring van de programmatuur

Testware

Alle testdocumentatie, zoals testspecificaties, testscripts en een beschrijving van de testinfrastructuur, die tijdens het testproces wordt geproduceerd

Almere © 2003


Implementatieplan van een testtool. Een aanpak. Algemene informatie voor medewerkers van SYSQA B.V

Recommend Documents