MCTL - Managing Computer Technology Library

Maat: px
Weergave met pagina beginnen:

Download "MCTL - Managing Computer Technology Library"

Transcriptie

1 16. TAAKGEBIED TESTEN Testen is een vakgebied dat werkzaamheden omvat die zich uitstrekken van diep in de techniek tot diep in de gebruikersorganisatie. Binnen MCTL wordt uitsluitend het functionele deel in ogenschouw genomen. De invalshoek binnen MCTL is niet het gewijzigde systeem, maar de wijzigingen in het bedrijfsproces. Dit businessperspectief betekent dat er getest wordt vanuit een beoogd gewijzigde werkwijze / bedrijfsproces in samenhang met de daarvoor aangepaste computertechnologie: software, databases en/of hardware. ACHTERGROND Testen kan worden gezien als onzekerheidsreductie. Goed beschouwd zou met precies de juiste input en de precies de juiste uitvoering van de aanpassingen, testen overbodig zijn. Helaas kan vanaf het moment dat een wijziging wordt geïnitieerd tot en met realisatie van alles mis gaan. Via testen is alleen in theorie 100% zekerheid te krijgen dat de gerealiseerde wijziging 100% correct is. Praktisch gesproken is dat niet zo, maar testen kan wel aantonen dat bepaalde aspecten in orde zijn. Hoe beter de testomgeving, hoe beter de testdata, testscript en het testteam, hoe hoger de zekerheid dat de gerealiseerde wijziging ook aan de verwachting voldoet. DEFINITIES Binnen het taakgebied testen worden enige termen gebruikt die ook wel in de praktijk voorkomen. Helaas wil er zeker op het gebied van testen nog wel eens verwarring zijn over welke term waarvoor staat. Daarom worden ze hieronder gedefinieerd: Definitie Toetsen Toetsen is het beoordelen van tussenproducten in het gehele wijzigingstraject Definitie Testen Testen omvat activiteiten die inzicht geven in en adviseren over de kwaliteit van eindproducten en de daaraan gerelateerde risico s Definitie Functionele acceptatietest (FAT) De functionele acceptatietest is een door functioneel specialisten uitgevoerde test in een zoveel als mogelijk op de productieomgeving gelijkende omgeving. Deze test moet aantonen dat de uitgevoerde wijzigingen aan de functionele eisen voldoen Definitie Gebruikersacceptatietest (GAT) De gebruikersacceptatietest is een door (een vertegenwoordiging van) de toekomstige gebruikers uitgevoerde test in een zoveel als mogelijk op de productieomgeving gelijkende omgeving. Deze test moet aantonen dat de uitgevoerde wijzigingen aan de wensen / eisen van de gebruikers voldoen Definitie Productieacceptatietest (PAT) De productieacceptatietest is een door (een vertegenwoordiging van) de toekomstige beheerders uitgevoerde test in een zoveel als mogelijk op de productieomgeving gelijkende omgeving. Deze test V1.0 Pagina 1

2 moet aantonen dat de uitgevoerde wijzigingen aan de wensen / eisen vanuit beheer voldoen. Beheer kan hierbij zowel de technische als functionele kant betreffen, hoewel de nadruk vaak sterk op de technische kant ligt. Definitie Acceptatiecriteria Acceptatiecriteria zijn meetbare condities waaraan voldaan moet zijn om een aangepast systeem in productie te nemen. Het opstellen en onderhouden van acceptatiecriteria vindt plaats in kwaliteitsmanagement. Het taakgebied Testen is een belangrijke gebruiker van de acceptatiecriteria. DOEL VAN DIT TAAKGEBIED Testen omvat het controleren of de gerealiseerde wijzigingen aan de gedefinieerde behoefte en specificaties voldoen en daarnaast aan de gestelde kwaliteitsnormen en vanzelfsprekende (dus niet expliciet gedefinieerde) behoeften en specificaties. HOE WEET JE DAT HET DOEL IS BEREIKT? De volgende indicatoren zijn te benoemen om te weten of bovenstaande doel wordt bereikt: Het aantal fouten dat is geconstateerd nadat de wijzingen in productie zijn genomen is < 2 % van het aantal bevindingen dat in de verschillende tests is geconstateerd en verholpen De totaal aan tests bestede tijd / hoeveelheid geld is < 50% van de schade die zou zijn ontstaan in productie indien de bevindingen in test niet al voor productie waren hersteld. (Genoemde percentages zijn uiteraard indicatief) INPUT, ACTIVITEITEN, OUTPUT De activiteiten in dit taakgebied zijn als volgt schematisch weer te geven: V1.0 Pagina 2

3 Toetsen vind plaats op de diverse tussenproducten en testen op de diverse eindproducten. Hierna worden ze toegelicht. 1. TOETSEN SPECIFICATIES EN OPGELEVERDE ONTWERP-PRODUCTEN Toetsen, het controleren van tussenproducten, kent verschillende technieken. Degenen die het meest bruikbaar zijn in de context van MCTL zijn: 1. Inspecties. Hierbij wordt een product beoordeeld dat 100% gereed is, maar nog niet definitief is vastgesteld. Door een team van mensen wordt vooraf gestructureerd gezocht naar bevindingen in de te inspecteren documenten. Tijdens de inspectiebijeenkomst worden deze bevindingen besproken en dient er overeenstemming over te ontstaan. Ook nieuwe bevindingen, die tijdens de bijeenkomst ontstaan, worden besproken en ook daarover dient overeenstemming te ontstaan. Na de bijeenkomst past de auteur het document aan en kan eventueel een herinspectie plaatsvinden. 2. Reviews. Reviews worden gedaan op producten die nog niet helemaal af zijn (60-80% gereed). Een review richt zich op het vinden van fouten, maar ook op het verbeteren van het document door de kennis en vaardigheden van degenen die de review uitvoeren. Ze mogen zich dus ook met de oplossingsrichtingen bemoeien en voorstellen voor verbetering doen. 3. Walkthrough. Bij een walkthrough wordt het document, dat voor % gereed is, stapsgewijs doorlopen. Daarbij kan de auteur een toelichting en bijvoorbeeld ook de keuzemogelijkheden en overwegingen daarin geven. De andere deelnemers kunnen direct reageren. Het is een erg interactieve manier van werken, waarbij wel het gevaar van ad-hoc discussies bestaat. Aan de hand van bovenstaande schema zijn de volgende toetsmomenten te definiëren: Requirements management / specificaties Het achterhalen van requirements en vervolgens opstellen van specificaties is het onderdeel waarin het het meest zinvol is om input te krijgen uit zo veel mogelijk relevante bronnen. Ook bij toetsen is het mogelijk via reviewen en walkthroughs niet alleen fouten te achterhalen, maar ook inzichten van degenen die deelnemen aan de review cq. walkthrough mee te nemen. Bovendien kan hier door anderen worden gecheckt of niet te snel naar één bepaalde uitwerking / oplossing is toegewerkt, of consequenties per oplossingsrichting inderdaad allemaal in beeld zijn en afgewogen, en of er ook vanuit de infra en support groep en evt. leverancier voldoende inbreng is geweest. Ontwerp In ontwerp worden een aantal modellen, diagrammen en beschrijvingen bijgewerkt op basis van de in Requirements management opgestelde specificaties. Deze bijgewerkte ontwerp-elementen kunnen via inspectie worden getoetst. Eventueel, indien bijvoorbeeld een onderdeel van het systeem nieuw is of sterk wordt gewijzigd, kan ook via reviews en walkthroughs het toetsteam meer worden betrokken in de oplossingen en worden gevraagd hierin mee te denken. De inhoudelijke controle op juistheid en volledigheid dient echter altijd de overhand te houden. Realisatie Hier kan een check worden uitgevoerd of alle (gewijzigde) configuratie-instellingen en parameters zijn beschreven (volledigheid) en vanzelfsprekend ook juist zijn. Tevens is een check op onderlinge V1.0 Pagina 3

4 strijdigheid en ook op aannemelijkheid (m.n. als bijv. parameters heel sterk wijzigen, of de onderlinge verhoudingen tussen de parameters sterk wijzigen) een aan te bevelen activiteit. Inspectie is een hiervoor de hand liggende techniek. Transitie In het taakgebied transitie wordt een transitieplan opgesteld. Binnen Testen kan het bijgewerkte transitieplan worden getoetst voordat dit plan binnen Transitie wordt uitgevoerd. Ook hier kan inspectie goede resultaten opleveren. Eindresultaat is steeds een gestructureerde terugkoppeling aan de opstellers van de specificaties, ontwerpen, plannen etc. Afhankelijk van de omvang en aard van de terugkoppeling kan worden afgesproken dat de aanmerkingen worden verwerkt en nogmaals getoetst, of dat een hertoetsing niet nodig is. 2. CHECK OP DOOR DE INFRA EN APPLICATIE SUPPORT EN LEVERANCIERS UITGEVOERDE TESTS Het echte testen start met een check op de door de infra en applicatie support en leveranciers uitgevoerde tests. In TMap termen spreken we dan van de Unittest (UT), de Unitintegratietest (UIT) en de Systeemtest (ST). In het geval er binnen infra en applicatie support een agile-achtige werkwijze wordt gevolgd, zijn de verschillende tests soms wat minder eenvoudig te onderscheiden. Voorop blijft staan dat iemand die iets creëert (in dit geval bijvoorbeeld een programmeur), allereerst ook zijn eigen werk zal moeten controleren. Daarna pas komen degenen in beeld die het resultaat van dit werk uiteindelijk ook zullen gaan gebruiken (gebruikers en de functioneel specialisten). Tevens speelt hier wel mee dat een infra en applicatie support en leveranciers vaak wat andere faciliteiten ter beschikking hebben dan een gebruikersorganisatie. Voorbeelden hiervan zijn tools waarmee rechtstreeks data in een testdatabase kan worden gemanipuleerd en het simuleren van een grote workload op een systeem. Van infra en applicatie support en leveranciers mag worden verwacht dat de unittest, de unitintegratietest en de systeemtest voldoende worden uitgevoerd. Binnen deze testsoorten kunnen verschillende testvormen worden onderscheiden. Uiteraard moeten de wijzigingen op zichzelf, zowel technisch als tot op zekere hoogte functioneel, door infra en applicatie support en leverancier worden getest. Daarnaast zijn nog te noemen: de back-up & restore test, de technische conversietest, de penetratie/beveiligingstest, herstartbaarheidstest, installatietest, de-installatietest en uitwijktest (zie aan het eind van dit taakgebied een uitgebreidere beschrijving van alle testsoorten en testvormen). De scheidslijn van waar de verantwoordelijkheden van infra en applicatie support en leverancier ophoudt en die van de functioneel support cq gebruikersorganisatie begint is nog niet zo heel makkelijk te bepalen. Een aantal voorbeelden ter illustratie: Een softwareleverancier voert regelmatig updates uit op de software die zij levert. Omdat zij niet tot in den treure op de hoogte is van alle specifieke klantomgevingen, hebben zij een interne referentieomgeving opgetuigd. Het zal duidelijk zijn dat deze softwareleverancier wel kan worden aangesproken op het juist functioneren van de software (technisch en functioneel) in die V1.0 Pagina 4

5 referentieomgeving, maar niet in een klantomgeving die hiervan afwijkt. Een softwareleverancier levert via een cloudoplossing feitelijk geen softwaresysteem meer, maar een werkende functionaliteit. In dit geval kan deze leverancier zeker worden aangesproken op het technisch en functioneel volledig juist functioneren van het geheel. Een klantorganisatie besluit een standaardsoftwarepakket functioneel geheel afwijkend in te zetten in de organisatie. Infra en applicatie support en leverancier doet aanpassingen op het pakket, maar de klantorganisatie zal zelf moeten controleren of de afwijkende werkwijze na die aanpassingen nog steeds wordt ondersteund door het pakket. Om duidelijkheid te scheppen in de scheiding tussen werkzaamheden van infra en applicatie support en leverancier enerzijds en functioneel support en de gebruikersorganisatie anderzijds kan met een zogenaamde intake worden gewerkt. Op het moment dat door de van infra en applicatie support en leveranciers iets wordt opgeleverd, wordt door functioneel support een intake gedaan waarbij een aantal vooraf vastgestelde elementen worden gecheckt. Op die wijze is al snel duidelijk of de oplevering retour afzender kan worden gestuurd, of dat functioneel support met de functionele acceptatietest aan de slag kan gaan. Het is immers niet de bedoeling dat functioneel specialisten en / of gebruikers testen gaan uitvoeren die feitelijk door infra en applicatiesupport of leveranciers hadden moeten worden gedaan. 3. FUNCTIONELE ACCEPTATIETEST In het algemeen wordt de functionele acceptatietest uitgevoerd door functioneel specialisten. De omgeving waarin de test wordt uitgevoerd lijkt zoveel als mogelijk op de uiteindelijke productiesituatie. Er dient een testplan te zijn opgesteld waarin de planning, de te testen onderdelen en een beschrijving van de testscripts en testdata zijn opgenomen. Input voor dit testplan komt uit de taakgebieden Requirements management en Ontwerp. Daarnaast dienen de acceptatiecriteria uit het taakgebied Kwaliteitsmanagement ter beschikking te staan. De functionele acceptatietest moet aantonen dat de uitgevoerde wijzigingen aan de functionele eisen voldoen. Er wordt dus getest ten opzichte van de gedefinieerde en gespecifieerde eisen in Requirements management en Ontwerp. De volgende testvormen komen in de functionele acceptatietest voor: 1. Functionaliteit Een allereerst uit te voeren test is of de functionaliteit overeenstemt met het ontwerp. Specifiek kan hier nog worden gekeken naar een ordentelijke foutafhandeling. 2. Regressietest Bij een regressietest wordt met name aandacht besteed aan de niet gewijzigde onderdelen. Het is een berucht fenomeen bij testen; de wijzigingen zijn in orde, maar uiteindelijk blijkt in productie een niet-gewijzigd onderdeel niet meer te functioneren. Veelal wordt dit veroorzaakt doordat de samenhang van systemen onvoldoende bekend is en daardoor de scope van de te V1.0 Pagina 5

6 testen onderdelen te nauw wordt genomen. Ook kan nog meespelen dat de aandacht bij de testers wat is verslapt omdat er via deze test betrekkelijk weinig fouten worden gevonden, en het dus minder relevant lijkt te zijn. Tot slot kan ook de motivatie van de testers ook wat lager zijn omdat bijv. basisonderdelen veelvuldig moeten worden getest die maar weinig interessant / uitdagend zijn. 3. Integratie / ketentest Bij een ketentest wordt het systeem in samenhang met andere systemen (de keten ) getest. Daarbij kan het zowel in- als externe andere systemen betreffen. Het opzetten van deze test kan lastig zijn omdat het behoorlijke eisen stelt aan de testomgeving. Bij koppelingen met systemen van externe partijen moet idealiter de totale testomgeving zich ook tot die externe partijen uitstrekken. In het geval een dergelijke testomgeving niet is op te tuigen kunnen de interfaces met bepaalde systemen ook worden gesimuleerd. Simulatie blijft echter feitelijk een suboptimale oplossing omdat de testomgeving als uitgangspunt moet hebben dat deze zoveel mogelijk op de werkelijke productieomgeving moet lijken. Bijzonder aandachtspunten bij de integratie / ketentest zijn de controle op input, output en beveiliging van het systeem en de gegevensstromen; komen geen gegevens op de verkeerde plaats terecht, staan de gegevens juist en tijdig als input ter beschikking, of andersom, worden ze tijdig ter beschikking aan een ander systeem gesteld? Daarnaast kan er ook sprake zijn van functionele integratie, waarbij een bepaalde functionaliteit technisch in samenstelsel van meerdere systemen wordt gerealiseerd. Indien in een deelfunctionaliteit van een van de systemen dan een wijziging plaatsvind, moet vervolgens de gehele functionaliteit worden getest. Een systeemdoorlooptest, waarbij zoals de naam al aangeeft het hele systeem wordt doorlopen, kan hier grote diensten bewijzen. 4. Beschikbaarheidstest Bij een beschikbaarheidstest wordt getest of een systeem langdurig goed blijft werken. Het doet denken aan de duurtests die ook wel worden uitgevoerd op fysieke producten om te zien of materialen langdurig tegen een bepaalde belasting bestand zijn. 5. Conversietest Indien van toepassing kan worden getest of de conversie goed verloopt. Een conversie kan zowel betrekking hebben op het converteren van gegevens in hetzelfde systeem, als het overzetten van gegevens van een oud naar een nieuw systeem. 6. Documentatie Bij deze test wordt specifiek gekeken naar de wijzigingen in de documentatie die voor het gebruik van het systeem bedoeld is. Is de documentatie correct, volledig, begrijpelijk? 7. Limiettest In de limiettest wordt gekeken naar kritische parameters en andere limieten waarbinnen het systeem moet functioneren. Ook het testen van het gedrag van het systeem zodra de limieten worden overschreden wordt in de limiettest meegenomen. Doorgaans moeten hier specifieke testgevallen voor worden gemaakt, omdat als het goed is in de productiedatabase geen gevallen aanwezig zijn die buiten de systeemlimieten vallen. Er kan in dit geval dus niet worden teruggevallen op testgevallen die uit productie zijn overgenomen. V1.0 Pagina 6

7 8. Muli-user Een test of het systeem toegankelijk is voor meerdere personen tegelijkertijd zonder dat daardoor problemen ontstaan, zoals bijvoorbeeld locking. Niet elke testvorm hoeft elke keer even relevant te zijn. Het is dus mogelijk sommige testvormen te combineren bij een relatief beperkte test, of testvormen geheel weg te laten. Uiteraard, maar dat is wel een open deur, moeten testvormen alleen worden weggelaten in de testfase omdat ze niet nodig zijn, en niet uit tijdgebrek. 4. GEBRUIKERSACCEPTATIETEST In het algemeen wordt de gebruikersacceptatietest uitgevoerd door gebruikers en key-users, met ondersteuning van functioneel specialisten. De omgeving waarin de test wordt uitgevoerd lijkt net zoals bij de functionele acceptatietest zoveel als mogelijk op de uiteindelijke productiesituatie. Eveneens dient, precies zoals ook bij de functionele acceptatietest beschreven, een testplan te zijn opgesteld, waarin de planning, de te testen onderdelen en een beschrijving van de testscripts en testdata zijn opgenomen. Daarnaast dienen ook hier de acceptatiecriteria ter beschikking te staan. De gebruikersacceptatietest moet aantonen dat de uitgevoerde wijzigingen aan de wensen / eisen van de gebruikers voldoen. Er wordt dus getest ten opzichte van oorspronkelijke behoeften van de gebruikers. Deze behoeften zijn in Requirements management zo goed mogelijk gespecificeerd en daarna ook nog eens gevalideerd. Toch kan ook daar, in die fase, al veel zijn misgelopen. Het probleem van het testen ten opzichte van de oorspronkelijke behoeften is in de praktijk vaak dat die behoeften wat vaag zijn, en niet meetbaar en controleerbaar zijn beschreven. Een voorbeeld ter illustratie: Een manager wil de efficiency van een afdeling graag verhogen. Op de afdeling worden diverse administraties gevoerd, maar er is ook een klein onderdeel advisering. De gedachte is dat door meer inzet van computertechnologie in het onderdeel administratievoering, daar FTE s worden bespaard die in het groeiende onderdeel advisering kunnen worden ingezet. Met als gevolg: met dezelfde personele bezetting kan een hogere output worden bereikt. De administratieve processen worden grondig bekeken en al snel worden diverse oplossingen gedefinieerd waarmee naar verwachting arbeidstijd kan worden bespaard. Te denken is bijv. aan het wegwerken van de laatste papieren formulieren, het beter koppelen van diverse systemen, het verbeteren van user interfaces die veel worden gebruikt en ook sommige handmatige controles kunnen worden geautomatiseerd. Een en ander wordt helder uitgewerkt in requirements en ontwerpdocumenten en ook zonder al te veel problemen gerealiseerd. Tijdens de functionele acceptatietest blijkt ook inderdaad dat alle onderdelen precies conform de functionele eisen zijn aangepast; de koppelingen functioneren, alle formulieren zijn gedigitaliseerd, user interfaces zijn sterk verbeterd en precies op de aangegeven plaatsen zijn handmatige handelingen verdwenen. Helaas blijkt bij het checken op de benodigde doorloop- en werktijd voor een gehele administratieve transactie, dat de gewenste tijdsbesparing (nog) niet wordt behaald. Met andere woorden: het wijzigingstraject op zichzelf loopt helemaal niet slecht, en zouden de wijzigingen op deze manier in V1.0 Pagina 7

8 productie genomen dan zal er naar verwachting technisch en functioneel niet al te veel fout gaan. Maar het achterliggende doel: arbeidstijd besparen in de administratieve processen, wordt helaas niet behaald. De testvormen die in de functionele acceptatietest zijn beschreven en ook bij de gebruikersacceptatietest voorkomen zijn: 1. Functionaliteit 2. Beschikbaarheid 3. Conversietest 4. Documentatie 5. Keten- cq integratietest 6. Regressietest De testvormen specifiek voor de gebruikersacceptatietest zijn: 1. Usability test Bij de usability test wordt het werkelijke gebruik van het systeem getest door een groep gebruikers. Onder andere kan dan worden gekeken naar de gebruikersvriendelijkheid: schermopbouw, begrijpelijkheid, ondersteuning door aanvullende teksten, etc. Het kan bijvoorbeeld worden uitgevoerd door gebruikers een bepaalde uit te voeren taak te geven en de gebruikers te verzoeken hardop al hun gedachten uit te spreken bij elke handeling die zij doen. Ook wordt wel gebruik gemaakt van eye tracking software, waarbij wordt gevolgd waar iemand precies naar kijkt op het scherm. Ook is het mogelijk de tijd op te nemen, zodat duidelijk wordt waar haperingen optreden en dus kennelijke onduidelijkheden zijn. In het geval een gebruikersgroep niet direct beschikbaar is (bijvoorbeeld bij een website) kan voor remote usability testing worden gekozen, waarbij op afstand gebruikers wordt gevraagd deel te nemen. Ook A/B testen komt dan in beeld, waarbij twee verschillende versies naast elkaar worden getest om te bepalen welke user interface de beste resultaten geeft. 2. Load- / stresstest Bij een load / stresstest wordt het systeem getest of het bestand is tegen grote aantallen medewerkers, gegevens en / of transacties. Natuurlijk moet hier een maximum zijn gedefinieerd en tot het maximum moet het systeem conform verwachting functioneren. Daarboven moet het gecontroleerd stoppen of anderszins reageren (zoals bijv. bij een website, die bij overschrijding van max. aantal bezoekers niet onderuit gaat maar de bezoekers boven de limiet een boodschap voorschotelt). Probleem bij deze test is doorgaans dat deze in een gebruikersacceptatietest omgeving moeilijk is uit te voeren: het benodigde aantal gebruikers is niet voorhanden, en grote aantallen transacties zijn ook moeilijk te forceren. Daarom wordt deze test in de praktijk ook wel door infra en applicatie support en / of leverancier uitgevoerd, waarna de daar genoteerde resultaten tijdens de gebruikersacceptatietest worden gecontroleerd. 3. Scenario testen Hierbij wordt via scenario s het bedrijfsproces gesimuleerd. Aldus is te constateren of niet alleen het gewijzigde systeem, maar ook het bedrijfsproces conform verwachting functioneert. V1.0 Pagina 8

9 Bij gebruikersacceptatietesten zijn de volgende praktijkopmerkingen te maken: Bij een gebruikersacceptatietest moeten eindgebruikers worden betrokken. Dat lijkt een voor de hand liggende zaak, maar is in de praktijk niet altijd eenvoudig uitvoerbaar. De juiste gebruikers moeten worden betrokken, die dan ook voldoende tijd ter beschikking hebben. Met juist wordt bedoeld dat niet alleen de beste gebruikers uit een gebruikersgroep worden betrokken, maar juist ook gebruikers met een lager kennisniveau en minder computervaardigheden. Dat maakt een test weliswaar lastiger, maar de zekerheid dat het systeem ook in productie zal doen wat het moet doen en zal worden gebruikt zoals het moet worden gebruikt, neemt vanzelfsprekend fors toe. De faciliteiten waarmee gebruikers moeten testen moeten in orde zijn. Niets is zo vervelend en frustrerend als gebrekkige faciliteiten, of omgevingen die afwijken van de uiteindelijke productiesituatie. De verwarring die dat schept kan een test volledig frustreren en de aandacht ook wegzuigen van waar de test eigenlijk werkelijk om draait. De ondersteuning vanuit functioneel specialisten is zonder meer nodig. Het betekent echter niet dat functioneel specialisten de test overnemen! Maar bij problemen met de omgeving waarin wordt getest kan een functioneel specialist doorgaans makkelijker ingrijpen en samen met infra en applicatie support en leverancier een en ander oplossen. Ook bij constatering van fouten kan een Functioneel specialist (beheerder) een oogje in het zeil houden: zijn het echte fouten, of worden zij bijvoorbeeld veroorzaakt door een (oude) werkwijze die niet meer van toepassing is? Voorkom te weinig èn teveel fouten. Het is een lovenswaardig streven om ervoor te zorgen dat tijdens een gebruikersacceptatietest niet te weinig, maar ook niet teveel fouten worden gevonden. Indien elke keer al tijdens eerdere tests zo grondig is getest, dat tijdens de gebruikersacceptatietesten vrijwel niets meer wordt gevonden, zal de gebruikersgroep in reactie daarop steeds minder gaan testen vanwege de zinloosheid ervan. Aan de andere kant, als het aantal fouten bij de gebruikers tijdens het testen erg hoog is, is er het risico van het ontstaan van een negatieve sfeer. Het idee kan ontstaan dat het niets is en ook niet kan worden. Omdat de gebruikers die testen ook gewoon op de werkvloer werken kan dat ook daar al snel gaan rondzingen. Al met al moet dus, hoe gek het ook klinkt, het aantal fouten tijdens de gebruikersacceptatietest worden gedoceerd. Al lijkt het erop dat het aantal fouten toch geheel en al uit de hand loopt, kan desnoods de gebruikersacceptatietest worden afgebroken. Vervolgens worden eerst voorgaande tests beter uitgevoerd en fouten opgelost V1.0 Pagina 9

10 waarna de gebruikersacceptatietest kan worden herstart. 5. PRODUCTIEACCEPTATIETEST De productieacceptatietest is een door (een vertegenwoordiging van) de toekomstige beheerders uitgevoerde test in een zoveel als mogelijk op de productieomgeving gelijkende omgeving. Deze test moet aantonen dat de uitgevoerde wijzigingen aan de wensen / eisen vanuit beheer voldoen. De nadruk bij een productieacceptatietest ligt in het algemeen sterk aan de technische kant. Toch dient er vanuit de positie van de functioneel specialisten op twee manieren aandacht binnen deze test te zijn. Ten eerste dienen ook functioneel specialisten hier zichzelf af te vragen, en dus ook te testen, of het systeem functioneel wel te beheren is. Bijvoorbeeld het ontbreken van bijgewerkte handleidingen, rammelende workflows of niet bijgewerkte helpteksten zijn wellicht voor gebruikers nog wel overkomelijk, dat moeten zij in de gebruikersacceptatietest natuurlijk zelf beoordelen. Maar Functioneel specialisten moeten daar vanuit de optiek van het leveren van ondersteuning ook een oordeel over vellen. Bovendien houden functioneel specialisten intern vaak ook documenten en tools bij die gebruikt worden ter ondersteuning. Zijn deze inderdaad ook bijgewerkt en kunnen die ook worden ingezet nadat bij gebruikers het gewijzigde systeem in productie is gekomen? Ten tweede kunnen aan de technische zijde tijdens de productieacceptatietest bevindingen worden gedaan, en daaropvolgend beslissingen worden genomen, die functionele impact hebben. In dit soort situaties is op zijn minst overleg tussen infra, applicatief en functioneel support nodig en moet er gezamenlijk naar de bevindingen worden gekeken. Hoewel technische perikelen roet in het eten kunnen gooien en deze testfase al vlak voor de inproductiename ligt met alle tijdsdruk van dien, moeten ook nu de belangen van de gebruikers blijven prevaleren. De testvormen specifiek voor de productiesacceptatietest zijn: 1. Back-up & restore test Het testen of de back-up en restore nog goed functioneert. De test wordt uitgevoerd door infra support, maar door functioneel specialisten wordt een controle uitgeoefend 2. Herstartbaarheid Is het systeem herstartbaar na (onverwachte) uitval? Uit te voeren door infra support, functioneel is er aandacht voor inconsistentie in gegevens, gegevensverlies en goede foutafhandeling 3. Installatie / de-installatietest Hierbij wordt functioneel gekeken naar de volledigheid en juistheid van de installatie (is niets vergeten, komen alle updates bij precies de juiste gebruikersgroep terecht?) en de-installatie (komt het oude systeem precies zoals het was weer in de lucht? Kunnen we met het oude systeem doorwerken?) V1.0 Pagina 10

11 4. Load- / stresstest Zie voor toelichting de hiervoor beschreven gebruikersacceptatietest. 5. Performance Voldoet het systeem aan de performance eisen. 6. Uitwijktest Functioneert uitwijk nog conform de afspraken? Ook hier is vooral aandacht voor de functionele aspecten: komt het gewijzigde systeem in geval van uitwijk binnen de gestelde tijd weer beschikbaar, zijn er geen negatieve gevolgen voor andere systemen, is het inderdaad mogelijk in uitwijksituatie met het systeem te werken, is inwijk (terugkeren naar de gewone werksituatie) nog steeds mogelijk? Sommige testvormen komen hier voor terwijl ze ook al bij eerdere testsoorten zijn genoemd. In de PAT ligt de focus vanzelfsprekend anders dan in de FAT of de GAT. 6. OPSTELLEN VRIJGAVE ADVIES / VERBETERPUNTEN Nadat alle tests zijn afgerond wordt een vrijgave advies opgesteld. Het betekent niet dat op dat moment alle geconstateerde bevindingen moeten zijn opgelost. Er kan voor worden gekozen om ondanks het feit dat er nog openstaande bevindingen zijn toch te adviseren de wijzigingen in productie te nemen. In het advies worden de eventueel nog openstaande bevindingen vermeld inclusief de consequenties daarvan voor de productieomgeving. Tevens kunnen in het vrijgave advies afspraken over later op te lossen bevindingen worden vermeld. Tevens kunnen op dit moment de verbeterpunten die in het hele toets- en testtraject zijn geconstateerd bij elkaar worden gebracht en gedocumenteerd voor later gebruik. Ook indien het toetsen testtraject op zichzelf naar volle tevredenheid is verlopen kunnen er vanzelfsprekend nog steeds verbeterpunten zijn. Toch is een waarschuwing wel op zijn plaats: er moet hier niet worden gestreefd naar het perfecte, maar naar het optimale. En die zijn veelal niet gelijk aan elkaar. OPMERKINGEN De volgende opmerkingen zijn te maken over dit taakgebied: 1. TESTSOORTEN EN -VORMEN In de wereld van het testen worden veel termen door elkaar gebruikt. Hieronder worden de testsoorten en -vormen die in TMap worden beschreven opgesomd. De testvormen kunnen binnen de verschillende testsoorten worden gebruikt om deze in te vullen. Doorgaans is een bepaalde testvorm daarom binnen meerdere testsoorten terug te vinden. De testsoorten: - Unittest (UT): Test door ontwikkelaar in ontwikkelomgeving, check op technisch goed functioneren van een unit (individuele wijziging) V1.0 Pagina 11

12 - Unitintegratietest (UIT): Test door ontwikkelaar in ontwikkelomgeving, check op technisch goed functioneren van een logische groep units (aantal wijzigingen, bijv. in een release) - Systeemtest (ST): Test door leverancier in laboratoriumomgeving uitgevoerde test van het systeem t.o.v. de niet-functionele en functionele specificaties en het technisch ontwerp - Systeemintegratietest (SIT): Een door de toekomstige gebruiker uitgevoerde test op de systeeminterfaces in een zoveel mogelijk op productie gelijkende omgeving - Functionele acceptatietest (FAT): Een door functioneel specialisten uitgevoerde test in een zoveel als mogelijk op de productieomgeving gelijkende omgeving. Deze test moet aantonen dat de uitgevoerde wijzigingen aan de functionele eisen voldoen - Gebruikersacceptatietest (GAT): Een door (een vertegenwoordiging van) de toekomstige gebruikers uitgevoerde test in een zoveel als mogelijk op de productieomgeving gelijkende omgeving. Deze test moet aantonen dat de uitgevoerde wijzigingen aan de wensen / eisen van de gebruikers voldoen - Productieacceptatietest (PAT): Een door (een vertegenwoordiging van) de toekomstige beheerders uitgevoerde test in een zoveel als mogelijk op de productieomgeving gelijkende omgeving. Deze test moet aantonen dat de uitgevoerde wijzigingen aan de wensen / eisen vanuit beheer voldoen. Beheer kan hierbij zowel de technische als functionele kant betreffen, hoewel de nadruk vaak sterk op de technische kant ligt. Een aantal testvormen (niet volledig, de meest voorkomende): - Back-up & restore test: Testen of back-up proces correct functioneert - Beschikbaarheid: Blijft het systeem langdurig correct werken? - Conversietest: Test op conversie van met name gegevens - Documentatie: Controle op volledigheid, juistheid, begrijpelijkheid - Functionaliteit: Is de functionaliteit overeenkomstig het ontwerp? - Hackerstest / penetratietest: Test op mogelijkheid om van buitenaf het systeem oneigenlijk te gebruiken - Herstartbaarheid: Is het systeem bij onverwacht afbreken conform afspraken herstartbaar? - Installatie / de-installatietest: Test of de installatie en de-installatie van de wijzigingen werkt conform afspraken - Interface / ketentest: Tests rondom aansluiting van systeem op andere systemen (technisch en functioneel) - Limiettest: Test op gedefinieerde limieten (functioneel, dus bijv. max. salaris) - Load- / stresstest: Test op verwerken van grote hoeveelheden gegevens / transacties / gebruikers / klanten / bezoekers - Middelengebruik: Test op gebruik van resources - Monkeytest: Test op bestandheid tegen onverwachte handelingen (foolproof) - Mulit-user: kunnen meerdere / het afgesproken aantal gebruikers van het systeem gebruik maken - Performance: Voldoet het systeem aan de performance eisen? - Regressie: Testen op het functioneren van alle onderdelen, met name ook de niet-gewijzigde onderdelen - Rollback: Test of een rollback werkt conform afspraken - Scenario testen: Testen via scenario s, waarbij bedrijfsprocessen worden gesimuleerd - Uitwijktest: Test of uitwijk conform afspraken functioneert V1.0 Pagina 12

13 - Usability: Test op gebruikersvriendelijkheid, juistheid functioneren user inferface, opbouw user interface conform afspraken 2. TESTEN MET PRODUCTIEDATA Een onderwerp dat al lang veel discussie oproept is of het aan te bevelen, of juist af te raden, is om te testen met productiegegevens. Hierbij wordt de gehele productiedatabase overgezet naar een acceptatietestomgeving, waarna een test plaatsvindt. De voordelen zijn onder andere dat het op deze wijze natuurlijk geen tijd kost om een bestand met testgevallen op te bouwen en bij testen de werkelijke productiesituatie heel goed wordt nagebootst. Toch zijn er ook aanmerkelijke nadelen. Een productiedatabase kan heel groot zijn, waardoor de acceptatietestomgeving ook heel groot wordt en daarmee onhandelbaarder wordt. Een meer principieel punt is in sommige organisaties wel dat productiedata vaak netjes is beschermd tegen verkeerde/verkeerde ogen. In testomgevingen zijn dergelijke waarborgen er vaak niet. Hierdoor kan het zomaar gebeuren dat via deze achterdeur productiegegevens toch beschikbaar komen op plaatsen en bij personen die daar geen toegang toe zouden mogen hebben. Nu is het mogelijk productiegegevens te scrambelen, maar dat heeft weer als nadeel dat bepaalde functionele tests niet meer kunnen worden uitgevoerd. Bijvoorbeeld, indien alle namen zijn gescrambeld, wordt het onmogelijk om een functionaliteit als zoek verwanten op naam nog te gebruiken. Tot slot is ook vanuit functioneel oogpunt een belangrijk punt dat niet alle te testen gevallen ook werkelijk in de productiedatabase hoeven voor te komen. Stel dat er bijv. in de loonadministratie een controle zit op overschrijding max. loon, hoe groot is dan de kans dat in de productiedatabase een persoon is opgenomen die precies op dat maximum zit? Of, als die controle getest moet worden, een persoon met een te hoog salaris in de productiedatabase aanwezig is? Als het goed is, zitten dergelijke gevallen niet in productie. Maar om de controle te testen zou een dergelijk geval wel in een testset moeten zijn opgenomen. Bij elkaar kan het zeker zinvol zijn ook met productiedata te testen. Dan kan nog worden gekozen voor het testen met de volledige productieset, of met een extract daarvan (bijv. 1 op de 100 random selecteren en overzetten naar een testomgeving). Maar het is zeker niet de enige test die zou moeten worden uitgevoerd, het samenstellen van één of meerdere testsets met eigen specifieke testgevallen blijft dus noodzaak. 3. TESTEN IN PRODUCTIE Een absolute no go voor veel bedrijven is testen in productie. Toch is dat principe altijd haalbaar? Er zijn genoeg situaties te bedenken waarin geen representatieve testomgeving is op te bouwen. Denk alleen al aan een productielijn voor veevoer, bier of auto s. Het is volstrekt ondenkbaar een dergelijk productieproces ook in een testomgeving geheel op te bouwen. Weliswaar is een simulatie uit te voeren, maar uiteindelijk zal pas in productie blijken of een en ander geheel juist is. Juist functioneel is het dan noodzaak op een of andere manier de gevolgen van eventuele productiefouten te beperken. Ook kunnen middels pre-productie runs eventuele fouten nog worden opgespoord. In productiebedrijven is het niet vreemd om voordat een productielijn volledig productie gaat draaien een periode te hebben om alles in te laten lopen. V1.0 Pagina 13

14 4. TESTEN IN PRODUCTIE LOOK-A-LIKE OMGEVINGEN In de functionele acceptatietest en gebruikersacceptatietest is het de bedoeling in een omgeving te testen die zoveel mogelijk gelijk is aan de uiteindelijke productieomgeving. Het brengt het gevaar met zich mee dat Functioneel specialisten/ specialisten en de gebruikers die de tests uitvoeren geheel en al in de war raken. Dat wordt mede veroorzaakt doordat deze mensen geneigd zijn om het gewijzigde systeem in de testomgeving te vergelijken met de werkelijke, huidige productiesituatie. Door maar genoeg schermen open te hebben staan kan uiteindelijk test worden aangezien voor productie en andersom. Op een of andere manier moet dus altijd duidelijk blijven welke omgeving de testomgeving is. Dat kan door het fysiek te maken: bepaalde apparaten / ruimtes geven altijd toegang tot uitsluitend de testomgeving. Of het systeem is zo gemaakt dat met behulp van een indicator op elk scherm is te zien of het een test- dan wel productieomgeving betreft. Een aardige anekdote hierover tot slot: Een fabriek maakt apparaten die tot wel enige miljoenen euro s per stuk kunnen kosten. Bij een aanpassing van het ordersysteem wordt in de acceptatietestomgeving een nieuwe order ingevoerd en goedgekeurd. Vanwege allerlei koppelingen en dashboards gaat al snel bij de directie de champagne open: dergelijke orders komen tenslotte niet elke dag voor. Pas na enige tijd wordt duidelijk dat het helaas geen echte order betreft V1.0 Pagina 14

En de houthakker hakte tot diep in de nacht, want hij had geen tijd om zijn bijl te slijpen. Hoofdstuk 16. Taakgebied Testen

En de houthakker hakte tot diep in de nacht, want hij had geen tijd om zijn bijl te slijpen. Hoofdstuk 16. Taakgebied Testen En de houthakker hakte tot diep in de nacht, want hij had geen tijd om zijn bijl te slijpen. Hoofdstuk 16 Taakgebied Testen V1.1 / 01 september 2015 MCTL v1.1 Hoofdstuk 16... 3 Plaats in het MCTL-framework...

Nadere informatie

TMAP NEXT DOCUMENT OVERZICHT TOEGEPASTE TESTVORMEN

TMAP NEXT DOCUMENT OVERZICHT TOEGEPASTE TESTVORMEN TMAP NEXT DOCUMENT OVERZICHT TOEGEPASTE TESTVORMEN Copyright Sogeti Nederland B.V. te Vianen Niets uit deze uitgave mag verveelvoudigd en/of openbaar worden gemaakt (voor willekeurig welke doeleinden)

Nadere informatie

Taakgebied realisatie

Taakgebied realisatie Een monnik vroeg aan zijn meester: Ik zoek bevrijding. Hij antwoordde: Waar zijn dan je boeien? De leerling keek verbaasd: Die heb ik niet! Toen vroeg de zenmeester: Waarom zoek je dan naar bevrijding?

Nadere informatie

MCTL - Managing Computer Technology Library

MCTL - Managing Computer Technology Library 17. TAAKGEBIED TRANSITIE Het laatste taakgebied in het taakcluster Change control is Transitie. Transitie betekent letterlijk overgang en dat is in dit kader een goed getroffen term. In dit taakgebied

Nadere informatie

Vrijgaveadvies. Project

Vrijgaveadvies. Project <naam project> Vrijgaveadvies Project SYSQA B.V. Almere Datum : 08-02-2013 Status : Versie : Opgesteld door : Organisatie Project Pagina 2 van 16 Inhoudsopgave 1 Management samenvatting...

Nadere informatie

Taakcluster Operationeel support

Taakcluster Operationeel support Ideeën en plannen kunnen nog zo mooi zijn, uiteindelijk, aan het eind van de dag, telt alleen wat werkelijk is gedaan. Hoofdstuk 5 Taakcluster Operationeel support V1.1 / 01 september 2015 Hoofdstuk 5...

Nadere informatie

Testomgevingen beheer

Testomgevingen beheer Testomgevingen beheer Testen brengt het verwachte resultaat en de huidige toestand bij elkaar. Het geeft aanknopingspunten om de planning te maken, het product te verbeteren en om zorgen bij belanghebbenden

Nadere informatie

MCTL - Managing Computer Technology Library

MCTL - Managing Computer Technology Library 10. TAAKGEBIED MONITORING Monitoring van computertechnologie bestaat al langere tijd. Het is ontstaan vanuit de wens proactief potentiële problemen te willen voorzien en tijdig maatregelen te treffen om

Nadere informatie

Kwaliteitsbewaking en testen in ICT beheerorganisaties

Kwaliteitsbewaking en testen in ICT beheerorganisaties DKTP Informatie Technologie Veembroederhof 1 1019 HD Amsterdam Telefoon 020 427 52 21 Kwaliteitsbewaking en testen in ICT beheerorganisaties Voor de meeste projectgroepen die software ontwikkelen vormt

Nadere informatie

Taakgebied Bepalen huidige bedrijfsprocessen

Taakgebied Bepalen huidige bedrijfsprocessen Weten wat je doet, maar ook hoe je het doet, is de basis voor elke toekomst. Hoofdstuk 22 Taakgebied Bepalen huidige bedrijfsprocessen V1.1 / 01 september 2015 MCTL v1.1 Hoofdstuk 22... 3 Plaats in het

Nadere informatie

Mastertestplan <> <>

Mastertestplan <<Naam project>> <<Organisatie>> Mastertestplan SYSQA B.V. Almere Datum : Status : Opgesteld door : Organisatie Pagina 2 van 17 Inhoudsopgave 1 Management

Nadere informatie

Procesvisie op Maat. Op basis van het Master Test Plan wordt een gedetailleerd testplan voor elke fase opgesteld.

Procesvisie op Maat. Op basis van het Master Test Plan wordt een gedetailleerd testplan voor elke fase opgesteld. 1. 1.1. Inleiding Doel In de discipline vindt de validatie van datgene wat binnen het project is gerealiseerd plaats. Dit bestrijkt het gebied van unittest tot en met acceptatie door gebruikers en beheerorganisatie.

Nadere informatie

Regressietesten. De aanpak en aandachtspunten. Algemene informatie voor medewerkers van: SYSQA B.V.

Regressietesten. De aanpak en aandachtspunten. Algemene informatie voor medewerkers van: SYSQA B.V. Regressietesten De aanpak en aandachtspunten Algemene informatie voor medewerkers van: SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 8 Inhoudsopgave 1 INLEIDING...3 1.1 ALGEMEEN...3 1.2 VERSIEBEHEER...3

Nadere informatie

Rapport Richtlijn gebruik productiegegevens

Rapport Richtlijn gebruik productiegegevens Rapport Richtlijn gebruik productiegegevens Documenthistorie Datum en versienummer Auteur Opmerking Versie 1.0, 20 december 2005 M. van der Werff, B. de Wit Ter vaststelling door DPB Goedkeuring Datum

Nadere informatie

Voorbeeldexamen. Testen Foundation. Editie maart 2012

Voorbeeldexamen. Testen Foundation. Editie maart 2012 Voorbeeldexamen Testen Foundation Editie maart 2012 Copyright 2012 EXIN All rights reserved. No part of this publication may be published, reproduced, copied or stored in a data processing system or circulated

Nadere informatie

Martin van Leeuwen Happy Testing

Martin van Leeuwen Happy Testing Titel, samenvatting en biografie Samenvatting: Deze presentatie beschrijft een aantal test maatregelen die in een RUP nieuwbouw project zijn genomen, om ervoor te zorgen dat het testen aan het eind van

Nadere informatie

Testen kost te veel tijd

Testen kost te veel tijd Testen kost te veel tijd De oplevering van een nieuwe ICT applicatie betekent in de praktijk voor de opdrachtgever nog geen reden voor een feest. Vaak blijkt het product in onvoldoende mate te voldoen

Nadere informatie

Software Test Document

Software Test Document Software Test Document PEN: Paper Exchange Network Software Engineering groep 1 (se1-1415) Academiejaar 2014-2015 Jens Nevens - Sander Lenaerts - Nassim Versbraegen Jo De Neve - Jasper Bevernage Versie

Nadere informatie

Software Test Plan. PEN: Paper Exchange Network Software Engineering groep 1 (se1-1415) Academiejaar 2014-2015

Software Test Plan. PEN: Paper Exchange Network Software Engineering groep 1 (se1-1415) Academiejaar 2014-2015 Software Test Plan PEN: Paper Exchange Network Software Engineering groep 1 (se1-1415) Academiejaar 2014-2015 Jens Nevens - Sander Lenaerts - Nassim Versbraegen Jo De Neve - Jasper Bevernage Versie 1 Versie

Nadere informatie

De wereld is een schouwtoneel, elk speelt zijn rol en krijgt zijn deel (Joost van den Vondel) Hoofdstuk 4. Rolbeschrijvingen

De wereld is een schouwtoneel, elk speelt zijn rol en krijgt zijn deel (Joost van den Vondel) Hoofdstuk 4. Rolbeschrijvingen De wereld is een schouwtoneel, elk speelt zijn rol en krijgt zijn deel (Joost van den Vondel) Hoofdstuk 4 V1.2 / 01 februari 2016 MCTL 4. v1.2 Geen copyright! MCTL is in licentie gegeven volgens een Creative

Nadere informatie

Procesvalidatie voor een veiliger ketentest

Procesvalidatie voor een veiliger ketentest Procesvalidatie voor een veiliger ketentest Johan Vink TestNet Voorjaarsevenement 2010 Agenda Inleiding Typering project & testaanpak Werkwijze business proces Probleem De opdracht voor het testteam Probleemanalyse

Nadere informatie

Project Fasering Documentatie Applicatie Ontwikkelaar

Project Fasering Documentatie Applicatie Ontwikkelaar Project Fasering Documentatie Applicatie Ontwikkelaar Auteurs: Erik Seldenthuis Aminah Balfaqih Datum: 31 Januari 2011 Kerntaak 1 Ontwerpen van applicaties De volgordelijke plaats van de documenten binnen

Nadere informatie

Bepalen toekomstige computertechnologie

Bepalen toekomstige computertechnologie Eén van de onmenselijke kanten van de computer is dat hij, eenmaal goed geprogrammeerd en goed werkend, zo volslagen eerlijk is (Isaac Asimov) Hoofdstuk 26 Bepalen toekomstige V1.1 / 01 september 2015

Nadere informatie

Handleiding. VSV-testomgeving voor softwareleveranciers; de Proeftuin

Handleiding. VSV-testomgeving voor softwareleveranciers; de Proeftuin Handleiding VSV-testomgeving voor softwareleveranciers; de Proeftuin 1/6 Inhoudsopgave Hoofdstuk 1 Inleiding... 3 1.1 Het gebruikersveld... 3 1.2 Historie... 3 Hoofdstuk 2 Gebruikte criteria voor inrichting

Nadere informatie

De wereld is een schouwtoneel, elk speelt zijn rol en krijgt zijn deel (Joost van den Vondel) Hoofdstuk 4. Rolbeschrijvingen

De wereld is een schouwtoneel, elk speelt zijn rol en krijgt zijn deel (Joost van den Vondel) Hoofdstuk 4. Rolbeschrijvingen De wereld is een schouwtoneel, elk speelt zijn rol en krijgt zijn deel (Joost van den Vondel) Hoofdstuk 4 V1.1 / 01 september 2015 MCTL v1.1 4. : taken, bevoegdheden en verantwoordelijkheden... 3 Rol Key-user...

Nadere informatie

Ministerie van Infrastructuur en Milieu Beheerst naar beheer

Ministerie van Infrastructuur en Milieu Beheerst naar beheer Document D-2 Ministerie van Infrastructuur en Milieu Beheerst naar beheer Versie 1.0 Datum 15 juli 2014 Status Definitief Colofon Versie 1.0 Contactpersoon Paul Leunissen M 06-5250 6691 Paul.Leunissen@minienm.nl

Nadere informatie

Verschillen in QA aanpak tussen ERP projecten en niet-erp projecten

Verschillen in QA aanpak tussen ERP projecten en niet-erp projecten Verschillen in QA aanpak tussen ERP projecten en niet-erp projecten SYSQA B.V. Almere Datum : 06 mei 2013 Status : definitief Versie : 2.0 Opgesteld door : Organisatie SYSQA B.V. Pagina 2 van 5 Overzicht

Nadere informatie

Woordenlijst bij TMap

Woordenlijst bij TMap Woordenlijst bij TMap Acceptatietest De door de toekomstige gebruiker(s) en beheerder(s) in een zoveel mogelijk als-ware-het-productie omgeving uitgevoerde test, die moet aantonen dat het ontwikkelde systeem

Nadere informatie

PROJECT MANAGEMENT 1 PROJECT MANAGERS CHECKLIST

PROJECT MANAGEMENT 1 PROJECT MANAGERS CHECKLIST 1 WE SCHIJNEN ALTIJD TIJD TE VINDEN OM HET OVER TE DOEN?! LATEN WE HET DE EERSTE KEER - GELIJK GOED DOEN! Overdracht van het Offerte Team Heb je een kopie van het kosten- en/of prijsmodel? Heb je een kopie

Nadere informatie

Last but not least. Hoofdstuk 35. Bijlagen

Last but not least. Hoofdstuk 35. Bijlagen Last but not least Hoofdstuk 35 Bijlagen V1.2 / 01 februari 2016 Geen copyright! MCTL is in licentie gegeven volgens een Creative Commons Naamsvermelding 3.0 Nederland licentie. Gebaseerd op een werk van

Nadere informatie

Testen. Presentatie. Open-i Software Services BV, Maarssen Datum : 06-07-2013 Versie : 1.2

Testen. Presentatie. Open-i Software Services BV, Maarssen Datum : 06-07-2013 Versie : 1.2 Testen Presentatie Open-i Software Services BV, Maarssen Datum : 06-07-2013 Versie : 1.2 Algemeen Tegenwoordig behoeft het belang van testen nauwelijks nog te worden uitgelegd. Binnen organisaties speelt

Nadere informatie

TestNet voorjaarsevenement 2014 Managen van een KetenTest bij NS met hun TOPAAS toolsuite. Managen van een Ketentest bij NS met hun TOPAAS tool-suite

TestNet voorjaarsevenement 2014 Managen van een KetenTest bij NS met hun TOPAAS toolsuite. Managen van een Ketentest bij NS met hun TOPAAS tool-suite Managen van een Ketentest bij NS met hun TOPAAS tool-suite Bart Broekman mei 2014 Onderwerpen De (prachtige) TOPAAS tooling De (niet zo prachtige) project-situatie De (oh zo mooie) dingen die we ermee

Nadere informatie

MCTL - Managing Computer Technology Library

MCTL - Managing Computer Technology Library 11. TAAKGEBIED EDUCATIE Optimale benutting van computertechnologie in het werk hangt mede af van de juiste kennis en vaardigheden bij medewerkers. In dit taakgebied wordt ervoor gezorgd dat nieuwe medewerkers,

Nadere informatie

ERP Testing. HP Nijhof. Testmanager. Testnet November 2005

ERP Testing. HP Nijhof. Testmanager. Testnet November 2005 ERP Testing HP Nijhof Testmanager Testnet November 2005 Solution Sales Meeting7 November 2005 1 Agenda Waarom pakketten testen? Schaarse middelen? Ideale ERP test situatie Vragen 2 De centrale vraag ERP

Nadere informatie

Software Test Plan. Yannick Verschueren

Software Test Plan. Yannick Verschueren Software Test Plan Yannick Verschueren Maart 2015 Document geschiedenis Versie Datum Auteur/co-auteur Beschrijving 1 November 2014 Yannick Verschueren Eerste versie 2 December 2014 Yannick Verschueren

Nadere informatie

ISO4 Opdracht 2 Tmap Next testplan

ISO4 Opdracht 2 Tmap Next testplan ISO4Opdracht2 TmapNexttestplan HermanvanderMeulen s1013123 Versie1.0 08 04 2009 Inhoudsopgave Versiebeheer... 3 Inleiding... 4 1.Opdracht... 5 1.1Opdrachtgever... 5 1.2Opdrachtnemer... 5 1.3Opdracht...

Nadere informatie

Webtesten onder schaarste

Webtesten onder schaarste Testnet najaarsevenement 2005 B e y o n d t h e o r d i n a r y Webtesten onder schaarste Vincent Staal ORDINA NV Ringwade 1 Postbus 7101 3430 JC Nieuwegein Tel: 030 6637000 Fax: 030 6637099 www.ordina.nl

Nadere informatie

Parasoft toepassingen

Parasoft toepassingen Testen op basis van OSB en Digikoppeling Voor de bestaande Overheid Service Bus en de nieuwe standaard Digikoppeling zijn verschillende test- omgevingen opgezet. Hiermee kan het asynchrone berichtenverkeer

Nadere informatie

Als je snel wilt gaan, ga alleen. Als je ver wilt komen, ga dan samen (Afrikaans spreekwoord) Hoofdstuk 20. Contractmanagement

Als je snel wilt gaan, ga alleen. Als je ver wilt komen, ga dan samen (Afrikaans spreekwoord) Hoofdstuk 20. Contractmanagement Als je snel wilt gaan, ga alleen. Als je ver wilt komen, ga dan samen (Afrikaans spreekwoord) Hoofdstuk 20 Contractmanagement V1.1 / 01 september 2015 Hoofdstuk 20... 3 Plaats in het MCTL-framework...

Nadere informatie

BDD/Gherkin. Een introductie

BDD/Gherkin. Een introductie BDD/Gherkin Een introductie Organisatie SYSQA B.V. Pagina 2 van 10 Inhoudsopgave 1. Inleiding... 3 2. BDD... 4 3. Gherkin... 5 4. BDD-Tools... 6 5. Voordelen... 7 6. Benodigde kennis en vaardigheden...

Nadere informatie

Sjabloon testplan o.b.v. situationeel testen. <>

Sjabloon testplan o.b.v. situationeel testen. <<Organisatie>> Sjabloon testplan o.b.v. situationeel testen SYSQA B.V. Almere Datum : Status : Opgesteld door : Organisatie SYSQA B.V. Pagina 2 van 11 Over dit sjabloon Dit

Nadere informatie

Betere dienstverlening financiële organisaties met continuous delivery Flexibeler, efficiënter en in kort tijdsbestek software ontwikkelen

Betere dienstverlening financiële organisaties met continuous delivery Flexibeler, efficiënter en in kort tijdsbestek software ontwikkelen Betere dienstverlening financiële organisaties met continuous delivery Flexibeler, efficiënter en in kort tijdsbestek software ontwikkelen Sinds de kredietcrisis en door opkomende technologieën staan banken

Nadere informatie

Testgedreven ontwikkeling dat is pas veilig!

Testgedreven ontwikkeling dat is pas veilig! Testgedreven ontwikkeling dat is pas veilig! INTRODUCTIE ANKO TIJMAN 2 Software tester sinds 1997 (TMap, ISEB Practitioner) Eerste agile ervaring in 2001 Presentaties op (inter)nationale congressen Nov

Nadere informatie

Plan van Aanpak Pilot

Plan van Aanpak Pilot Plan van Aanpak Pilot DBK-applicaties Beproeven compatibiliteit DBK-applicaties op innovatieplatform voor de Veiligheidsregio s Status : concept Versienummer : V0.2 Datum : Augustus 2012 Blad : 2 / 6 Inhoudsopgave

Nadere informatie

Uitdagingen performancetesten in een Agile omgeving Best Practices & Demo

Uitdagingen performancetesten in een Agile omgeving Best Practices & Demo Uitdagingen performancetesten in een Agile omgeving Best Practices & Demo Henrik Rexed & Joerek van Gaalen Voorstellen Joerek van Gaalen Performancetest specialist sinds 2005 Sinds 2014 CTO Computest Voorstellen

Nadere informatie

Agile Testen in de praktijk

Agile Testen in de praktijk 1 Agenda 2 Agile Testen in de praktijk Summerschool 13 Juli 2011 Introductie Agile de context van agile Testen2.0 de tester in een agile project Waarden en principes DoD, PRA en MTP Testen3.0 in een agile

Nadere informatie

ICT Beheermodel informatiesystemen Drechtsteden Baseline inrichting ICT beheermodel Drechtsteden

ICT Beheermodel informatiesystemen Drechtsteden Baseline inrichting ICT beheermodel Drechtsteden Drechtsteden Technische Architectuur (DTA) ICT Beheermodel informatiesystemen Drechtsteden Baseline inrichting ICT beheermodel Drechtsteden Status : Definitief 1.0 Redactie : DTA Datum : 29-08-2007 1 Versiebeheer

Nadere informatie

Handleiding voor aansluiten op Digilevering

Handleiding voor aansluiten op Digilevering Handleiding voor aansluiten op Digilevering Versie 1.0 Datum 1 augustus 2013 Status definitief Colofon Projectnaam Digilevering Versienummer 1.0 Contactpersoon Servicecentrum Logius Organisatie Logius

Nadere informatie

Testrapport Kiezen op Afstand Inhoudelijke Stresstest

Testrapport Kiezen op Afstand Inhoudelijke Stresstest Testrapport Inhoudelijke Stresstest Dit document heeft 10 pagina 's Testrapport 1nhoudelijke Stresstest vo.21 Document historie Versie Datum Bijzonderheden Autorisatie 0.1 20-09-2006 Opzet 0.2 22-09-2006

Nadere informatie

Whitepaper Test Management Business case voor geautomatiseerd testen

Whitepaper Test Management Business case voor geautomatiseerd testen Whitepaper Test Management Business case voor geautomatiseerd testen Waarom we informatiesystemen testen behoeft geen uitleg: Testen is nodig om inzicht te geven in de kwaliteit. Het voorkomen van risico

Nadere informatie

Marlin Family. Marlin

Marlin Family. Marlin PCA Mobile PCA Mobile Organisatie PCA Mobile BV maakt deel uit van de Mobile Solution Group en biedt met ruim 40 enthousiaste collega s een veelomvattend pakket van innovatieve en gebruiksvriendelijke

Nadere informatie

Organisatie SYSQA B.V. Pagina 1 van 6 Titel Overzicht Versie 1.0 Onderwerp Overzicht blackbox testtechnieken Datum 15 februari 1996

Organisatie SYSQA B.V. Pagina 1 van 6 Titel Overzicht Versie 1.0 Onderwerp Overzicht blackbox testtechnieken Datum 15 februari 1996 Organisatie SYSQA B.V. Pagina 1 van 6 Black-Box Test Technieken Er zijn een aantal test specificatie technieken, verder testtechnieken genoemd, die bruikbaar zijn binnen het black-box acceptatietesten.

Nadere informatie

Acceptatietesten en testmanagement Examennummer: 93453 Datum: 29 maart 2014 Tijd: 10:00 uur - 11:30 uur

Acceptatietesten en testmanagement Examennummer: 93453 Datum: 29 maart 2014 Tijd: 10:00 uur - 11:30 uur Acceptatietesten en testmanagement Examennummer: 93453 Datum: 29 maart 2014 Tijd: 10:00 uur - 11:30 uur Dit examen bestaat uit 7 pagina s. De opbouw van het examen is als volgt: - 20 meerkeuzevragen (maximaal

Nadere informatie

GAMP Toegepast op de DeskTopXorter Besturing DeskTopXorter

GAMP Toegepast op de DeskTopXorter Besturing DeskTopXorter GAMP Toegepast op de DeskTopXorter Besturing DeskTopXorter 2 Opdrachtgever : Opdrachtnemers : Ing. P. van den Berg Michel van Reenen Thijs Mommen GAMP Toegepast op de DeskTopXorter Besturing DeskTopXorter

Nadere informatie

De Btw-verhoging van 01 oktober 2012 in UNIT4 Multivers met de UNIT4 Multivers BTW Converter

De Btw-verhoging van 01 oktober 2012 in UNIT4 Multivers met de UNIT4 Multivers BTW Converter 1 De Btw-verhoging van 01 oktober 2012 in UNIT4 Multivers met de UNIT4 Multivers BTW Converter Inleiding Per 01 oktober 2012 zal in Nederland het hoge Btw-tarief van 19% door de overheid verhoogd worden

Nadere informatie

Releasen met een druk op de knop: Met behulp van Continuous Delivery sneller uw doel bereiken

Releasen met een druk op de knop: Met behulp van Continuous Delivery sneller uw doel bereiken Releasen met een druk op de knop: Met behulp van Continuous Delivery sneller uw doel bereiken De business organisatie heeft altijd stijgende verwachtingen van uw IT organisatie. Meer dan ooit is het van

Nadere informatie

Testen bij DWH-projecten

Testen bij DWH-projecten Testen bij DWH-projecten Snelheid, Kwaliteit, Flexibiliteit onder úw regie Armando Dörsek, Software Control 18-09-2007 Wat gaat u horen? Testen van DW/BI > Structureren & Plannen Project- en teamstructuur

Nadere informatie

Releases en change-management bij maatwerkapplicaties

Releases en change-management bij maatwerkapplicaties Releases en change-management bij maatwerkapplicaties door Wim - 01-26-2011 http://www.itpedia.nl/2011/01/26/releases-en-change-management-bij-maatwerk-applicaties/ Op grote maatwerk informatiesystemen

Nadere informatie

Anand T hakur. Over Anand

Anand T hakur. Over Anand Anand T hakur Over Anand 1987 Anand Thakur is een TMAP Next gecertificeerde testcoördinator. Mede door zijn analytisch vermogen, objectiviteit, senioriteit, vermogen om onder druk te werken en geode stakeholder

Nadere informatie

Introductie Performancetesten

Introductie Performancetesten Introductie Performancetesten SYSQA B.V. Almere Datum : 19-12-2014 Status : Definitief Organisatie: SYSQA B.V. Pagina 2 van 12 1 Inleiding SYSQA is een onafhankelijke organisatie, gespecialiseerd in het

Nadere informatie

Presentatie 06-03-2008 Gestructureerd en geautomatiseerd testen Ad Driessens en Gerben Mondeel

Presentatie 06-03-2008 Gestructureerd en geautomatiseerd testen Ad Driessens en Gerben Mondeel Presentatie 06-03-2008 Gestructureerd en geautomatiseerd testen Ad Driessens en Gerben Mondeel Doelstelling Introductie Practis en Producten Project bij Achmea Testaanpak Concrete toepassing van Rational

Nadere informatie

Managing Computer Technology Library

Managing Computer Technology Library Managing Computer Technology Library 1. INLEIDING Welkom bij dit basisboek over MCTL (Managing Computer Technology Library). In dit boek worden de doelstellingen, activiteiten, te behalen resultaten en

Nadere informatie

Checklist risicofactoren IT-projecten

Checklist risicofactoren IT-projecten Organisatie SYSQA B.V. Pagina 1 van 5 Checklist risicofactoren IT-projecten In onderstaande checklists zijn de factoren die het slagen van een project beïnvloeden opgenomen. Projectomvang Hoe groot is

Nadere informatie

Uitwerking thema avond Testnet HBO/Academische Testopleiding 14 november 2012

Uitwerking thema avond Testnet HBO/Academische Testopleiding 14 november 2012 Uitwerking thema avond Testnet HBO/Academische Testopleiding 14 november 2012 Inleiding: Tijdens deze thema avond heeft de werkgroep vertegenwoordigd door een 4 koppige delegatie de resultaten van de werkgroep

Nadere informatie

PROJECT PLAN VOOR DE IMPLEMENTATIE VAN EEN STANDAARD SITE VOOR DE VERENIGING O3D

PROJECT PLAN VOOR DE IMPLEMENTATIE VAN EEN STANDAARD SITE VOOR DE VERENIGING O3D PROJECT PLAN VOOR DE IMPLEMENTATIE VAN EEN STANDAARD SITE VOOR DE VERENIGING O3D Auteur : P. van der Meer, Ritense B.V. Datum : 17 juli 2008 Versie : 1.3 2008 Ritense B.V. INHOUD 1 VERSIEBEHEER...1 2 PROJECT

Nadere informatie

Software Test Plan. Yannick Verschueren

Software Test Plan. Yannick Verschueren Software Test Plan Yannick Verschueren November 2014 Document geschiedenis Versie Datum Auteur/co-auteur Beschrijving 1 November 2014 Yannick Verschueren Eerste versie 1 Inhoudstafel 1 Introductie 3 1.1

Nadere informatie

Performance Testen bij Rabobank Nederland. TestNet Noord Testers bij de bank 21 februari 2012 Allan Beumer

Performance Testen bij Rabobank Nederland. TestNet Noord Testers bij de bank 21 februari 2012 Allan Beumer Performance Testen bij Rabobank Nederland TestNet Noord Testers bij de bank 21 februari 2012 Allan Beumer Agenda Performance Testen bij Rabobank Nederland 1 2 3 4 Introductie Performance Competence Center

Nadere informatie

SEPA-Testevent. SEPA migratie Van Lanschot Bankiers. Den Haag 25 september 2012

SEPA-Testevent. SEPA migratie Van Lanschot Bankiers. Den Haag 25 september 2012 SEPA-Testevent SEPA migratie Van Lanschot Bankiers Den Haag 25 september 2012 Agenda 1. Testscope SEPA @ Van Lanschot 2. Testproces voor aanlevering PAIN bestanden 3. Aanvullingen Van Lanschot op specificaties

Nadere informatie

ISACA round-table 7 december 2009 Rik Marselis

ISACA round-table 7 december 2009 Rik Marselis ISACA round-table 7 december 2009 Rik Marselis Senior Testconsultant bij Sogeti Penningmeester van BNTQB, de member board voor België en Nederland van de International Software Testing Qualifications Board

Nadere informatie

INTERPRETATIEDOCUMENT vastgesteld door het CCvD Bodembeheer

INTERPRETATIEDOCUMENT vastgesteld door het CCvD Bodembeheer INTERPRETATIEDOCUMENT vastgesteld door het CCvD Bodembeheer Van toepassing op : BRL SIKB 0100, versie 4.0-29 juni 2005 Versie en datum vaststelling : 1, 3 september 2009 Datum in werking treden : 7 september

Nadere informatie

PROQA Project Quality Assurance. Checklist. Behorend bij het PROQA-assessment SYSQA B.V.

PROQA Project Quality Assurance. Checklist. Behorend bij het PROQA-assessment SYSQA B.V. PROQA Project Quality Assurance Checklist Behorend bij het PROQA-assessment SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 9 Inhoudsopgave 1 INLEIDING CHECKLIST WERKEN VOLGENS PROQA... 3 1.1 DE 5 FASEN

Nadere informatie

Wij testen..maar....wat test jij?

Wij testen..maar....wat test jij? Wij testen..maar....wat test jij? Wij testen maar wat test jij? Harm Pul, Busineslinemanager Functioneel Beheer TMAP dag 2015, 29 september 2015 Bussum 2 Herkent u dit? De gebruikers testen dit straks

Nadere informatie

Ontwikkelen en testen van e-business: beheerste dynamiek

Ontwikkelen en testen van e-business: beheerste dynamiek Ontwikkelen en testen van e-business: beheerste dynamiek Het ontwikkelen en gestructureerd testen van administratieve systemen is gebaseerd het watervalprincipe. Bij het ontwikkelen volgens het watervalprincipe

Nadere informatie

MCTL - Managing Computer Technology Library

MCTL - Managing Computer Technology Library 6. TAAKGEBIED GEBRUIKERSONDERSTEUNING Gebruikersondersteuning omvat precies wat de term aangeeft: ondersteuning van gebruikers bij het juist toepassen van computertechnologie tijdens de uitvoering van

Nadere informatie

Welkom. Great SAP Test Experience. 23 maart 2015

Welkom. Great SAP Test Experience. 23 maart 2015 Welkom Great SAP Test Experience 23 maart 2015 Sogeti PowerPoint Referentie 2014 2 5 5 Sogeti PowerPoint Referentie 2014 3 Sogeti PowerPoint Referentie 2014 4 Sogeti PowerPoint Referentie 2014 5 En toch

Nadere informatie

TESTAUTOMATISERING IN EEN ETL-OMGEVING

TESTAUTOMATISERING IN EEN ETL-OMGEVING Pagina 21 TESTAUTOMATISERING IN EEN ETL-OMGEVING Door John Kronenberg John.Kronenberg@bartosz.nl @johnkronenberg Edward Crain Edward.crain@divetro.nl Welke groeifasen werden doorlopen in testautomatisering

Nadere informatie

Prijzen RIVOS. RIVOS Prijzen Pagina 1

Prijzen RIVOS. RIVOS Prijzen Pagina 1 Prijzen RIVOS De totale investering voor RIVOS bestaat uit de basis aanschafprijs, optionele modules, bijkomende kosten en jaarlijks terugkerende kosten. De basis aanschafprijs wordt bepaald door het aantal

Nadere informatie

4.1 Simulatie in de analysefase

4.1 Simulatie in de analysefase 1 Bijlage 4 Simulatietechnieken Simulatie is een toetstechniek waarmee door middel van het nabootsen van een bepaalde situatie (bijvoorbeeld een herontworpen bedrijfsproces) in een afgeschermde omgeving

Nadere informatie

Whitepaper implementatie workflow in een organisatie

Whitepaper implementatie workflow in een organisatie Whitepaper implementatie workflow in een organisatie Auteur: Remy Stibbe Website: http://www.stibbe.org Datum: 01 mei 2010 Versie: 1.0 Whitepaper implementatie workflow in een organisatie 1 Inhoudsopgave

Nadere informatie

TESTEN VOLGENS TMAP, EEN KORTE INTRODUCTIE. 1. Inleiding. 2. TMap methode. Kwaliteit zonder gestructureerd testen is toeval.

TESTEN VOLGENS TMAP, EEN KORTE INTRODUCTIE. 1. Inleiding. 2. TMap methode. Kwaliteit zonder gestructureerd testen is toeval. TESTEN VOLGENS TMAP, EEN KORTE INTRODUCTIE Kwaliteit zonder gestructureerd testen is toeval Inhoudsopgave 1. Inleiding 2. De TMap methode 3. De fase Planning & Beheer 4. De fase testspecificatie 5. De

Nadere informatie

Titel: Projectdocumenten niveau 4. Versie: 0.6. Datum: 28 augustus 2008. Auteur: Harmen Steenbergen / Titia Brouwer. Projectdocumenten Niveau 4

Titel: Projectdocumenten niveau 4. Versie: 0.6. Datum: 28 augustus 2008. Auteur: Harmen Steenbergen / Titia Brouwer. Projectdocumenten Niveau 4 Titel: Projectdocumenten niveau 4 Versie: 0.6 Datum: 28 augustus 2008 Auteur: Harmen Steenbergen / Titia Brouwer Pagina 1 van 10 Inhoudsopgave Inleiding...4 Algemeen...4 Planning en logboek...4 Definitiestudie...4

Nadere informatie

Alles wat ik nodig heb om een komedie te maken is een park, een politieagent en een mooi meisje (Charlie Chaplin) Hoofdstuk 2.

Alles wat ik nodig heb om een komedie te maken is een park, een politieagent en een mooi meisje (Charlie Chaplin) Hoofdstuk 2. Alles wat ik nodig heb om een komedie te maken is een park, een politieagent en een mooi meisje (Charlie Chaplin) Hoofdstuk 2 V1.1 / 01 september 2015 MCTL v1.1 Hoofdstuk 2... 3 Concretisering doel MCTL...

Nadere informatie

Software Test Documentation

Software Test Documentation FACULTEIT INGENIEURSWETENSCHAPPEN & WE- TENSCHAPPEN DEPARTMENT OF COMPUTER SCIENCE AND APPLIED COMPUTER SCIENCE Software Test Documentation Software Engineering Nicolas Carraggi, Youri Coppens, Christophe

Nadere informatie

MCTL - Managing Computer Technology Library

MCTL - Managing Computer Technology Library 8. TAAKGEBIED GEGEVENSBEHEER Gegevensbeheer, met name de gegevens in elektronische databases, is in essentie altijd een zaak van de eigenaar van de gegevens; de gebruikersorganisatie dus. In dit taakgebied

Nadere informatie

Management. Analyse Sourcing Management

Management. Analyse Sourcing Management Management Analyse Sourcing Management Management Business Driven Management Informatie- en communicatietoepassingen zijn onmisbaar geworden in de dagelijkse praktijk van uw organisatie. Steeds meer

Nadere informatie

Risico s bij ERP. SYSQA B.V. Almere. Datum : 6 mei 2013 Status : Definitief Versie : 2.0 Opgesteld door :

Risico s bij ERP. SYSQA B.V. Almere. Datum : 6 mei 2013 Status : Definitief Versie : 2.0 Opgesteld door : Risico s bij ERP SYSQA B.V. Almere Datum : 6 mei 2013 Status : Definitief Versie : 2.0 Opgesteld door : Organisatie SYSQA B.V. Pagina 2 van 13 Titel Risico s bij ERP Versie 2.0 Datum 06-05-2013 Inhoudsopgave

Nadere informatie

Whitepaper. Exploratory Testing. Waarom doen we dat niet altijd? door Dennis Joele

Whitepaper. Exploratory Testing. Waarom doen we dat niet altijd? door Dennis Joele Whitepaper Exploratory Testing Waarom doen we dat niet altijd? door Dennis Joele Dennis Joele is werkzaam als test designer bij TriOpSys en heeft als zodanig voor de Dienst der Hydrografie van de Koninklijke

Nadere informatie

Sjabloon testplan op basis van SYSQA -teststrategieaanpak. <>

Sjabloon testplan op basis van SYSQA -teststrategieaanpak. <<Organisatie>> Sjabloon testplan op basis van SYSQA -teststrategieaanpak SYSQA B.V. Almere Datum : Status : Opgesteld door : Organisatie Sjabloon detailtestplan op basis

Nadere informatie

Summerschool 2011 Performance testen in vogelvlucht. Max Lans Martijn Ruff

Summerschool 2011 Performance testen in vogelvlucht. Max Lans Martijn Ruff Summerschool 2011 Performance testen in vogelvlucht Max Lans Martijn Ruff 1 Introductie Martijn Introductie Max Wat zit er NIET in de Summerschool? Een puur technisch verhaal Een voorkeur voor tooling

Nadere informatie

MCTL - Managing Computer Technology Library

MCTL - Managing Computer Technology Library 2. ACHTERGROND In dit hoofdstuk wordt de achtergrond van MCTL toegelicht. Zo wordt het doel, maar ook het ontstaan van MCTL en de positie van MCTL in een organisatie geschetst. CONCRETISERING DOEL MCTL

Nadere informatie

8-12-2015. Hoe test je een pen? Je kunt de presentatie na afloop van elke les downloaden. Ga naar : www.gelsing.info Kies voor de map Acceptatietesten

8-12-2015. Hoe test je een pen? Je kunt de presentatie na afloop van elke les downloaden. Ga naar : www.gelsing.info Kies voor de map Acceptatietesten Les 1 Docent: Marcel Gelsing Je kunt de presentatie na afloop van elke les downloaden. Ga naar : www.gelsing.info Kies voor de map Acceptatietesten Hoe test je een pen? 1 Bekijk eerst het filmpje over

Nadere informatie

Bedrijfssystemen vervangen door Slim Software Nabouwen

Bedrijfssystemen vervangen door Slim Software Nabouwen Bedrijfssystemen vervangen door Slim Software Nabouwen Codeless White Paper Roland Worms, Directeur Wouter van der Ven, Lead Software Architect Inhoudsopgave 1. Introductie 2. Het IT dilemma. Als standaard

Nadere informatie

De best leesbare displays van Nederland

De best leesbare displays van Nederland De best leesbare displays van Nederland Missie De missie van Data Display is helder de openbare ruimte voorzien van hoogwaardige elektronische informatiesystemen. Daarbij onderscheidt Data Display drie

Nadere informatie

Data Warehouse. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

Data Warehouse. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. Data Warehouse Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 9 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 1.2 VERSIEBEHEER... 3 2 DOEL VAN

Nadere informatie

Uitstroom + Crebonummer Applicatie- en mediaontwikkelaar; Crebonummer 25187 Niveau Niveau 4

Uitstroom + Crebonummer Applicatie- en mediaontwikkelaar; Crebonummer 25187 Niveau Niveau 4 VOORBLAD FORMAT BLAUWDRUK VAN DE OPLEIDING Algemene informatie Blauwdruk Ontwerper: Isolde Kolkhuis Tanke Ontwerpdatum: 23 september 2015 Versie: 03 Domein: Informatie- en communicatietechnologie Kwalificatiedossier:

Nadere informatie

Als je blijft denken zoals je altijd hebt gedacht, blijf je krijgen wat je altijd hebt gekregen. Hoofdstuk 1: Inleiding

Als je blijft denken zoals je altijd hebt gedacht, blijf je krijgen wat je altijd hebt gekregen. Hoofdstuk 1: Inleiding Als je blijft denken zoals je altijd hebt gedacht, blijf je krijgen wat je altijd hebt gekregen Hoofdstuk 1: V1.1 / 01 september 2015 MCTL v1.1 1.... 2 Wat is MCTL?... 2 Het doel van MCTL... 3 Scope /

Nadere informatie

Rapportage Pizzasessie Functioneel-beheer.com Specialisten Managers Adviseurs Algemeen functioneel beheer applicatiebeheer informatiemanagement

Rapportage Pizzasessie Functioneel-beheer.com Specialisten Managers Adviseurs Algemeen functioneel beheer applicatiebeheer informatiemanagement Rapportage Pizzasessie Functioneel-beheer.com Alle deelnemers hebben hun functienaam opgegeven. De volgende functienamen zijn gemeld: Specialisten o Functioneel beheerder (9x) o Functioneel applicatiebeheerder

Nadere informatie

RAD Rapid application development. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

RAD Rapid application development. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. RAD Rapid application development Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 10 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 1.2 VERSIEBEHEER...

Nadere informatie

MCTL - Managing Computer Technology Library

MCTL - Managing Computer Technology Library 13. TAAKGEBIED REQUIREMENTS MANAGEMENT Aan de gebruikerszijde moet vanzelfsprekend een beschrijving zijn van de bedrijfsprocessen en de inzet van computertechnologie hierbinnen. In het geval van een wijziging

Nadere informatie