Introductie QA en testen bij ERP

Transcriptie

1 Introductie QA en testen bij ERP SYSQA B.V. Almere Datum : Status : definitief Versie : 2.0 Opgesteld door :

2 Organisatie SYSQA B.V. Pagina 2 van 12 Inhoudsopgave 1 Inleiding Leeswijzer Requirementstechnieken Methode voor requirements Reviewtechnieken Collegiale review Walkthrough Inhoudelijke review Inspectie Managementreview Monitoringstechnieken Audit Inspectie Andere vormen van monitoringstechnieken Testen Testen Methoden voor testen... 11

3 Organisatie SYSQA B.V. Pagina 3 van 12 1 Inleiding Deze introductie is opgesteld om lezers te laten zien welke kwaliteitsmaatregelen (QA maatregelen) mogelijk zijn om ERP implementaties succesvol te laten verlopen. Maatregelen rond de conversie van masterdata, maar ook configuratie / parameterisering van ERP pakketten vragen om passende maatregelen. Een aantal vragen die elke opdrachtgever zichzelf moet stellen zijn: Wilt u het laten slagen alleen van de leverancier af laten hangen? Is al eerder een succesvolle implementatie van een ERP-pakket uitgevoerd? Is uitvoerig naar de risico s van ERP implementatie gekeken en niet alleen naar de risico s die de leverancier heeft benoemd? Een ERP pakket is vaak het hart van een organisatie, wilt u dan risico lopen dat de implementatie mislukt? Is het antwoord op de vraag of de business of de IT bepaalt op welke manier de implementatie verloopt, de business? Is het antwoord op 1 of meerdere van bovenstaande vragen nee, dan is het van belang de juiste maatregelen te nemen en dit document goed door te nemen om zo meer kans op een succesvolle implementatie af te dwingen. Voor informatie over wat ERP is en welke aandachtspunten bij implementatie van belang zijn, verwijzen wij u naar de introductie ERP op de kennisbank van SYSQA. Kwaliteitsmaatregelen zijn van belang voor het succesvol laten verlopen van een ERP implementatie. De in dit document benoemde kwaliteitsmaatregelen zijn toepasbaar op de risico s benoemd in het document Risicos bij ERP Vx.x.pdf. 1.1 Leeswijzer In deze introductie worden verschillende QA maatregelen behandeld die toepasbaar zijn bij ERP implementaties. Naast het behandelen van de technieken wil SYSQA u handvatten geven om te laten zien op welke manieren deze technieken toepasbaar zijn. Hiervoor zijn voor alle technieken cases beschreven die voortkomen uit ervaringen van medewerkers van SYSQA bij verschillende opdrachtgevers. Het te toetsen product en het belang van het product bepaalt welke techniek dient te worden toegepast. Het document is als volgt opgebouwd: In hoofdstuk 2 wordt het belang van requirements nader toegelicht inclusief een nadere toelichting over een beheerst requirementsproces; Hoofdstuk 3 geeft een uitleg over de verschillende reviewtechnieken en met behulp van cases wordt uitgelegd hoe deze succesvol kunnen worden toegepast voor ERP; In hoofdstuk 4 worden monitoringstechnieken nader toegelicht; Hoofdstuk 5 gaat dieper in op de verschillende soorten testen die te gebruiken zijn bij ERP.

4 Organisatie SYSQA B.V. Pagina 4 van 12 2 Requirementstechnieken Om tijdens een ERP traject tot de keuze van een ERP pakket te komen dat de juiste ondersteuning aan de bedrijfsprocessen biedt, is het van belang om goede en volledige requirements (eisen) op te stellen. Om de juiste kwaliteit van het ERP systeem te bereiken is het van belang dat requirements worden opgesteld aan de hand van een beproefde methode. De kwaliteit van het opgeleverde ERP systeem wordt direct bepaald door de kwaliteit van de requirements. De requirements moeten aan het einde van het requirement-ontwikkeltraject antwoord geven op de volgende 3 hoofdvragen: 1. Waarom moet dit systeem aangeschaft worden? 2. Wat moet het systeem doen? 3. Hoe moet het systeem werken om aan vraag 1 en 2 te voldoen? Tijdens de testfase van het ERP systeem zal worden bekeken of het systeem voldoet aan de opgestelde requirements. 2.1 Methode voor requirements IREB (International Requirements Engineering Board) is een requirements ontwikkelmethode die gebruikt wordt bij het definiëren, documenteren en beheren van de requirements. Het requirement ontwikkeltraject bestaat volgens IREB uit vier basis activiteiten: 1. Elicitatie 2. Documentatie 3. Validatie & onderhandeling 4. Management Elicitatie van requirements Elicitatie van requirements heeft als doel om zoveel mogelijk requirements boven water te krijgen, zodat deze kunnen worden vastgelegd en bewaakt. Voor de elicitatie van requirements zijn verschillende technieken beschikbaar. Zo wordt er onder andere gebruik gemaakt van onderstaande technieken: Onderzoekstechnieken: interviews en vragenlijsten Observatietechnieken: meekijken, gebruik maken van systemen. Creatieve technieken: brainstormsessie, bekijken vanuit verschillende perspectieven, associatie technieken. Documentatie onderzoek: huidige systeem in kaart brengen, perspectief gerelateerd benaderen, hergebruik Documentatie van requirements Om goed overzicht te krijgen in de requirements dienen deze te worden gedocumenteerd. Bij de documentatie van requirements wordt er aandacht besteed aan: Standaard structuur Aanpasbaarheid Volledigheid Traceerbaarheid Een requirements document bevat ook de prioritering van de requirements. Bij de leverancierkeuze kan op basis van deze prioritering snel bekeken worden wat de gevolgen zijn bij het niet voldoen van het ERP pakket aan de requirements.

5 Organisatie SYSQA B.V. Pagina 5 van Validatie & onderhandeling requirements Bij de validatie van de requirements wordt er bepaald of de requirements voldoen aan de kwaliteitseisen (zie ISO ISO 25010:2011). De validatie van de requirements wordt uitgevoerd door de stakeholders. Als blijkt dat er conflicterende requirements zijn opgesteld zullen de stakeholders moeten onderhandelen over het belang van de requirements en de prioritering hiervan. Het vroegtijdig oplossen van conflicterende requirements levert een aanzienlijker besparing op ten opzichte van wanneer het bijvoorbeeld pas bij uitrol wordt opgelost. Omdat ERP door meerdere, verschillende afdelingen wordt gebruikt is de kans op conflicterende belangen en daarmee conflicterende requirements groter Management van requirements Tijdens het ERP traject dienen de requirements goed bewaakt te worden en waar nodig bijgesteld. Er wordt overzichtelijk bijgehouden welke requirements zijn gedocumenteerd, wat de status is van de requirements, de prioritering, welke veranderingen er zijn doorgevoerd en de traceability naar de verschillende onderdelen van het ERP systeem Case Een bedrijf in de automotivebranche schaft een nieuw ERP pakket aan. De reden waarom het pakket wordt aangeschaft is dat het oude pakket niet meer voldoet aan de huidige eisen van het bedrijf. Het beoogde ERP pakket zou alle bedrijfsprocessen ondersteunen. Tijdens de gebruikers acceptatietest kwam men er achter dat het aanvragen van kentekens voor de verkochte auto s niet mogelijk was. Het was voor het ERP pakket niet mogelijk om via een standaard interface het systeem te koppelen aan het systeem welke de aanvragen moet indienen bij het RDW. Het project heeft 6 maanden langer geduurd omdat er een stuk maatwerk gemaakt moest worden waar de business niet op had gerekend. Het bedrijf had verzuimd om het proces op te nemen in de requirements, door gebrek aan betrokkenheid van de afdeling, waren niet alle requirements benoemd bij het requirement ontwikkelproces. Was er tijdens de requirement ontwikkeling gebruik gemaakt van een methode dan was het gemis van een belangrijk proces eerder ontdekt, wat uitloop van het project had voorkomen. 3 Reviewtechnieken Reviewtechnieken hebben tot doel het vroegtijdig vinden van fouten zodat ze vroegtijdig hersteld kunnen worden. Door vroegtijdig herstel kunnen grote voordelen in termen van tijd, geld en kwaliteit worden behaald. Het uitvoeren van een review vergt een gedegen voorbereiding evenals een evenwichtige afweging van de toe te passen reviewtechniek. 3.1 Collegiale review De collegiale review is een informele techniek die wordt toegepast door collega s onderling. De techniek wordt vooral gebruikt om het werk van een collega te toetsen op juistheid. Een aantal voorwaarden zijn van belang: Het belang van het document mag niet te hoog zijn; Vertrouwen tussen collega s moet aanwezig zijn; Fouten zijn zonder consequenties. Nadelen: Minder geschikt voor requirements, architectuuroverzichten of ontwerpen; Mogelijkheid om fouten te verzwijgen in verband met de onderlinge relatie.

6 Organisatie SYSQA B.V. Pagina 6 van Case Bij een levensmiddelenproducent was een leverancier in vergevorderd stadium met de implementatie van een ERP pakket. De manier waarop met het systeem moest worden gewerkt was door de afdelingsmanager op papier gezet. Op deze werkwijze was het pakket ook aangepast. Waar de leverancier en ook de opdrachtgever niet aan hadden gedacht was dat de afdelingsmanager nog maar sinds kort werkzaam was binnen het bedrijf en nog niet op de hoogte was van alle werkprocessen binnen de afdeling. Door betrokkenheid van een QA medewerker van SYSQA, tijdens verschillende oriënterende gesprekken met medewerkers die binnen het bedrijf werkzaam waren, kwam dit tijdig aan het licht. Door het toepassen van de collegiale review zijn voor verdere implementatie alle processen zoals bedacht door verschillende afdelingsmanagers gereviewd door verschillende medewerkers van de betreffende afdelingen. Na het bespreken van de verschillende werkwijzen is het proces afgestemd op de werkelijke en gewenste processen. 3.2 Walkthrough Bij een walkthrough leidt de auteur een groep door een document of een ander product en licht de achterliggende gedachten en keuzes toe. Een walkthrough wordt vooral toegepast als het tussenproduct, zoals de architectuur en het ontwerp, nog in ontwikkeling is. Deelnemers aan een walkthrough geven vanuit hun eigen expertise feedback op het document en kunnen eventuele alternatieven aandragen. Het doel is consensus te bereiken over de discussiepunten. Voordelen: Vroegtijdig consensus bereiken over (mogelijke) discussiepunten Kansen en beperkingen in het ERP pakket komen eerder aan het licht Belanghebbenden worden pro-actief betrokken bij besluitvorming en oplossingsrichtingen. Voorwaarden: Vertegenwoordiging vanuit alle belanghebbenden van het betreffende product Deelnemers dienen vrij te kunnen discussiëren Deelnemers kunnen bestaan uit collega s, experts en deelnemers van buiten de eigen disciplines Case Een groothandel in levensmiddelen besloot tot aanschaf van een ERP pakket voor het afhandelen van de goederenstroom door het bedrijf. Na het uitvoeren van de requirementsfase stelde de leverancier een ontwerp op waarin de procesbeschrijvingen waren opgenomen en waar de ondersteuning vanuit het systeem was beschreven. Tijdens de walkthrough heeft de leverancier de ondersteuning vanuit het ERP systeem toegelicht. Tijdens deze toelichting bleek dat de leverancier een aantal aannames had gedaan om het inkoopproces sluitend te krijgen. Deze kwamen niet overeen met het proces zoals dat bij de groothandel gebruikelijk was.

7 Organisatie SYSQA B.V. Pagina 7 van Inhoudelijke review Een gestructureerde, inhoudelijke beoordeling van een product. Het doel van de inhoudelijke review is het vinden van fouten en het beoordelen van de beschreven oplossingsrichting. De inhoudelijke review is een formelere reviewtechniek dan een walkthrough of collegiale review maar is minder formeel dan een inspectie. Voorwaarden: Deelname van experts en/of collega s vereist; Per reviewer rollen van tevoren toewijzen; Bevindingen uit de inhoudelijke review dienen te worden vastgelegd; Deelnemers dienen tijd te krijgen voor het uitvoeren van de review (managementcommitment). Voordelen: Kan gebruikt worden om producten formeel goed te keuren; Kwaliteit van de bevindingen en de traceerbaarheid van de verwerking van de bevindingen neemt toe t.o.v. de collegiale review Case De documentatie die een leverancier van een ERP systeem heeft opgesteld is onder begeleiding van een medewerker van SYSQA onderworpen aan een inhoudelijke review. Uit verschillende delen van de organisatie zijn medewerkers het hoofdstuk over de systeeminstellingen in de documentatie gaan beoordelen vanuit hun perspectief. Een week na de start van de review waren 38 major en 91 minor bevindingen gedaan in het hoofdstuk over de systeeminstellingen. Een aantal van de majors waren potentieel bedreigend voor de organisatie. 3.4 Inspectie Bij een inspectie maakt de auteur een product op basis van ontvangen input en conform een gedefinieerd proces. Als het product gereed is wordt dit door middel van een inspectie beoordeeld waarbij bevindingen worden geïdentificeerd. Op basis van deze bevindingen wordt het product verbeterd. Het doel van de inspectie is niet alleen om fouten te vinden maar ook om processen te verbeteren. Daarnaast heeft de inspectie tot doel om de kwaliteit van het product vast te stellen. Een inspectie is de meest uitgebreide vorm van reviewen en wordt met name gebruikt wanneer het product nagenoeg gereed is. Het verschil met een inhoudelijke reviw is vooral de diepgang en de structuur die bij een inspectie wordt toegepast. Voorwaarden: Vereist gedegen voorbereiding Van tevoren wordt vastgesteld op welke aspecten iedere inspecteur de inspectie uit gaat voeren Het organiseren van een kick-off is, zeker wanneer een inspectie voor het eerst wordt georganiseerd, aan te raden Voordelen: Kennisdeling. Door het product kritisch te beoordelen leren teamleden het product beter kennen. Aantal fouten later in het project neemt af, project loopt soepeler en tevredenheid medewerkers neemt toe.

8 Organisatie SYSQA B.V. Pagina 8 van Case Een maritiem transporteur die gewend is om inspecties bij reguliere softwaretrajecten uit te voeren, besluit dit op advies van SYSQA ook te doen bij de implementatie van een ERP pakket. Dit ondanks dat de leverancier aangeeft dat dit niet nodig is in verband met het standaardpakket waar de transporteur gebruik van wil gaan maken. Tijdens de inspectie komt een aantal procesbeschrijvingen naar voren die niet aansluiten op de werkmethodiek bij de transporteur. De transporteur geeft later aan Als we de inspectie niet hadden gedaan dan hadden we dit tijdens het testen waarschijnlijk gevonden, maar dan hadden we minimaal 6 maanden vertraging opgelopen. 3.5 Managementreview Een managementreview wordt in opdracht van het management uitgevoerd. Een managementreview kan worden gecombineerd met belangrijke mijlpalen in het project om te bepalen of het project de desbetreffende mijlpaal al dan niet mag passeren. Het doel van de managementreview is het beoordelen van de status van een project op basis van de volgende aspecten: Tijd, geld, kwaliteit en risico s. Voorwaarden: Reviewers zijn onafhankelijk ten opzichte van het project Opstellen duidelijke opdrachtomschrijving voor het reviewteam Case Voor een gemeentelijke instantie heeft SYSQA op verzoek van het management een managementreview uitgevoerd op de IT dienstverlening op verschillende afdelingen van de instantie. De focus lag daarbij op klanttevredenheid, de kosten en de gebruikersintensiteit van een ERP pakket. Tijdens die review bleek al snel dat het gebruik van het pakket minder intensief was en dat de tevredenheid te wensen over liet. Het systeem ondersteunde niet voldoende de gebruikte processen waardoor veel workarounds nodig waren om het geheel werkend te houden. In het advies naar het management kwam dan ook een aanbeveling om de procesflow van het pakket onder de loep te nemen en te kijken naar mogelijke aanpassingen. Uit de businesscase die daarvoor werd opgesteld bleek het aanpassen van de software minder te kosten dan de kosten die nodig waren om alles op de huidige manier te laten werken. 4 Monitoringstechnieken Bij monitoringstechnieken wordt geobserveerd op welke manier bestaande systemen worden gebruik. Monitoringstechnieken worden veelal gebruikt om op een onafhankelijke manier te bepalen wat de situatie van het project of proces is. Met monitoringstechnieken kan op een objectieve manier antwoord gegeven worden op één of meerdere van de onderstaande vragen: Wordt het project conform afspraken uitgevoerd? Is het huidige werkproces toereikend genoeg voor de organisatie? Klopt het vermoeden dat het project achter ligt op schema? Monitoringstechnieken zijn niet zozeer bedoelt om producten te verbeteren of fouten op te sporen maar meer om op een onafhankelijke manier de huidige stand van zaken te bepalen.

9 Organisatie SYSQA B.V. Pagina 9 van Audit Een audit kan plaatsvinden op projecten, processen en producten. Daarmee kan een audit ook op de implementatie van een ERP pakket plaatsvinden. Zowel op de projectuitvoering als (de inrichting van) het product. Een audit vindt voornamelijk plaats op momenten dat er twijfels rijzen over de juistheid, het niet bereiken van het doel tijdens van de projectuitvoering of het niet voldoen aan de eisen van het product. Een audit dient als hulpmiddel om inzicht te geven is de werkelijke status van het product, proces of project vast te stellen. Het uitvoeren van een audit is een formele aangelegenheid en medewerking van alle belanghebbenden (zeker van externe partijen) is niet gegarandeerd. Van belang is om vooraf het onderzoeksgebied, het referentiekader en de opdracht van de auditor goed af te bakenen. Een audit kan voor ERP op de volgende momenten voordelen bieden: Vooraf: Bepalen of de focus op het met ERP te ondersteunen proces juist is. Wordt QA volledig en op de juiste manier toegepast. Achteraf: Sluiten de werkprocessen en het ERP systeem voldoende op elkaar aan Case Bij een implementatie van een ERP systeem bij een multinational bleek het product qua prestaties niet te voldoen. De reactietijden van het systeem naar de gebruiker bleven achter bij de verwachtingen en zelfs bij de de facto industrie standaarden. Daarbij namen de batchprocessen te veel tijd in beslag waardoor materiaalberekeningen niet konden worden uitgevoerd. Hierdoor liep de productie vertraging op en leed het bedrijf forse economische schade. Door de inzet van een externe QA auditor met kennis van ERP systemen kwam de opdrachtgever achter de oorzaken van de problemen en kreeg een advies over de oplossing hiervoor. Vooraf heeft de QA auditor onderzoek gedaan naar gemelde problemen en (pogingen tot) oplossingen. Tijdens de audit zelf heeft de auditor zich gericht op het achterhalen van de inrichting van het systeem en deze vergeleken met de door de pakketleverancier voorgeschreven inrichting. Waar nodig heeft de auditor gebruik gemaakt van externe materiedeskundigen. Door het opvolgen van de adviezen uit het audit rapport werd de inzet van het ERP pakket een succes. 4.2 Inspectie Tijdens een inspectie wordt (een deel van) de implementatie onder de loep genomen. Komt de voortgangsrapportage overeen met werkelijkheid. Worden de projectdoelen en bedrijfsdoelen gehaald. Of juist niet. Aanleiding voor een inspectie tijdens de projectuitvoering is meestal dat (een aantal) belanghebbenden (ernstige) twijfels hebben over het behalen van het projectdoelen of bedrijfsdoelen. De inspectie kan zich bijvoorbeeld richten op de inrichting van ERP of juist op de pakketleverancier. Een onderzoeksvraag kan dan zijn hoe de pakketleverancier om gaat met kwaliteitsborging en maatregelen. Oorzaak van zo n onderzoeksvraag is in dat geval dat vaak de kwaliteit van het pakket achterblijft ten opzichte van de verwachtingen van de koper.

10 Organisatie SYSQA B.V. Pagina 10 van Andere vormen van monitoringstechnieken Bepaalde vormen van monitoringstechnieken kunnen toegepast worden aan het begin van een traject of project, bijvoorbeeld bij de pakketselectie van een ERP systeem. Een mogelijkheid zou een demonstratie van de leverancier van het ERP systeem kunnen zijn. In de demonstratie kan aangegeven worden wat de mogelijkheden van het systeem zijn en een idee gevormd worden in hoeverre het ERP systeem aan kan sluiten bij de wensen van de klant. Eventueel lastiger maar desalniettemin zeer waardevol is het observeren van een ERP systeem bij een branche-genoot. In verband met concurrentie kan dit lastig te regelen zijn maar een duidelijke indruk kan worden verkregen hoe een leverancier het ERP-systeem kan implementeren. 5 Testen In de voorgaande hoofdstukken is vooral stilgestaan bij QA maatregelen welke genomen kunnen worden aan het begin en gedurende het traject. De ERP software is geïnstalleerd en geconfigureerd, wat nu? Kan worden gestart met de testuitvoering? Maar welke tests kunnen worden uitgevoerd? Deze vraag wordt in dit hoofdstuk behandeld. 5.1 Testen Vragen die moet worden beantwoord zijn; is de huidige configuratie daadwerkelijk inpasbaar in het bedrijfsproces en functioneert het ERP systeem zoals verwacht. De bedrijfsprocessen die het pakket gaat besturen, zullen onderdeel uitmaken van tests. Denk hierbij ook aan bedrijfsprocessen die op elkaar aansluiten, zoals logistieke transacties die gevolgen hebben in het grootboek. Dit soort afhankelijkheden zullen onderdeel van een integrale test moeten zijn. Tijdens deze tests kunnen issues optreden die tot softwareaanpassingen leiden vanuit de pakketleverancier. Op basis van de test- en kwaliteitsaanpak van de software leverancier moet de software koper haar testaanpak en testdiepgang aanpassen. Is er sprake van maatwerk op het ERP pakket, hoe vind de oplevering plaats? Is het reeds functioneel getest in de systeemtest(en) door de leverancier, dan kan het maatwerk mee in de testcyclus alsof het maatwerk onlosmakelijk bij het pakket hoort. Anders zal het testen met meer diepgang (en zorg) moeten plaatsvinden. Een ondergeschoven kind tijdens de implementatie van ERP pakketten is de dataconversie van de oude masterdata naar de nieuwe masterdata. Welke data wordt overgezet en welke conversies vinden plaats om de data passend in het nieuwe systeem te krijgen, zodat de data correct kan worden verwerkt. Hoe komen bijvoorbeeld orders die halverwege het orderproces zijn tijdens het migratie correct in het nieuwe systeem zodat ze niet blijven hangen maar verder verwerkt kunnen worden. Niet alleen is het nodig te controleren of een pakket de bedrijfsprocessen ondersteund, maar ook of de prestaties voldoende zijn. Denk bijvoorbeeld aan reactietijden van de invoer en opvraag schermen. Of aan de snelheid waar mee een batch proces verloopt. Tuning van een ERP systeem en de bijbehorende database vereist de nodige aandacht. Daarnaast kan er vanuit verschillende kanten naar beveiliging gekeken worden. Is de toegang tot de applicatie beveiligd en hoe? Heeft het ERP pakket een webinterface welke ook vanaf internet te benaderen valt, zal hier anders naar gekeken moeten worden dan indien het pakket alleen binnen het bedrijf zelf te gebruiken is. Onderdeel van beveiliging is ook autorisaties en toegangsverlening. Is dit logisch opgezet, wordt het 4 ogen principe toegepast en zijn er eventueel signaleringen voor afwijkende transacties? Denk hierbij niet alleen aan afwijkende financiële transacties maar ook aan voorraadcorrecties.

11 Organisatie SYSQA B.V. Pagina 11 van 12 Als de verificatie en validatie succesvol zijn afgerond kan een (laatste) proefconversie plaatsvinden en kan het schaduwdraaien beginnen. Het vergelijken van het oude met het nieuwe systeem waarbij ze parallel in gebruik zijn. Het doel is een laatste controle of het nieuwe pakket daadwerkelijk hetzelfde werkt als het oude systeem. De keuze om terug te gaan naar het oude pakket is dan eenvoudig en doorgaan met het nieuwe pakket ook. In de beheerfase komen vanuit de pakketleverancier mogelijk patches en servicepacks. Hiervoor zal de organisatie een (test)aanpak moeten kiezen die aansluit op de wijze waarop de pakketleverancier de software oplevert Case Bij een verzekeringsmaatschappij heeft SYSQA ondersteund bij het inrichten van het testen voor een migratieproject. De klant ging van pakket A naar Pakket B. Beide pakketten zijn van verschillende leveranciers. De leverancier van het nieuwe pakket heeft aangegeven dat de software voor oplevering wordt getest. Ook de klant had behoefte om vast te stellen dat de leverancier zich aan de gestelde afspraken hield. Samen met de leverancier en de opdrachtgever is een testmanager van SYSQA gaan afstemmen wie welke testsoorten uit gaat voeren, welke delen van het systeem daarmee worden geraakt en welke deliverables de verschillende testsoorten moeten opleveren. Samen hebben ze de teststrategie voor het project opgesteld, de testmanager heeft dit vervolgens in een Mastertestplan verwerkt, waar beide partijen een akkoord op hebben gegeven. Door deze afstemming is onnodig dubbel werk voorkomen en heeft ook de klant aan gegeven waar voor zijn organisatie de belangrijkste delen en functionaliteiten zijn. Op deze manier hebben zowel de opdrachtgever als de leverancier tijd en geld uitgespaard doordat de focus alleen op de grootste risico s lag en dubbel werk zoveel mogelijk is voorkomen. 5.2 Methoden voor testen Het testen van software heeft zich de afgelopen 20 jaar ontwikkeld tot een volwassen tak van de ICT dienstverlening. In de loop van de tijd zijn hiervoor meerdere methoden ontwikkeld, de belangrijkste binnen dit vakgebied worden in dit hoofdstuk behandeld ISTQB ISTQB ziet ERP software als standaard software (COTS / Commercial of the shelf) welke door de koper aan een integratietest en waar nodig aan een acceptatietest wordt onderworpen. Door het toepassen van een bruikbaarheidstest (usability testing) kan de inpasbaarheid van het pakket en de configuratie gecontroleerd worden. Het testen van kritische bedrijfsprocessen kan door middel van nauwkeurigheidstesten (accuracy testing). Dataconversies kunnen aan een nauwkeurigheidstest en een bruikbaarheidstest worden onderworpen.

12 Organisatie SYSQA B.V. Pagina 12 van TMap Next Vanuit TMap Next zijn de volgende testontwerptechnieken bruikbaar, deze worden in de introductie testontwerptechnieken TMap Next op de SYSQA kennisbank nader uitgewerkt. Procescyclustest om de inpasbaarheid van het pakket te testen. Om de integratie van kritische bedrijfsprocessen, met name het snijvlak logistiek en financieel te testen, is de gegevenscyclustest bruikbaar. Door de complexiteit van de verschillende authorisaties kan dit leiden tot een hogere testinspanning dan de procescyclustest. Voor dataconversies kan de gegevenscyclustest worden toegepast, gevolgd door een procescyclustest om te valideren dat de geïmporteerde data kan worden toegepast in de verschillende bedrijfsprocessen. De testtechniek real life test kan een goede basis vormen om de prestaties van het pakket en de inrichting hiervan zo dicht mogelijk bij de (verwachte) realiteit te meten Case Een organisatie zat met een dilemma, welke testmethodiek past het beste bij de organisatie. Een testconsultant van SYSQA heeft voor de klant een aantal methoden naast elkaar gehouden en daarbij gekeken wat de wensen en richtlijnen binnen de organisatie waren. Het antwoord op deze vraag is relatief eenvoudig te geven, want beide methoden hebben sterke punten. In het advies van de testconsultant stond dan ook welke delen van welke methoden het beste bij de organisatie paste, hierdoor ontstond een hybride testmethodiek die bij de organisatie paste en waar duidelijke afspraken zijn vastgelegd over de gebruikte terminologie.