Testmanagement In de zorgsector

Testmanagement In de zorgsector

Auteur Review Versie Datum

Bruggebouw Bos en Lommerplein 280 Postbus 9204 1006 AE Amsterdam Telefoon (020) 346 71 71 Fax (020) 346 71 77 [email protected]

: : : :

Yvonne Goorman Ilse Verstappen, Ray Oei 1.0 7 juli 2009

© 2008 Furore. Alle rechten voorbehouden. Niets uit deze whitepaper mag worden openbaar gemaakt zonder toestemming van Furore of volledige bronvermelding.

Testen, hoezo? Britse patiënten maanden onbehandeld door IThaperingen 19 AUG 2008 Tientallen patiënten in Noord-Londen zijn maandenlang verstoken geweest van behandeling, nadat hun ziekenhuis nieuwe IT-systemen introduceerde. Het IT-systeem Cerner Millenium Care Records Service maakt deel uit van het nationale IT-programma van de NHS, waarvan de totale investering 12,7 miljard pond bedraagt, aldus een artikel in ComputerWeekly.

Ervaringsfeit: Hoe eerder in het traject je fouten vindt, hoe goedkoper ze zijn op te lossen. Ter vergelijking: Wanneer u een huis gaat verbouwen, worden de elektriciteitsleidingen in een vroeg stadium aangelegd. Als u er pas achter komt dat hier iets fout zit op het moment dat alle muren zijn gestuukt en geverfd, de schilderijen hangen, is het oplossen van de fout vele malen ingrijpender en duurder dan wanneer u er tijdens of direct na het implementeren van de leidingen achter was gekomen.

U hebt een applicatie laten ontwikkelen, zelf een applicatie gebouwd of standaardsoftware van een leverancier gekocht. Mooi! Maar hoe weet u nu zeker dat alles in de praktijk ook goed gaat werken? Omdat software ook in de zorg een steeds crucialere rol speelt in de primaire processen is het van groot belang dat u van de kwaliteit en de werking op aan kunt. Een gestructureerde manier van testen helpt u hierbij. Het zorgt voor: 1. Een hogere kwaliteit van de werking van de applicatie: de veiligheid van de processen en gegevens wordt verhoogd; er zijn minder herstelwerkzaamheden na implementatie nodig; minder frustratie en overbodig werk bij gebruikers. 2. Vergroting van de kennis van de applicaties bij betrokken applicatiebeheerders en gebruikers: bevordert beter gebruik van de applicaties. 3. Grotere acceptatie van systemen door betrokkenheid van beheerders en gebruikers 4. Een efficiënter ontwikkelen implementatieproces door hergebruik van documentatie en de opbouw van kennis. 5. Kostenbesparing op de lange(re) termijn. Hoe eerder in het traject fouten worden opgespoord, hoe gemakkelijker en dus goedkoper zijn ze op te lossen. Testen kan uw organisatie dus veel opleveren. Maar, wat en hoe moet er dan precies getest worden en wat komt daar eigenlijk allemaal bij kijken? Deze notitie geeft u hier een overzicht van.

1. Een vak apart Testen is… een proces dat: • gericht is op het vinden van fouten • het verschil aantoont tussen specificaties en de applicatie • nagaat of de applicatie juist is (voldoet aan de eisen van gebruikers) • adviseert over kwaliteit en risico’s. Testen is niet: • alleen uitvoeren van tests, maar ook plannen en voorbereiden • het vrijgeven of accepteren van applicaties de opdrachtgever beslist op basis van de testresultaten • foutherstel dat moet nog gebeuren na het testen • goedkoop Een gedegen testaanpak vraagt investeringen Uit bovenstaande opsomming blijkt al dat testen meer is dan rechtuit, meer is dan ‘een paar testjes uitvoeren’, of ‘kijken of het systeem het doet’. Testmanagement en testen zijn een belangrijk onderdeel van het totale kwaliteitsmanagement bij software ontwikkeling.

2. Onze Visie Onze ervaring op het gebied van testmanagement is dat tot nu toe zeer veel trajecten vanuit de theorie worden aangepakt. Dit heeft te maken met de ontwikkelfase waarin het testen als vak zich momenteel bevindt. De testtheorieën en modellen zijn relatief jong en nog flink in ontwikkeling. Gevolg is dat de theorie een centralere rol in de praktijk krijgt dan vaak gewenst is. De implementatie van testmanagement heeft dan meer het karakter van het implementeren van een dik boek met richtlijnen en documenten dan dat er knelpunten worden opgelost. De sleutel ligt daarom in de toepassing van die theorie. Hierdoor ontstaat er ook een gezonde wisselwerking tussen praktijkervaringen en het op basis hiervan aanpassen van tools en modellen.

Testmanagement © 2008 Furore

7 juli 2009 pagina 1

Uit de praktijk: Niet goed geteste applicaties kunnen, zeker in de zorg, verstrekkende gevolgen hebben. Zo wordt er in sommige ziekenhuizen gebruik gemaakt van beslisbomen ten aanzien van pijnbestrijding. In een van die gevallen was een aanpassing hieraan onvoldoende doorgetest waardoor de telling niet meer correct was. In een ander voorbeeld werden na de implementatie van een nieuw, niet goed getest, systeem zelfs patiënten ten onrechte ontslagen.

De implementatie van goed testmanagement gaat verder dan het inzetten van een aantal templates en testtools. Het is ook een veranderproces waarin management en medewerkers leren op een andere manier naar het totale ontwikkelproces en hun rol daarin te kijken. Daarom is niet alleen het resultaat maar ook de weg ernaar toe belangrijk! En dat betekent een toepassing op maat. Hiervoor hanteren wij een projectmatige aanpak met de volgende fasering: 1. Analyse. In de analysefase wordt beoordeeld wat de huidige werkwijze is, waar de voornaamste knelpunten liggen en met welke risico’s de organisatie op hoofdlijnen te maken heeft. 2. Business Case. Op basis van de analyse wordt een advies voor verbetering opgesteld. De voorgestelde maatregelen en hun kosten dienen hierbij in verhouding te staan tot de ervaren knelpunten en de te verwachten baten. Er dient dus bovenal een valide Business case te zijn. 3. Stapsgewijze implementatie. Omdat de implementatie van testmanagement grote impact op de organisatie heeft en om te voorkomen dat er een ‘papieren tijger’ ontstaat, is het raadzaam om ‘klein’ te beginnen. Bijvoorbeeld via een pilotproject, de introductie van enkele primaire testelementen en het vergroten van kennis. Vervolgens wordt op die ervaringen stapsgewijs uitgebouwd tot het gewenste niveau is bereikt.

3. De sleutelelementen Vanuit bovenstaande visie en onze ervaring, zien wij de volgende elementen als cruciaal bij de implementatie van professioneel testmanagement: • Zorg voor draagvlak in de organisatie. • Richt een gestructureerd en geborgd testproces in. • Maak bewuste keuzes ten aanzien van de te testen onderdelen: test alleen die delen die een bepaald risiconiveau met zich mee brengen. • Integreer het testproces in het totale ontwikkelen implementatieproject. • Test niet alleen een applicatie, test het (keten)proces dat ondersteund wordt. • Betrek eindgebruikers en beheerders en zorg voor voldoende kennis over testen bij betrokkenen. • Zorg voor een goede registratie van bevindingen. 3.1. Zorg voor draagvlak in de organisatie Zoals in het vorige hoofdstuk al werd gesteld is de implementatie van professioneel testmanagement een veranderproces. Het creëren van draagvlak in de organisatie is daarom cruciaal voor het slagen van de implementatie. Professioneel testen betekent een investering (in geld en inzet) op de korte termijn om baten op langere termijn te realiseren. Door middel van uitleg over de filosofie en baten van testmanagement en een gefaseerde aanpak wordt draagvlak bij zowel management als medewerkers gecreëerd. 3.2. Richt een gestructureerd en geborgd testproces in Bijna elke (zorg)organisatie heeft te maken met meerdere (primaire) applicaties met vaak ook verschillende updates per jaar. Vaak worden er standaard updates door leveranciers aangeboden met daarin o.a. bugfixes, maar ook de eigen wensen staan niet stil en vragen regelmatig uitbreiding of aanpassing van de bestaande applicaties. Vanwege de frequentie waarmee softwarewijzigingen tegenwoordig worden doorgevoerd is het verstandig en efficiënt een investering te doen om het testproces goed in te richten en vervolgens te borgen zodat toekomstige projecten hierop kunnen terugvallen. Een gestructureerd testproces houdt in dat er afspraken zijn gemaakt en vastgelegd over onder meer: Testmanagement © 2008 Furore


•

•

• • •

Verantwoordelijkheden en rollen; wie voert welke activiteiten binnen het testen uit, wie coördineert en wie neemt beslissingen. Bijvoorbeeld over het in productie nemen van de software op basis van de testresultaten. Documentatie: welke documentatie wordt opgeleverd? Bijvoorbeeld testplannen, testscripts en rapportages. Het is handig om voor telkens terugkerende documenten templates af te spreken. Registratie: hoe worden bevindingen en wijzigingen vastgelegd. Infrastructuur: afspraken over (het beheer van) ontwikkel-, testen productieomgevingen. Welke testen worden zelf uitgevoerd, welke testen worden van de leverancier verwacht. Het is van belang bepaalde (minimale) eisen aan de testen van de leverancier te stellen en hierover expliciete afspraken vast te leggen.

De inrichting, omvang en zwaarte van het testproces en de organisatie zijn sterk afhankelijk van: • het belang van de applicaties voor de organisatie. Welke applicaties zijn bedrijfskritisch? • de vraag of er ‘in-huis’ wordt ontwikkeld door eigen medewerkers of niet • het gebruik van maatwerkapplicaties of standaardsoftware • de frequentie van veranderingen in de bedrijfsprocessen en applicaties TMap® Next • Beschrijft gestructureerd testproces • Leidraad testaanpak • Complete gereedschapskist • Ervaringen uit de praktijk • Vier pijlers: Wat; fasering Hoe; technieken Wie; organisatie & personeel Waarmee; infrastructuur & tools

Het Testplan Voor de inrichting en uitvoering van het testproces wordt veel gebruik gemaakt van de TMap methodiek (Test Management Approach). TMap is dé teststandaard voor Nederland, België en Duitsland. TMap is gebaseerd op ervaringen uit de praktijk en biedt een complete gereedschapskist waarmee het testproces op de eigen organisatie kan toegespitst worden. In TMap staat het opstellen van een Master TestPlan (MTP) centraal. In het Master Testplan wordt onder ander beschreven wat wel/niet getest wordt en op welke wijze, wat de acceptatiecriteria zijn (op basis waarvan wordt besloten of een applicatie in productie kan), de testorganisatie, de begroting en de planning.

Door het opstellen van een Master TestPlan wordt vorm gegeven aan het testproces voor een bepaalde applicatie of een bepaald project. Het kan vervolgens als leidraad dienen voor de plannen voor andere applicaties en aanpassingen. Hierdoor hoeft niet elke keer het wiel opnieuw uitgevonden te worden. Bij tussenversies of uitbreidingen aan applicaties kan dan volstaan worden met een detail (level) testplan waarin slechts de specifieke projectdetails worden beschreven.



Soorten Testen In onderstaand overzicht zijn de meest gangbare testsoorten die wij in de praktijk tegen komen benoemd:

Ter vergelijking: U koopt een auto: als toekomstige gebruiker maakt u en proefrit (FAT). Tijdens dit ritje let u op een aantal zaken: Hoe rijdt de auto? Hoe zitten de stoelen? Is het dashboard overzichtelijk? Hoe snel trekt hij op? Waar u niet op let: • Of de verbindingen onder de motorkap niet lekken • Of de wielen goed vastzitten • Is de hoeveelheid Co2 uitstoot gelijk aan de hoeveelheid genoemd in de verkoopfolder Kortom; wees bewust van het feit dat 100% dekking niet mogelijk is en realiseer u waar voor u in welke fase van het project de risico’s zitten.

Test

Doel

Wie

Ontwerp & ontwikkel testen

• • • •

Leverancier

Niet functionele (systeem)test

review ontwerp documenten; unit testen van de ontwikkelcode; integratie testen; algemene toetsing gebouwde functionaliteit aan ontwerpen. Verifiëren dat de applicatie in beginsel technisch functioneert.

Functionele Acceptatie Test (FAT) Gebruikers Acceptatie Test (GAT) Productie Acceptatie Test

Verifiëren of de opgeleverde programmatuur functioneert conform het Functionele Ontwerp. Verifiëren of de geleverde functionaliteit ook aansluit op de werkprocessen van de gebruiker. De GAT kan ook impliciet bij de FAT meegenomen worden. Toetsing in de gereed staande productieomgeving als laatste stap voor het vrijgeven van het systeem.

Opdrachtgever

Leverancier

Opdrachtgever

Opdrachtgever

Bovenstaande opsommingen gaan uit van de min of meer standaard ‘testfasen’ die elke (aanpassing aan een) applicatie wel doorloopt. Over het algemeen wordt bij testen gedacht aan het controleren van de functionaliteit, de inhoudelijke werking van de applicatie. Vaak is het echter ook zinvol te kijken naar de performance van een applicatie; kan het systeem het bedoelde aantal (gelijktijdige) gebruikers aan? Wat is de limiet van het aantal gebruikers? Hoe zwaar dit wordt opgetuigd is afhankelijk van het gebruik van de applicatie. Dit zijn de zogenaamde performance- en stresstesten. 3.3. Maak bewuste keuzes Gestructureerd testen brengt een flinke investering met zich mee. Het is natuurlijk van belang die investering zo goed en gericht mogelijk in te zetten. 100% testen gaat niet en is ook niet gewenst. Er moet een zekere balans zitten tussen de investering die gedaan wordt en het resultaat (in de vorm van kwaliteit en het voorkomen van fouten in de Praktijk). Teststrategie is daarom gebaseerd op risico-denken: een systeem moet zodanig voldoen in de praktijk dat er geen onacceptabele risico's voor de organisatie uit voortvloeien. Daar waar de oplevering van een systeem veel risico's met zich meebrengt, is uitgebreid testen op zijn plaats; het omgekeerde is ook waar: 'geen risico = geen test'. Om hierin de juiste keuzes te kunnen maken worden de volgende stappen doorlopen: 1. Identificeren van de testdoelen. De testdoelen beschrijven wat vanuit het perspectief van de opdrachtgever uiteindelijk met de test bereikt dient te worden. Hier wordt vaak alleen de correcte werking van systeemonderdelen onder opgenomen, maar testdoelen zijn breder dan dat. Een testdoel kan ook een totaal bedrijfsproces zijn of een bepaalde kritieke succesfactor, zoals het uiterlijk van output naar externe partijen. Het gaat dus niet alleen om stukken functionaliteit. 2. Bepalen van de risicoklasse per testdoel. Leidende vraag hierbij is “hoe groot is de kans dat er iets fout gaat en tot schade leidt voor de organisatie?”. Hierbij is zowel de kans dat een fout zich voordoet van belang als de impact die de fout heeft. 3. Op basis van de risicoklasse wordt vervolgens de zwaarte van de test bepaald. Bij onderdelen waar nauwelijks of geen risico’s aan de orde zijn kan bijvoorbeeld volstaan worden met een impliciete test. In dat geval worden de onderdelen bij een andere test meegenomen, zonder het maken van specifieke testgevallen. Bij hoge risico’s zal een zware dynamische test uitgevoerd worden, waarbij systeemonderdelen met testscenario’s uitgebreid worden doorgelicht.



3.4.

Integreer het testproces in het totale ontwikkelen implementatieproces In het verleden werd het testen nogal eens als ‘achterdeur’ van het ontwikkelproces beschouwd. Testen kwam pas laat in beeld en kwam daardoor ook nog wel eens in de verdrukking. Inmiddels is het testvak geprofessionaliseerd en daarmee kwam ook het besef dat het te laat is om pas na oplevering van de software te beginnen met het testproces. Zodra gestart is met het ontwerp van nieuwe software kan ook al gestart worden met de voorbereidingen van het testen. Op die manier: • kan er voldoende tijd besteed worden aan de testvoorbereiding, zoals het maken van een plan, het uitvoeren van de risicoanalyse en het schrijven van testcases en testscripts; • maken testers al tijdens de ontwerpen ontwikkelfase kennis met het (concept) systeem en ontstaat er een wisselwerking tussen de verschillende disciplines (ontwerpers, programmeurs, testers). Dit komt de kwaliteit van het totale proces en het uiteindelijke resultaat ten goede. • kunnen specifieke testen toegepast worden voor specifieke doeleinden en ontstaat een logisch verband tussen de verschillende systeemdocumenten. Onderstaand model van TMap® Next ligt deze verbanden toe: wens, probleem, wet, beleid, kans toetsen aan

Gebruik & Beheer

accepterende partij

Business & Functionele Requirements

input

Acceptatie Tests

toetsen aan

Functioneel Ontwerp

input

Systeem Tests

leverende partij

toetsen aan

Productie Acceptatie Test Gebruikers Acceptatie Test Functionele AcceptatieTest Systeem Integratie Test

Systeem Test

input

Technisch Ontwerp

toetsen aan

input

Ontwikkel Tests

Unit Integratie Test Unit Test

input

Realisatie /Bouw

Bovenstaande impliceert dat het testmanagement ook qua organisatie ingebed dient te zijn in de (project)organisatie die verantwoordelijk is voor de totale ontwikkeling en implementatie van nieuwe software. 3.5. Test niet alleen een applicatie, test het (keten)proces De neiging bestaat vaak om het testen op te delen naar functionaliteiten van de applicatie en naar werkzaamheden van verschillende afdelingen. Vaak ondersteunt een applicatie echter een proces dat niet ophoudt bij de grenzen van de afdeling, maar doorloopt naar andere afdelingen en koppelingen heeft met andere applicaties. Dit geldt ook voor veel primaire zorginformatiesystemen. De ontwikkelingen op dit gebied versterken deze situatie alleen maar. Er wordt steeds meer toegewerkt naar een integraal systeem dat alle (zorggerelateerde) processen ondersteund. In deze situatie is het cruciaal dat het testen vanuit het proces wordt opgezet. Hierdoor wordt bij implementatie van een applicatie onderzocht of de overgang tussen rollen en Testmanagement © 2008 Furore


afdelingen goed wordt ondersteund, of gegevens correct wordt doorgegeven en of het uiteindelijke resultaat aan het eind van het proces, bijvoorbeeld de facturatie, wel klopt met de gegevens die ‘onderweg’ zijn vastgelegd. Bij wijzigingen in bestaande applicaties wordt zo ook onderzocht of de veranderingen geen onverwachte effecten hebben op andere delen van de applicatie en daarmee mogelijk op andere afdelingen en processen. Een voorbeeld van een dergelijke procesbenadering: Bij de implementatie van een nieuwe versie van een ZIS werd een procestest voorbereid voor het poliklinisch spreekuur. Hierbij werd het totale proces beschreven, startend bij het moment van het (telefonisch) maken van een afspraak, tot aan het feitelijke consult en het afsluiten van het spreekuur. In het proces zijn zes verschillende medewerkerrollen actief. De test werd opgedeeld in een aantal subprocessen zoals de inschrijving, de voorbereiding van het spreekuur, het consult en het maken van een vervolgafspraak. Per subproces werden alle mogelijke ‘routes’ van een patiënt in een testscenario verwerkt. Vervolgens werd met enkele fictieve patiënten op basis van verschillende routes het hele proces doorlopen. Uit de praktijk: Hoe belangrijk het is om niet alleen op (gebruikers-) functionaliteit te testen, bleek in de volgende praktijksituatie: Medewerkers kwamen er na verloop van tijd toevallig achter dat het mogelijk was dat twee medewerkers gelijktijdig gegevens invoerden in een elektronisch patiëntdossier zonder dat het systeem hierover een melding gaf. Wanneer dit gebeurde werden de gegevens niet opgeslagen! Hierdoor ging medische informatie verloren terwijl de medewerkers dachten dat dit goed geregistreerd was.

3.6. Betrek eindgebruikers en beheerders Om een applicatie uiteindelijk in de praktijk goed te laten functioneren is er meer nodig dan het controleren of de functionaliteit technisch werkt en voldoet aan het afgesproken ontwerp. De programmeur weet hoe hij het systeem heeft gebouwd en zal ook (onbewust) volgens deze procedures testen. Hij zal zich nooit helemaal kunnen verplaatsen in de praktijk waarin de applicatie gebruikt wordt. Daarom is het belangrijk eindgebruikers en beheerders van de applicaties bij het testen te betrekken. Hiermee wordt ook beter mogelijk om, zoals hierboven is beschreven, het proces als uitgangspunt te nemen, in plaats van de applicatie. Ook zullen gebruikers meer oog hebben voor de gebruikersvriendelijkheid en de look & feel van een applicatie. Bijkomend voordeel is dat de betrokkenheid zorgt voor vergroting van de kennis van de applicaties, waardoor beter gebruik van de applicaties wordt bevorderd. Testpool Testen vergt specifieke vaardigheden en kennis. Het is daarom aan te bevelen om een relatief vaste pool van medewerkers beschikbaar te hebben voor testwerkzaamheden en hen te scholen in het testen. Hiermee wordt een gespecialiseerd team gecreëerd die met elke implementatie meer ervaring opdoet ten aanzien van de applicaties en het testen en dit binnen de organisatie ook kan overdragen. Bij grote projecten kan overwogen worden om daarnaast gespecialiseerde testers in te huren. 3.7. Zorg voor een goede registratie van bevindingen Tijdens het testen wordt een veelheid aan bevindingen gedaan, die allemaal beoordeeld, geprioriteerd en opgelost (of geaccepteerd) moeten worden. Dit is een arbeidsintensief proces, dat vergemakkelijkt wordt als vanaf dag 1 helder is waar en op welke manier bevindingen moeten worden vastgelegd. Een gestructureerde registratie zorgt voor: • Goede traceerbaarheid; wat houdt de bevinding precies in en welke beslissing is erover genomen. • Betere bewaking; wat is de prioriteit en de status van een bevinding. • Beter overzicht van de voortgang en status van het testen en de herstelwerkzaamheden. • Heldere communicatie met andere betrokkenen, zoals de leverancier Door het inrichten van een bevindingen registratie ‘systeem’ wordt veel onnodig werk en toekomstige frustratie voorkomen. Wanneer een dergelijk systeem eenmaal staat kan het gebruikt worden voor alle softwareprojecten in de organisatie. De registratie kan ondersteund worden met behulp van een gespecialiseerd tool, maar dit kan ook met standaard middelen. E.e.a. is afhankelijk van de omvang van het testen en het Testmanagement © 2008 Furore


aantal te testen applicaties. Wanneer de software geleverd wordt door een externe leverancier kan soms ook gebruik gemaakt worden van het registratiesysteem van de leverancier.

4. Conclusie Met de implementatie van professioneel testmanagement staat u aan het begin van een leertraject dat u veel baten op kan leveren. Om dit traject goed te laten verlopen is het van belang vooraf tijd te investeren in een gedegen analyse en business case zodat u het testmanagement op uw specifieke situatie kunt toepassen en er geen ‘overkill’ ontstaat. De implementatie van testmanagement is een veranderproces voor uw organisatie en medewerkers, dat gebaat is bij een stapsgewijze aanpak. Begin bescheiden met bijvoorbeeld een pilot project. Zo doen uw medewerkers kennis en ervaring op, op basis waarvan stapsgewijs naar de gewenste eindsituatie gewerkt kan worden. Hiermee wordt draagvlag gecreëerd en kunt u tijdig bijsturen. Vanuit onze ervaring hebben wij een zevental sleutelelementen van testmanagement geïdentificeerd die in de implementatie terug dienen te komen. Door het toepassen van deze elementen realiseert u alle randvoorwaarden om een grote kwaliteitsslag in de ontwikkeling en implementatie van nieuwe software te maken.

Over Furore Furore heeft een groot aantal succesvolle projecten op diverse kennisgebieden binnen de zorgsector afgerond. Furore heeft dan ook diepgaand inzicht in de processen en uitdagingen binnen deze sector. Wij zijn een onafhankelijke partij zonder banden met leveranciers, zo bent u altijd zeker van een eerlijk en objectief advies. Op het gebied van testen kunt u bij ons terecht voor onder andere interim testmanagement, advisering ten aanzien van inrichting en professionalisering van uw testproces, testcoördinatie, en testuitvoering zoals het maken van testscenario’s. Onze aanpak wordt gekenmerkt door enerzijds grote materiekennis van zowel zorgprocessen als testmethodieken (TMap® Next (gecertificeerde medewerkers), ISQTB), en anderzijds door een praktische en pragmatische toepassing van methodieken in uw specifieke situatie. Een advies van Furore is daarmee volledig afgestemd op de behoefte binnen uw organisatie. Voor meer informatie over onze Testdiensten kunt u contact opnemen met Ilse Verstappen, manager van de afdeling Quality Assurance & Testen, via 020 – 346 71 71 of mail naar [email protected]. Voor een volledig overzicht van onze dienstverlening verwijzen wij u graag naar onze website: www.furore.com



Testmanagement In de zorgsector

Recommend Documents