Uittreksel. Ten geleide

Maat: px
Weergave met pagina beginnen:

Download "Uittreksel. Ten geleide"

Transcriptie

1 Ten geleide TMap, Test Management Approach, is een aanpak voor het gestructureerd testen van informatiesystemen. Het geeft antwoord op de wat/wanneer, hoe, waarmee en wie vragen van het testen. Om de inrichting en uitvoering van testprocessen gestructureerd te laten verlopen, is TMap gebaseerd op vier, aan deze vragen gerelateerde, pijlers. 1. De wat/wanneer vragen worden beantwoord door het faseringsmodel, een aan de ontwikkelingscyclus gerelateerde beschrijving van de testcyclus. 2. Het hoe is verwoord in de beschrijving van de technieken voor het plannen, voorbereiden en uitvoeren van de diverse tests. 3. Op het waarmee wordt ingegaan bij de beschrijving van de infrastructuur en de tools. 4. De beschrijving van de organisatie~aspecten geeft antwoord op de wie vraag. TMap is een generiek model. De theorie is universeel beschreven omdat dé testaanpak nu eenmaal niet bestaat. Testen komt voor in diverse variaties die elk hun eigen toepassing van de standaard vragen. In het boek wordt daarom ruim aandacht besteed aan de wijze waarop de juiste componenten van TMAp, voor welk testproces dan ook, geselecteerd kunnen worden. Het boek is opgebouwd uit vijf delen. Deel 1 beschrijft het fenomeen testen en TMap in het algemeen, terwijl de delen 2, 3, 4 en 5 de respectievelijke pijlers van TMap beschrijven: fasering, technieken, organisatie en infrastructuur. Deel I beschrijft het belang en context van het testen in de informatievoorziening en binnen de kwaliteitszorg in het bijzonder. Het waarom van het testen en de mogelijkheden van een gestructureerde toepassing komen uitvoerig aan de orde. Ter oriëntatie is een hoofdstuk opgenomen waarin de theorie in een notedop is beschreven. In Variaties op het thema zijn enkele belangrijke toepassingsgebieden belicht, zoals het testen van pakketten, het testen in onderhoudssituaties en het testen in client/server omgevingen. Deel II bevat het faseringsmodel voor de testprocessen. De testactiviteiten worden systematisch beschreven voor zowel de white-box als de black-box tests. De fasering vormt de rode draad van TMap. Vanuit de fasering wordt de relatie gelegd tussen de componenten van de overige pijlers: technieken, organisatie en infrastructuur. In deel III worden de voor het testen beschikbare technieken in detail beschreven. Naast de primaire testspecificatietechnieken voorziet het TMap instrumentarium onder andere in technieken voor het bepalen van de teststrategie en de testbegroting. Dit deel bevat tevens een uitgebreide verzameling checklists. In deel IV komt de organisatie van het testen aan de orde. Hierin worden de testfuncties met de vereiste kennis en vaardigheden, de organisatiestructuur en het aspect testbeheer beschreven. Aan de selectie en de opleiding van testpersoneel is in een apart hoofdstuk aandacht besteed. In het hoofdstuk Structurering wordt ingegaan op de implementatie van het gestructureerd testen binnen een organisatie. Hiertoe is een speciaal voor dit doel ontwikkelde leidraad opgenomen. Deel V gaat in op de voor het testen benodigde infrastructuur. Respectievelijk zijn richtlijnen opgenomen voor de testomgeving, de testtools en de kantoor inrichting. Aangemaakt d.d Pagina 2

2 Deel I: Algemeen 1. Inleiding Testen is volgens het woordenboek: aan een test onderwerpen, beproeven, toetsen. Over testen bestaat in de informatica industrie zo langzamerhand een beeld, maar nog lang geen sluitende definitie waarvan een ieder zich bedient. De vele soorten tests met uiteenlopende doelen, de vage begrenzingen en de veelal nog informele toepassing van het fenomeen maken het opstellen van een eenduidige begripsbepaling lastig. 1.1 Wat is testen? Testen is in ieder geval vergelijken. Het vraagt om een te testen object en een referentiekader waaraan dat object moet voldoen. Definitie van Testen volgens ISO Activiteiten zoals meten, onderzoeken, beproeven, keuren met kalibers van één of meer kenmerken van een produkt of dienst en het vergelijken van uitkomsten met gestelde eisen om te bepalen of aan deze voorwaarde is voldaan. Testen geeft inzicht in het verschil tussen de actuele en de vereiste status van een object. Testen behoort tot de detectieve middelen van een kwaliteitssysteem. De diverse detectie-instrumenten worden verdeeld in twee groepen: toetsen : het inspecteren van tussenprodukten en ontwikkelingsprocessen, ofwel verificatie (wordt er goed gebouwd?) testen : het inspecteren van de eindprodukten, ofwel de validatie (wordt het goede produkt gebouwd?) Definitie van Testen Testen is een proces van plannen, voorbereiden en meten, dat tot doel heeft de kenmerken van een informatiesysteem vast te stellen en het verschil tussen de actuele en de vereiste status aan te tonen. 1.2 Waarom testen? ISO formuleert: Is vastgesteld of het produkt de eigenschappen en kenmerken bezit om te voldoen aan de vastgestelde of, en dat is nog lastiger; vanzelfsprekende behoeften? Eigenlijk luidt de vraag: Welke risico s worden gelopen, en welke maatregelen zijn eventueel te nemen ter reductie van die risico s? Om niet pas tijdens de exploitatiefase antwoord op dit soort cruciale vragen te krijgen, is een goed gestructureerd en betrouwbaar testproces vereist. Dat vraagt om een gestructureerde testaanpak en dito organisatie en infrastructuur. 1.3 Waar staat het testen? In de meeste organisaties is het testen onderontwikkeld en bevindt het zich nog vaak in een experimenteel stadium. Men heeft veelal de neiging om de invoering van een gedegen kwaliteitssysteem, waarvan het testen een belangrijk onderdeel vormt, voor zich uit te schuiven. Het ontbreekt meestal aan de vereiste organisatorische basis die waarborgen biedt om kwalitatief te kunnen ontwikkelen en testen. Daar waar men het fenomeen kwaliteit wel serieus neemt, wordt het testen pas als laatste gestructureerd. Overigens blijkt dat in rijpere industrieën, zoals bijvoorbeeld de luchtvaart en hardware industrie, het testen zich ontwikkeld heeft tot een volwaardig (en substantieel) onderdeel van het kwaliteitssysteem. Aangemaakt d.d Pagina 3

3 2. Kader en belang U wilt gaan testen. In wezen echter wilt u niet testen, maar u wilt de risico s beheersen die verbonden zijn aan het invoeren van een nieuw informatiesysteem. Dit boek gaat daarom eigenlijk niet over testen, maar over risicobeheersing. Testen is daarbij slechts een middel. Misschien een paardemiddel, maar voorlopig wel een noodzakelijk middel Doel van het testen Het ontwikkelen en onderhouden van informatiesystemen vereist bijzondere aandacht voor de kwaliteit ervan, dat wil zeggen het voldoen aan de verwachtingen van de diverse gebruikers. Op basis van het bovenstaande ligt het voor de hand te concluderen dat het blootleggen van kwaliteitsgebrek teneinde die op te kunnen (laten) heffen, de belangrijkste doelstelling van het testen is: Testen doe je om de fouten eruit te halen. Hoewel het niet te ontkennen valt dat door middel van testen de kwaliteit verbeterd kan worden, is testen toch niet het geschikte middel om dat te bereiken. Met behulp van testen worden uitsluitend symptomen waargenomen. Het gevaar is daardoor groot dat testen enkel tot symptoombestrijding leidt. Testen zou aanleiding moeten zijn om diagnoses te stellen: het zoeken van de oorzaken achter de problemen. Kwaliteit moet er in worden gebouwd, niet getest! De waargenomen symptomen stellen de organisatie in staat om een diagnose te stellen en de problemen op te lossen. Maar, minstens even belangrijk, die waargenomen symptomen bieden ook de gelegenheid een uitspraak te doen over de risico s die gelopen worden als een bepaalde versie van een systeem in gebruik genomen wordt. Op basis van de waarnemingen gedurende het testen kan door middel van extrapolatie een voorspelling worden gedaan over het systeemgedrag in produktie. 2.2 Wat is testen niet? Testen is niet: 1. alleen meten, maar ook plannen en voorbereiden: Het testen behelst maar 40%, plannen en voorbereiden, vragen 60% van de testinspanning. 2. het vrijgeven of accepteren: Het testen levert advies over de kwaliteit, de beslissing over vrijgave is aan anderen. 3. foutherstel: Slechts bij de programmatest is het mogelijk het testen en herstellen in één hand te leggen. Bij alle andere tests moet het principe gehanteerd worden, dat er niet getest wordt door de persoon die heeft gebouwd en niet hersteld wordt door de persoon die heeft getest. 4. een fase ná ontwikkeling: Parallel aan het opstellen van de functionele specificaties, moet een testplan worden opgesteld. Direct na het vaststellen van de functionele specificaties wordt dan gestart met de voorbereiding van de tests. 5. het implementeren van een informatiesysteem: In principe zijn testen en implementeren tegengestelde, sterk gerelateerde activiteiten, die organisatorisch goed belegd dienen te worden. 6. bedoeld om het systeem te toetsen op volledigheid en juistheid van de functionaliteit; 7. goedkoop: De testkosten schommelen tussen de 20% en 50 % van de ontwikkelingskosten na de fase functionele specificatie. Daarentegen zal een goede, tijdig uitgevoerde test het ontwikkelingsproces positief beïnvloeden en kan een kwalitatief beter systeem opleveren. Het herstellen van fouten vergt meer inspanning, tijd en geld naarmate het moment van detectie verder afligt van het moment van ontstaan. 8. het opleiden voor gebruik en beheer: Hoewel het de voorkeur geniet het testen en het opleiden te scheiden, is de combinatie onder voorwaarden mogelijk. Goede afspraken moeten voorkomen dat zowel de test als de opleiding van onvoldoende kwaliteit zullen zijn. 9. populair. 2.3 Kwaliteitszorg en Testen Definitie van Kwaliteit volgens ISO: Het geheel van eigenschappen en kenmerken van een produkt of dienst dat van belang is voor het voldoen aan vastgestelde of vanzelfsprekende behoeften. Aangemaakt d.d Pagina 4

4 Wat voor de één vanzelfsprekend is, is dat voor de ander absoluut niet. Vanzelfsprekendheid is bij uitstek een subjectief begrip. Een belangrijk aspect van kwaliteitszorg is daarom het minimaliseren van de vanzelfsprekende behoeften, door deze om te zetten in vastgestelde behoeften en het zichtbaar maken in welke mate aan de vastgestelde behoeften wordt voldaan. Daartoe moeten maatregelen worden getroffen om de eisen vast te stellen en het ontwikkelingsproces beheersbaar te maken. Definitie van kwaliteitsborging, quality assurance : Het geheel van alle geplande en systematische acties nodig om in voldoende mate het vertrouwen te geven dat een produkt of dienst voldoet aan de gestelde kwaliteitseisen. Deze maatregelen moeten ertoe leiden dat: er meetpunten en -grootheden zijn die een indicatie geven van de kwaliteit van de processen (normering). het voor de individuele medewerker duidelijk is aan welke eisen zijn werk moet voldoen en dat hij aan de hand van bovengenoemde normen kan toetsen. het voor een onafhankelijke partij mogelijk is de produkten/diensten aan de hand van bovengenoemde normen te toetsen. het management bij gebleken gebreken in (deel)produkten of diensten kan traceren waardoor dat gebrek is ontstaan en hoe het in de toekomst kan worden voorkomen.. Deze maatregelen zijn te onderscheiden in: preventieve maatregelen: voorkomen van diskwaliteit; detectieve maatregelen: ontdekken van diskwaliteit; correctieve maatregelen: opheffen van diskwaliteit. Het is van wezenlijke belang dat er samenhang bestaat tussen de verschillende maatregelen. 2.4 De kwaliteit van informatiesystemen Wat eigenlijk nodig is, is een aantal (onafhankelijk en meetbare) criteria die gezamenlijk het hele kwaliteitsspectrum van een informatiesysteem afdekken. Per criterium dient de Meeteenheid te worden bepaald. Vervolgens kunnen dan per criterium afspraken worden gemaakt omtrent de mate waarin dat aspect in het produkt aanwezig moet zijn: de normering. Dat is helaas nog niet gerealiseerd. Goede aanzetten zijn: Delen 1991, SERC 1993, NGGO 994. De produktkwaliteit wordt ontleed in twee dimensies: Statische dimensie: Beschrijft de beheereigenschappen van een informatiesysteem, ofwel de kwaliteit die wordt ervaren door het systeembeheerder- en onderhoudspersoneel. Het gaat vooral over de aanpasbaarheid van het systeem. Dynamische dimensie: Beschrijft de gebruikseigenschappen van een informatiesysteem, ofwel de kwaliteit van de informatievoorziening in werking. Het gaat over het gebruik van het systeem. 3. Context van het testen 3.1 Dynamisch expliciet testen Het actuele resultaat wordt vergeleken met het verwachte resultaat om zo te bepalen of het systeem zich als vereist gedraagt. De bedoeling is om fouten te vinden. 3.2 Dynamisch impliciet testen Gelijktijdig met het expliciet testen kunnen gegevens over dat testproces worden verzameld. Uit deze gegevens kan informatie worden afgeleid over het wel en wee van het informatiesysteem. Zo kan een uitspraak over de bedrijfszekerheid van het systeem gebaseerd worden op het gedrag van het systeem gedurende de test testperiode: door bij te houden hoe vaak het systeem is geplaagd door storingen en met name trends daarin te zoeken, kan een schatting worden gedaan over de te verwachten storingen gedurende het gebruik. Aangemaakt d.d Pagina 5

5 3.3 Statisch testen Een informatiesysteem is meer dan een programma: het is het totaal van structuren en middelen die gebruikt worden om een organisatie van informatie te voorzien. Een aantal van deze aspecten kan niet door middel van dynamische testen gecontroleerd worden. Dit maakt het noodzakelijk andere vormen van testen aan te wenden. Zo n andere vorm is het controleren en onderzoeken van produkten, zonder dat er sprake is van het uitvoeren van programma s. Dit heet statisch testen. 3.4 Ontwikkel- en testproces Het ontwikkelen van informatiesystemen gebeurt in de meeste gevallen nog steeds volgens het gangbare faseringsmodel, de waterval-methode: 1. informatiebeleid, informatieplanning: Men begint bedrijfsbreed met het definiëren van de mogelijkheden die de informatietechnologie zoal biedt voor de oplossing van problemen of de optimalisatie van de bedrijfsprocessen en men kent daarin prioriteiten toe; 2. informatie-analyse, definitiestudie: Men stelt globaal vast aan welke eisen de functionaliteit moet gaan voldoen; 3. functioneel ontwerp: Men bepaalt vervolgens wat er aan functionaliteit gemaakt moet worden om die problemen op te lossen; 4. technisch ontwerp: Men gaat zich daarna druk maken over hoe dat dan moet worden opgelost; 5. Men maakt het systeem en gaat het vervolgens testen, invoeren en gebruiken. Een momenteel veel gehanteerde presentatie van het faseringsmodel voor systeemontwikkeling en het testen is het zogenaamde V-model (zie figuur 1). Figuur 1 V-model 3.5 Testsoorten Een testsoort is een groep van testactiviteiten die gezamenlijk worden georganiseerd en aangestuurd. Testsoorten kunnen in eerste instantie worden ingedeeld in de zogenaamde white-box en black-box tests. White-box testsoorten Zijn gebaseerd op de coding, de programmabeschrijvingen of het technisch ontwerp. Er wordt nadrukkelijk gebruik gemaakt van kennis over de interne bouw van het systeem. Deze worden uitsluitend uitgevoerd door ontwikkelaars. Onderscheid wordt gemaakt tussen: Programmatest: Een door de ontwikkelaar in de laboratoriumomgeving uitgevoerd test, die moet aantonen dat een programma aan de in de technische specificaties gestelde eisen voldoet. Integratietest: Een door de ontwikkelaar in de laboratoriumomgeving uitgevoerd test, die moet aantonen dat een logische serie programma s aan de in de technische specificaties gestelde eisen voldoet. De nadruk ligt op gegevensdoorvoer en de interface werking. Black-box testen Zijn gebaseerd op de functionele specificaties en de kwaliteitseisen. Het systeem wordt beschouwd in de verschijningsvorm zoals die ook gedurende het uiteindelijke gebruik zal zijn. Onderscheid wordt gemaakt tussen: Systeemtest: Een door de ontwikkelaar in een (goed beheersbare) laboratoriumomgeving uitgevoerde test, die moet aantonen dat het ontwikkelde systeem of delen daarvan aan de in de functionele- en technische Aangemaakt d.d Pagina 6

6 specificaties gestelde eisen voldoen. Acceptatietest: Een door de gebruiker(s) en beheerder(s) in een zoveel mogelijk als-het-ware-produktie-omgeving uitgevoerde test, die moet aantonen dat het ontwikkelde systeem aan de functionele en kwalitatieve eisen voldoet. Deze test geeft antwoorden op de vragen als: Welke risico s worden gelopen bij in gebruikname? Heeft de leverancier aan zijn verplichtingen voldaan? Acceptatie-test wordt opgedeeld in: Functionele acceptatietest: Is gericht op de functionele werking, wordt uitgevoerd door de gebruikers en functioneel beheerders en sluit nauw aan bij de systeemtest. Produktie-acceptatietest: Is gericht op exploitatie-eisen, wordt uitgevoerd door technisch beheerders kort voor de in-produktname. 3.6 Testvormen Een testvorm is een groep activiteiten met het oogmerk het informatiesysteem op een aantal samenhangende kwaliteitsattributen te controleren. Bij de strategiebepaling wordt bepaald op welke manier, dus in welke vorm getest gaat worden. Indien nodig worden nieuwe testvormen bedacht. Op basis van de testvormen kunnen afspraken gemaakt worden over wie welke tests uitvoert. Testvorm Omschrijving Kwaliteitsattribuut o.a. Stress Het laten verwerken van grote hoeveelheden en Bedrijfszekerheid, continuïteit aantallen Middelen gebruik Het meten van de benodigde hoeveelheid middelen Zuinigheid (disk, geheugen, etc.) Herstel Het testen van de herstel en herstart faciliteiten Herstelbaarheid Produktie Het testen van de produktie procedures Juistheid, bedrijfszekerheid Standaards het testen van de standaards Beveiliging, bruikbaarheid Beveiliging Het testen van de beveiliging Beveiliging, geoorloofdheid Functionaliteit Het testen van de functionaliteit (inclusief Juistheid volledigheid foutafhandeling) Regressie Het testen dat alle onderdelen nog correct functioneren Alle na het doorvoeren van een wijziging Handmatige Het testen van de relatie tussen het geautomatiseerde Inpasbaarheid ondersteuning en het handmatige deel van het systeem Interfaces Het testen van aansluitingen met andere systemen Juistheid, volledigheid Controls Het testen van controles, zoals audit-trails, gegevensvalidaties, enzovoorts Controleerbaarheid, beveiliging, juistheid Referentie schaduw draaien 4. Gestructureerd testen Het testen of twee versies van een applicatie een identieke interface hebben Juistheid, volledigheid Uit diverse onderzoek naar het testproces in de afgelopen jaren is de onvolwassenheid van het testen bevestigd. Testen wordt meestal gezien als een noodzakelijk kwaad dat alleen maar geld en vooral veel tijd kost. Veel organisaties zijn, na de zoveelste structureringspoging, nog steeds zoekende. De meeste aanzetten tot het op een hoger plan brengen van het testen zijn gestrand op allerlei, meestal voorspelbare, oorzaken. Naast de toenemende functionele en technische complexiteit van de informatiesystemen en de steeds wijzigende ontwikkelmethoden, technieken en hulpmiddelen vinden deze oorzaken vooral hun oorsprong in de organisatie van het testen; enerzijds en de organisatie van het structureringsproces van het testen, anderzijds in de organisatie en de beheersing van het testproces zelf. Aangemaakt d.d Pagina 7

7 4.1 Ongestructureerd testen: de bevindingen Traditionele valkuilen, die de structurering van het testen met zich meebrengen: Tijdsdruk: Een ongestructureerd testproces verliest het vrijwel altijd van tijdsdruk. Wachthouding: Te late start van de voorbereiding. Fasering van de testactiviteiten: Het ontbreekt vaak aan een voorgeschreven aanpak waarin de testactiviteiten minimaal in fasen zijn onderverdeeld en beschreven. Testtechnieken en tools: Hoewel dikwijls wel aanwezig, worden de testtechnieken en tools niet gebruikt. Fixatie van de specificaties: In contracten voor de ontwikkeling of het onderhoud van informatiesystemen wordt het testen als bijzaak gezien en formele gronden voor oplevering en/of niet-acceptatie zijn in de meeste gevallen niet beschikbaar. De specificaties blijken in veel gevallen niet gefixeerd en beheerd te zijn. Beheer: Een testproces strandt nogal eens door het ontbreken van de vereiste beheerfuncties, als configuratie- en wijzigingsbeheer. Kwaliteit van de white-box tests laat in veel gevallen te wensen over. Tegengestelde belangen: Ontwikkelaars willen zoveel mogelijk tijd om het product te optimaliseren. Het rekencentrum moet voordat het systeem in produktie gaat inzicht hebben in een groot aantal aspecten. Testers/gebruikers/beheerders willen de tests conform de testplanning uitvoeren. De opdrachtgever wil simpelweg tegen de minste kosten en moeite de optimale oplossing voor het probleem. Coördinatie van de testactiviteiten: Het ontbreekt in projecten of in organisaties vaak aan voorschriften over de te hanteren testmethoden en technieken. 4.2 Gestructureerd testen: de aanbevelingen Om het testproces binnen een project of de testprocessen in een organisatie te structureren kunnen de belangrijkste bevindingen uit de diverse onderzoeken als basis dienen. Reductie van de tijdsdruk. Dit wordt bereikt door: tijdige, flexibele planning; voortgangsbewaking; een tijdige start; voldoende en geschikt personeel; sluitende afspraken. Reductie van de tijdsdruk wordt bevorderd door tijdig een mastertestplan op te stellen, waarin geregeld is welke partijen, welke tests, op welke momenten uitvoeren. De technieken strategiebepaling en testpuntanalyse (TPA) leveren de daarbij vereiste ondersteuning. Projectmatige aanpak, los van de lijnbeslommeringen : De testactiviteiten moeten op basis van het testplan projectmatig worden aangepakt. De ruis van de lijn, zoals afdelingsoverleg, atv-verplichtingen, nevenactiviteiten en opleidingen, moet daarbij tot het minimum beperkt blijven. Het is raadzaam de testactiviteiten stringent te scheiden van de dagelijkse lijnbeslommeringen. Aangemaakt d.d Pagina 8

8 Fasering van de testactiviteiten, parallel aan de bouwactiviteiten: Testactiviteiten moeten op enig moment tijdens het proces van systeemontwikkeling starten en in onderlinge samenhang met andere activiteiten worden uitgevoerd. Dat vraagt om een zorgvuldige fasering. Een faseringsmodel moet per testsoort fasegewijs de activiteiten beschrijven tot het niveau van wat en wanneer. Voorschriftgeving en controle op de toepassing: De te gebruiken standaards voor het testen (faseringsmodel, documentatie, technieken, tools, enzovoort) moeten tijdig, eenduidig en centraal worden voorgeschreven. Gestructureerd en passend gebruik van testtools: In theorie kunnen de meeste testactiviteiten geautomatiseerd worden uitgevoerd, dat wil zeggen er zijn testtools voor beschikbaar. Als de vereiste structuur in het testproces is aangebracht kunnen testtools passend worden ingezet. In eerste instantie moet daarbij gedacht worden aan ondersteunende tools voor begroting, planning, voortgangsbewaking, beheer van testdata, coverage analysers en rapportage tools. In tweede instantie aan zogenaamde primaire testtools voor onder andere testontwerp en record & playback. Inrichting beheer: Het gaat hier om het beheer van het testproces zelf; haar omgeving en de testattributen zoals het testobject, de specificaties en de testware. Reductie van tegengestelde belangen en teambuilding: Door het vroegtijdig opstellen van een mastertestplan waarin zoveel mogelijk afspraken tussen de diverse betrokkenen worden vastgelegd, wordt voorkomen dat in een later stadium conflicten de voortgang en het werkklimaat negatief beïnvloeden. Inrichten van een testcoördinatie en/of testhelpdesk functie: Een facilitaire discipline die waar nodig de testactiviteiten coördineert en als helpdesk fungeert. 4.3 De vier pijlers onder een gestructureerde testaanpak De vier pijlers zijn een aan de ontwikkelingscyclus gerelateerde: Fasering (F): Door gebruik van een faseringsmodel wordt het overzicht behouden tijdens het systeemontwikkelingsproces. Door te noteren wat, wanneer, hoe, waar (mee), door wie, enz., moet gebeuren in het stramien van het proces, worden vanzelf de claims op en de relaties met de overige aspecten (pijlers) gelegd. Figuur 2 De vier pijlers Technieken (T): Er zijn technieken ter ondersteuning van het planningsproces, intake en rapportage technieken. De belangrijkste groep technieken wordt gevormd door de testspecificatietechnieken waarmee bepaalde eigenschappen (kwaliteitsattributen) van een informatiesysteem worden gemeten. Er is geen enkele techniek waarmee alle attributen gemeten kunnen worden. Infrastructuur (I): Om tests te kunnen uitvoeren is een testomgeving nodig. Deze omgeving moet stabiel, beheersbaar en representatief zijn. Verder moet deze omgeving zijn afgescheiden van andere omgevingen, zoals de ontwikkelingsomgeving. Organisatie (O): Enerzijds is er de organisatie binnen het testteam, anderzijds is er de inbedding van het testteam in de projectorganisatie. Voor iedere test moet beschreven zijn wie hem uitvoert, wie er verantwoordelijk voor is, wie controleert dat de test goed is uitgevoerd en aan wie de resultaten worden doorgegeven. Aangemaakt d.d Pagina 9

9 5. TMap in een notedop 5.1 Testen als proces Voor alle testsoorten en vormen gelden de hoofdactiviteiten plannen, voorbereiden en uitvoeren. In grote lijnen komt het erop neer dat tijdens de creatie of aanpassing van de functionele specificaties een mastertestplan wordt opgesteld, waarin geregeld is wie, wanneer, welke testsoort of testvorm voor zijn rekening neemt. Omdat het testen meerdere disciplines raakt moeten de diverse taken, verantwoordelijkheden, mijlpalen en produkten worden beschreven in een testplan. In grotere projecten wordt de opdracht voor het tot stand komen en coördineren van dat testplan vaak belegd bij het management van een, al dan niet onafhankelijk, testteam. Op basis van het dit (Master)testplan worden vervolgens deeltestplannen gemaakt, meestal: een White-box testplan; een Systeem testplan; een Acceptatie testplan. Na fixatie van de testplannen worden parallel aan de ontwerp- en realisatie-activiteiten de testgevallen en de testinfrastructuur ontwikkeld. Na de oplevering van het testobject wordt dan het daadwerkelijke testen uitgevoerd. Een testproces introduceert naast het systeemontwerp dus een tweede ontwerpproces, het testproces. 5.2 Testfasering In het faseringsmodel van TMap zijn de drie hoofdactiviteiten van het testen verdeeld over een vijftal fasen, te weten: 1. planning en beheer; 2. voorbereiding; 3. specificatie; 4. uitvoering; 5. afronding. Het TMap-faseringsmodel is een generiek model. Het is toepasbaar voor alle testsoorten en vormen. Voor de White-box testen bevat het te veel activiteiten. Het is aan de Figuur 3 Het TMap-faseringsmodel testverantwoordelijkheden de passende keuze te maken uit het TMap-arsenaal. Binnen de hiërarchie van de testplannen zullen in een systeemontwikkelingsproces dus meerdere TMapmodellen functioneren voor de verschillende testsoorten De fase Planning en beheer De fase Planning en beheer start tijdens de specificatiefase. De uit te voeren activiteiten leggen de basis voor een beheersbaar en kwalitatief testproces. Nadat de testopdracht is gefixeerd wordt globaal kennis gemaakt met de specificaties, de materie en de organisatie (van het project). Het is onmogelijk het systeem volledig te testen. 100% dekkende testtechnieken bestaan alleen in theorie en geen enkele organisatie heeft daar tijd en geld voor. Daarom wordt via risicotaxatie de teststrategie bepaald. Afhankelijk van de risico s wordt vastgesteld welke systeemdelen de meeste aandacht zullen krijgen en welke wat minder, enz. Een en ander wordt uiteraard nadrukkelijk afgestemd met de opdrachtgever. Testers mogen en kunnen dat niet zelf beslissen. Het doel is: De best haalbare dekkingsgraad op de juiste plaats. Aangemaakt d.d Pagina 10

10 Het is belangrijk dat gedurende alle fasen van het testproces kwaliteitsindicaties worden afgegeven. Tegen het einde van het testproces wil de opdrachtgever, zo nodig onderbouwd met statistische informatie, weten welke risico s er gelopen worden en dus welke maatregelen er genomen moeten worden. Er kan bijvoorbeeld worden besloten nog langer te testen of gedeeltelijk in produktie te gaan. Aangemaakt d.d Pagina 11

11 5.2.2 Activiteiten Planning en beheer opdrachtformulering; globale intake en studie; vaststellen testbasis; bepalen strategie; inrichten organisatie; inrichten testprodukten; definiëren infrastructuur; inrichten beheer; bepalen planning; fixeren testplan; onderhouden testplan; uitvoeren beheer; rapporteren; bepalen detailplanning De fase Voorbereiding De fase begint met de detail intake van de specificaties en de overige documentatie die als testbasis dient. Er wordt inzicht in de testbaarheid verkregen door te onderzoeken op bijvoorbeeld uniforme notatie, scheidbaarheid en herkenbaarheid. Naar aanleiding hiervan zal de kwaliteit van de testbasis kunnen toenemen. Na de intake wordt de testbasis (in samenwerking met de bouwers) onderverdeeld in onafhankelijke opleverbare en testbare systeemdelen. Vervolgens wordt aan deze testeenheden de testtechnieken toegewezen en wordt een planning gemaakt van het vervolg van de testactiviteiten Activiteiten Voorbereiding detail intake testbasis; definiëren testeenheden; toewijzen testtechnieken; specificeren infrastructuur De fase Specificatie Tijdens de fase Specificatie worden de testgevallen gespecificeerd en de bijbehorende testinfrastructuur gerealiseerd. De creatie van testgevallen wordt in twee stappen uitgevoerd: het logisch en het fysiek testontwerp. Op het moment dat de testbasis beschikbaar is, worden op basis daarvan (logische) testgevallen gespecificeerd (testspecificaties). Bij een testgeval moet hierbij worden gedacht aan de beschrijving van de uitgangssituatie, het veranderingsproces en de resultaatvoorspelling. Later als er meer bekend is over de technische realisatie, worden de logische testgevallen vertaald naar fysieke testgevallen (testscripts) Activiteiten Specificatie opstellen testspecificaties; definiëren uitgangsbestanden; opstellen testscripts; opstellen testdraaiboek; specificeren intake testobject/infrastructuur; realiseren infrastructuur De fase Uitvoering De fase Uitvoering start op het moment dat de eerste testbare componenten beschikbaar zijn. Eerst worden de opgeleverde (delen van) applicaties gecontroleerd op volledigheid en in de testomgeving geïnstalleerd. Daarna wordt gecheckt of het samenstel van applicaties en technische infrastructuur überhaupt werken (intake). Om het testen te beginnen moeten de initiële testbestanden gevuld worden. Als zowel de (delen van) de applicaties, de infrastrctuur als de initiële bestanden klaar staan, worden de zogenaamde pretest uitgevoerd met als doel de werking van de hoofdtaken van het te testen object te Aangemaakt d.d Pagina 12

12 controleren. De pretest geven het antwoord op de vraag: Is de kwaliteit van het testobject van dien aard dat het grondig aan de tand gevoeld kan worden met de daadwerkelijke testuitvoering Activiteiten Uitvoering intake testobject / infrastructuur; vullen uitgangsbestanden uitvoeren (her)tests; controleren en beoordelen testresultaten; onderhouden testdraaiboek De fase Afronding Tijdens de afronding wordt er een selectie gemaakt van de vaak grote hoeveelheid testware, zoals de testgevallen, de testresultaten en ook bijvoorbeeld de beschrijvingen van de testinfrastructuur en de gebruikte tools. Het oogmerk is hierbij dat bij wijzigingen en de bijbehorende onderhoudstests de testware alleen maar aanpassing behoeft en er dus niet opnieuw een complete nieuwe testset moet worden ontworpen (regressietesten) Activiteiten Afrondingsfase evalueren testobject; evalueren testproces; opstellen evaluatierapport; Figuur 4 Activiteiten in de TMap-fasering conserveren testware; decharge testteam. 5.3 Testtechnieken Testtechnieken per TMap fase Planning en beheer Strategiebepaling; Testpuntanalyse (TPA); Diverse checklists. Voorbereiding Detail intake testbasis; Fagan inspection. Specificatie Testspecificatietechnieken Uitvoering Checklists kwaliteitsattributen Afronding Diverse checklists Strategiebepaling Het bepalen van een expliciete teststrategie is een instrument om met de opdrachtgever (van de test) te communiceren over de organisatie en de strategische keuzen van het testen. De opdrachtgever van een test verwacht bepaalde kwaliteiten van het op te leveren systeem die van geval tot geval heel verschillend zijn. Het is van groot belang in staat te zijn daarover met de opdrachtgever te kunnen communiceren, en afhankelijk van de wensen van de opdrachtgever een vertaling te maken naar de manier waarop getest zal worden. Een risicotaxatie vormt de basis voor de teststrategie, omdat het van belang is de testinspanning (testdekking) optimaal in te zetten. Met de techniek voor strategiebepaling wordt geanalyseerd hoeveel in een test moet worden geïnvesteerd om de optimale balans te vinden tussen de gewenste kwaliteit en de hoeveelheid tijd c.q. geld die daarvoor nodig is. Aangemaakt d.d Pagina 13

13 5.3.2 Testpuntanalyse (TPA) TPA is geschikt voor het begroten van de black-box testsoorten, systeem- en acceptatietest. TPA herleidt de Functie-Punt-Analyse (FPA) punten naar testpunten op basis waarvan vervolgens het aantal testuren berekend wordt. De TPA-techniek analyseert de impact van specifieke testbeïnvloedingsfactoren, zoals bijvoorbeeld de kwaliteitseisen, de omvang en de complexiteit van het systeem, maar ook de kwaliteit van de testbasis of de mate waarin testtools worden gebruikt Detail intake testbasis De testbasis wordt gevormd door de documentatie op basis waarvan de tests worden voorbereid. De intake is in wezen een audit van de testbasis waarbij gekeken wordt of de documentatie voldoende compleet, accuraat en consistent is om als uitgangspunt voor de test te dienen Testspecificatietechniek Op basis van de uitgangsinformatie moeten testgevallen worden bepaald. Een elementair testgeval bestaat uit: de uitgangssituatie; het veranderingsproces en; een resultaatvoorspelling. Een testspecificatietechniek Is een gestandaardiseerde manier om vanuit uitgangsinformatie testgevallen af te leiden Checklists Tmap biedt een groot aantal checklists (zie bijlage B - Checklists). 5.4 Infrastructuur en tools De infrastructuur voor het testen bevat alle faciliteiten en middelen die nodig zijn om naar behoren te kunnen testen: testomgevingen: Testomgevingen worden ingericht op basis van de testsoort en testvorm. laboratorium omgeving voor White-box testen; beheersbare systeemtestomgeving; de als het ware omgeving voor acceptatietesten. testtools: record & playback: Het kunnen opnemen van een testsessie om die naderhand automatisch te kunnen spelen. comparators: Het automatisch vergelijken van testresultaten met resultaten van voorgaande sessies. testdrivers: Een vervanging van een aansturingsprogramma dat nog niet is opgeleverd, om toch de onderliggende delen al te kunnen testen. simulators: Tools waarmee de life-omgeving kan worden nagebootst voor het testen van bijvoorbeeld de performance. coverage analysers: Daarmee wordt gemeten in hoeverre het testobject door testgevallen is gedekt. werkplekken (kantoorinrichting) 5.5 Organisatie De organisatie van gestructureerd testen vraagt aandacht op de volgende aspectgebieden: het operationele testproces; de structurele testorganisatie; testbeheer; personeel & opleidingen; Aangemaakt d.d Pagina 14

14 structurering van het testproces. Aangemaakt d.d Pagina 15

15 5.5.1 Het operationele testproces De belangrijkste functies zijn: testen; testmanagement; beheer. Kennis dient aanwezig te zijn op het gebied van: testen; het testobject; gebruik en beheer; infrastructuur en tools De structurele testorganisatie Kent twee functies: voorwaarde scheppende testvoorschriftgeving coördinatie van testprocessen testbeheer methodische en technische ondersteuning operationele Testbeheer Het in bedwang houden van: het testproces; de testinfrastructuur; de testprodukten Structurering van het testproces Teststructurering vindt meestal haar oorsprong in een of andere kostbare fout of, zo u wilt, ramp. Het management besluit dan dat er nu maar eindelijk eens iets moet gebeuren. Er wordt iemand belast met de structurering en er wordt alvast een project of een systeem als pilot geselecteerd, waarmee die structurering zich moet bewijzen. Dat gaat nogal eens mis. Een structureringsproces vraagt een strategie en know-how op zowel het gebied van organisatieverandering als van testen. Na inventarisatie van de actuele testpraktijk en de mogelijkheden voor het structureringsproces moet stapsgewijs getransformeerd worden van ist naar soll. Tijd en tact spelen daarbij een belangrijke rol. 6. Variaties op het thema 6.1 Inleiding TMap is een generiek model. De oorspronkelijk voor het black-box testen in nieuwbouw situaties ontworpen aanpak is geëvalueerd tot een werkbasis voor vrijwel alle testsoorten en testactiviteiten in de informatievoorziening. De TMap-pijlers fasering, technieken, infrastructuur en organisatie kunnen voor andere testvormen worden gehanteerd. Dit vraagt het een en ander van zowel de samenstellers van de TMap-standaard als van de gebruikers daarvan. Primair staat een verantwoord testproces, niet onderbelicht maar vooral ook niet overdone. Soms vraagt een testproces extra s in de vorm van speciale technieken of een afwijkende organisatiestructuur. Die kunnen dan meestal gemakkelijk van de standaard worden afgeleid. Vanwege verscheidenheid in aanbod en gebruiksvormen is het uiteraard onmogelijk dé standaard testinfrastructuur te beschrijven. TMap biedt een referentiekader op basis waarvan de testinfrastuctuur kan worden gedefinieerd. Aangemaakt d.d Pagina 16

16 6.2 Variaties Bij elke standaard aanpak ontstaan in het gebruik variaties die zich min of meer als een specifieke subset van de standaard ontwikkelen. Hierna wordt ingegaan op enkele gebieden waarin dit fenomeen zich met betrekking tot TMap voordoet. 6.3 Testen in de onderhoudssituatie TMap kan zowel worden gebruikt bij nieuwbouw als bij het onderhoud van informatiesystemen. Er is slechts sprake van een benadering vanuit een ander perspectief, hetgeen een aantal accentverschuivingen veroorzaakt (zie figuur 5). In grote lijnen kun echter gesteld worden dat het onderhoudstesten op dezelfde manier kan worden aangepakt als bij nieuwbouw Ontwikkel- en testproces Het ontwikkel- en testproces, dat geldt in nieuwbouwsituaties, verandert voor onderhoud in principe niet. Er is sprake van een white-box programma- en integratietest en van een black-box systeem- en acceptatietest. Een onderhoudstestproces start meestal bij de ontvangst van een wijzigingsaanvraag of een releaseplan Soorten onderhoud Met betrekking tot het soort onderhoud is uit het oogpunt van het testen een tweedeling te maken: planbaar onderhoud: Tot deze categorie behoren: perfectief onderhoud (aanpassen van de programmatuur aan nieuwe wensen) adaptief onderhoud (aanpassen van programmatuur aan veranderingen in de omgeving) correctief planbaar onderhoud (uitstelbaar herstel van fouten of tekortkomingen) ad-hoc correctief onderhoud: Ad-hoc correctief onderhoud heeft te maken met storingen die onmiddellijk om een oplossing vragen. Het zal niet mogelijk zijn de benodigde stappen van een gestructureerde testaanpak uit te voeren. Ook ten aanzien van ad-hoc onderhoud is het mogelijk om door middel van een bepaalde testaanpak een kwaliteitsverbetering te realiseren. Belangrijk is het uitvoeren van een goede risico-analyse met betrekking tot het informatiesysteem en op basis van de uitkomsten ervan, het definiëren van een aantal standaard tests. 6.4 Geïntegreerde testaanpak Figuur 5 Systeemonderhoud in het V-model In veel organisaties worden de systeemtest en de acceptatietest geheel of gedeeltelijk samengevoegd. Dit verschijnsel wordt de Geïntegreerde testaanpak genoemd. Bij toepassing van een geïntegreerde test wordt tevoren tussen de partijen afgesproken welke aspecten bij welke test en tot welk niveau aan de orde komen. Doorgaans door het toewijzen van kwaliteitsattributen en daaraan gekoppeld de testvormen en de te gebruiken technieken of een te realiseren dekkingsgraad. De ontwikkelaars en de gebruikers specificeren ieder hun eigen testgevallen, zoveel mogelijk onafhankelijk van elkaar, parallel aan de technisch ontwerpfase en de systeemrealisatie. Een geïntegreerde test wordt voorafgegaan door een (gereduceerde) systeemtest. De overeengekomen aspecten worden tot het afgesproken niveau door de ontwikkelaars aan een systeemtest onderworpen. De gebruikers spelen daarbij geen rol. Na uitvoering van het systeemtestdeel wordt in samenwerking tussen de ontwikkelaars en de gebruikers het systeem geconfronteerd met de voor het geïntegreerde deel overeengekomen testgevallen. Aangemaakt d.d Pagina 17

17 Ten aanzien van de verantwoordelijkheden moet worden opgemerkt dat de ontwikkelaar onverminderd verantwoordelijk blijft voor het ter acceptatie aan te bieden produkt. De participatie van de gebruiker bij de geïntegreerde test moet uitsluitend gekenschetst worden als ondersteuning van het ontwikkelproces. De gebruiker accepteert het systeem door het uitvoeren van een acceptatietest Risico s, maatregelen en overwegingen De geïntegreerde testaanpak kan slechts worden toegepast nadat vooraf eenduidige afspraken gemaakt zijn over een groot aantal aspecten. Een belangrijk risico van de geïntegreerde testaanpak is de verminderde onafhankelijkheid van de betrokkenen. Hoewel formeel goede afspraken te maken zijn, kunnen conflicten ontstaan over allerlei onderwerpen. Een risico bij de geïntegreerde test is de late constatering dat één van de partijen geen goede test heeft voorbereid. Het is dan vaak niet meer mogelijk om die schade te herstellen. Een maatregel ter voorkoming van conflicten en of te late constatering van onvoldoende voorbereiding voor het testen, is het inschakelen van een controlerende derde partij. Deze taak kan bijvoorbeeld worden ingevuld door een kwaliteitszorg medewerker. 6.5 Client/Server, GUI s, OO, RAD, CASE en CAST Steeds meer informatiesystemen worden geëxploiteerd in andere dan de klassieke mainframe infrastructuur. De beperkingen van de mainframe omgevingen remmen organisaties snel te kunnen inspelen op veranderende wensen uit de markt. Diensten en produkten moeten met concurrerende snelheid in exploitatie kunnen worden gebracht. Time-to-market is de slogan van de jaren negentig. Om in dat kader doeltreffend te kunnen opereren wil de gebruiker tijdig en snel over betrouwbare informatie beschikken. Hij wil daarvoor een flexibele informatie infrastructuur. Om zijn doel te bereiken wil de gebruiker vanaf zijn werkplek alle beschikbare applicaties en gegevens kunnen aanwenden. Dat vraagt integratie van hardware en applicaties, van hulpmiddelen en (lokale) netwerken, open systemen, enzovoort. Deze mogelijkheden worden in het algemeen geboden door de zogenaamde client/server technologie Client/Server De client/server technologie bestaat uit een groot aantal componenten voor zowel ontwikkeling als exploitatie. Vooralsnog kan Figuur 6 De vijf Client/Server architecturen (Gartner Group) het fenomeen client/server worden beschreven als een technologie waarin informatiesystemen in onafhankelijke processen worden onderverdeeld, die door clients worden geïnitieerd en door servers worden uitgevoerd. Het gebruik van een standaard communicatie taal is daarbij essentieel. Voor het testen is het van belang over de logische inrichting van applicaties duidelijkheid te verkrijgen. Informatiesystemen zijn in het algemeen onderverdeeld in 3 logische onderdelen: presentatie; toepassing; gegevens. Dit onderscheid speelt een belangrijke rol bij het distribueren van delen van een applicatie over meerdere hardwareplatforms. In samenhang hiermee heeft de Gartner Group vijf client/server architecturen (zie figuur 6) vastgesteld, waarbinnen de logische applicatieonderdelen over client en server verspreid zijn. Deze verdeling van de applicatie-onderdelen is van grote invloed op het testen, in het bijzonder op de toe te passen teststrategie en testspecificatietechnieken. Er is sprake van dislocatie van functionaliteit en gegevens en een veelheid aan nieuwe c.q. afwijkende situaties voor de tester in de client/server omgeving Graphical User Interfaces (GUI s) De transformatie van karakter-georiënteerde naar grafisch georiënteerde software voor gebruikersinterfaces (GUl s) vraagt ook een transformatie van de testwijze en voorlopig meer testinspanning. Aangemaakt d.d Pagina 18

18 Voor het testen geldt dat er een aantal testniveaus te onderscheiden is: individuele vensters interactie tussen vensters individuele applicaties interfaces tussen applicaties. Daarbinnen vragen de verschillende schermattributen hun eigen aandacht. Het is van belang de GUl-tests in de aangegeven niveaus te organiseren. De tests worden dakpansgewijs opgezet, waarbij na elke test weer de werking van een attribuut of een component wordt goedgekeurd, tot en met de integrale werking van de totale interface. Wellicht nog sterker dan bij andere tests is het aantal mogelijke testsituaties bij GUl-tests vrijwel onbeperkt. Het gebruik van testtools is bij het testen van GUl s sterk aan te raden. Zeker record & playback tools die de vele scherminteracties nauwkeurig en snel kunnen (her) testen zijn zeer bruikbaar, of eigenlijk een must Object Oriented Development (OO) Voor wat betreft het testen is OO alleen een (gestructureerde) stap meer in de goede richting. De werkwijze bij het ontwerp (onderkennen, beschrijven, classificeren en structureren van objecten) en de realisatie (specificeren, bouwen en implementeren van methods) bieden testers de vereiste structuur. Zowel de white-box als de black-box tests, en daarbinnen zowel de intake van de testbasis als de statische en de dynamische tests, kunnen conform de TMap-bouwstenen worden uitgevoerd. De mogelijkheden van parallellisatie van tests en de integratie van testspecificaties van ontwikkelaars en gebruikers zullen door OO toenemen. Zoals altijd geldt ook hier dat testers optimaal van de voordelen kunnen profiteren bij consequente toepassing van de ontwikkelstandaards en standaard functionaliteit. Hoe meer daarvan wordt afgeweken, hoe meer testinspanning vereist is! RAD, Evolutionaire systeemontwikkeling In grote lijnen komt het er op neer dat bij RAD de nadruk ligt op het specificeren, prototypen en realiseren van systeemdelen in kleine teams van gebruikers en ontwikkelaars, waarbij gebruik gemaakt wordt van de meest geavanceerde hulpmiddelen. De evolutionaire aanpak kan in principe RAD impliceren, maar legt meer nadruk op het stapsgewijs ontwikkelen c.q. aanpassen van kleine systeemdelen naar de uiteindelijke gewenste totaaloplossing. Het testen bij dit soort ontwikkelingsprocessen is bij consequente toepassing van de overeengekomen werkwijze gemakkelijker. De deelontwikkelingen kunnen als dakpannen worden beschouwd, die alle hun eigen testproces kunnen doorlopen. Zowel de testbasis (de specificaties) als het testobject komt dakpansgewijs tot stand en kan als zodanig als invoer dienen voor specificatie en de uitvoering van de respectievelijke white-box en black-box tests CASE en CAST Computer Aided Software Engineering en Testing stellen een verzameling hulpmiddelen voor waarmee in theorie systemen vanaf de specificaties geheel geautomatiseerd gerealiseerd en getest kunnen worden. Zowel de software als de testware worden vanaf de Specificaties gerealiseerd en vervolgens met elkaar geconfronteerd. De resultaten worden automatisch vergeleken en wellicht automatisch hersteld. Een kind kan de was doen. De systeemontwikkeling beperkt zich tot de selectie en toepassing van tools! Impact algemeen In het algemeen concentreert de impact van client/server en gerelateerde technologieën en ontwikkelingsmethoden op het testen zich vooralsnog op de volgende aspecten: Toepasbaarheid van TMap: Tmap biedt voldoende bouwstenen voor de inrichting en uitvoering van testprocessen. Meer aandacht voor het ontwikkelingsproces en de gebruikte hulpmiddelen: De aandacht zal verschuiven van het testobject naar het ontwikkelingsproces en de consequente toepassing van de gebruikte hulpmiddelen. Uitgaan van consequent gebruik van ontwikkelstandaards: Tests zullen worden afgestemd op strikte toepassing van de standaards voor bijvoorbeeld modulariteit, Aangemaakt d.d Pagina 19

19 object oriëntatie en het gebruik van hulpmiddelen. Nieuwe testvormen: Voor sommige aspecten zullen nieuwe of afwijkende testnormen ontstaan. Technology-push: De tester wordt voortdurend geconfronteerd met een niet aflatende technology-push en het kost veel tijd en inlevingsvermogen van het testpersoneel om bij te blijven. Aangemaakt d.d Pagina 20

20 Onvolwassenheid technologie: De veelheid, de complexiteit en het innovatieve karakter van de toegepaste technologische hulpmiddelen is op zichzelf een bron van fouten. Bij het bepalen van de teststrategie moet dit fenomeen aandacht krijgen. Verhouding bouw- en testinspanning: De ervaring leert dat de technologische ontwikkelingen zich het eerst richten op de technische infrastructuur; daarna op de ontwikkelings- en beheeraspecten en vervolgens pas op het voorzien in passende testinstrumenten. Hierdoor dreigt de verhouding testinspanning ten opzichte van bouwinspanning onevenwichtig te worden. Door toepassing van evolutionaire en rapid ontwikkelingsmethoden wordt de tester in dit kader ook nog geconfronteerd met een latere beschikbaarheid van de testbasis (de specificerende documentatie). De structureel bij het testen aanwezige tijdsdruk zal voorlopig dus toenemen. Daarom moet gezocht worden naar een nog betere balans tussen: tijd en kwaliteit van het testproces; testen en toetsen (meer toetsen dan voorheen); white-box en black-box tests (meer integratie). 6.6 Testen van pakketten Inleiding Het aanschaffen van een pakket in plaats van het zelf ontwikkelen van software is iets wat steeds vaker voorkomt. Het aantal beschikbare pakketten, alsmede de goede kwaliteit ervan, is hier vooral debet aan. Wat zijn echter de gevolgen van deze ontwikkeling voor het testen? De doelstelling van testen is het verkrijgen van een bepaalde mate van inzicht in de kwaliteit. In dit kader is bij het testen van pakketten een drietal vragen van belang: 1. Voldoet het pakket aan de leveranciersspecificaties? beantwoorden d.m.v. de Innametest 2. Voldoet het pakket aan de wensen en eisen van de Organisatie? beantwoorden d.m.v. de Functietest 3. Kan het pakket in produktie worden genomen? beantwoorden d.m.v. de Acceptatietest De eerste twee vragen dienen in principe te worden beantwoord tijdens het proces van pakketselectie (dus voordat het pakket is aangeschaft!) en de laatste vraag tijdens het implementatieproces De Innametest Het vaststellen of het pakket voldoet aan de leveranciersspecificatie is het eerste aspect dat moet worden beoordeeld. De leveranciersspecificaties vormen dus de testbasis voor de innametest. Voor het uitvoeren van de innametest zijn er verschillende mogelijkheden: uitvoeren en beoordelen bijgeleverde testset; zelf testen van kritieke functies; statisch testen, door analyse van ervaringen van bestaande gebruikers en beoordeling van tests en de kwaliteitszorg van de leverancier De Functietest Nadat is vastgesteld dat het pakket voldoet aan de leveranciersspecificatie, moet worden beoordeeld of het pakket voldoet aan de wensen en eisen van de organisatie. Dit is het moeilijkste, maar ook het belangrijkste onderdeel van pakkettesten. De volgende TMap-activiteiten worden in het kader van de functietest minimaal onderkend: bepalen teststrategie fixeren testplan detail intake testbasis opstellen testspecificaties opstellen testdraaiboek uitvoeren (her) tests controleren en beoordelen testresultaten rapporteren Aangemaakt d.d Pagina 21

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

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

Examen TMPA Test Management Approach (TMap) Professional Advanced

Examen TMPA Test Management Approach (TMap) Professional Advanced Examen TMPA Test Management Approach (TMap) Professional Advanced Publicatiedatum Startdatum 6 juni 2003 1 mei 2003 Doelgroep De module is bestemd voor (beginnende) professionele testers met een ½ tot

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

TMap in een notedop. Martin Pol en Erik van Veenendaal

TMap in een notedop. Martin Pol en Erik van Veenendaal TMap in een notedop Martin Pol en Erik van Veenendaal De vier pijlers onder een gestructureerde testaanpak zijn een aan de ontwikkelingscyclus gerelateerde fasering van de testactiviteiten, een goede organisatorische

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

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

TMap NEXT Test Engineer

TMap NEXT Test Engineer Voorbeeldexamen TMap NEXT Test Engineer Editie juni 2013 Copyright 2013 EXIN All rights reserved. No part of this publication may be published, reproduced, copied or stored in a data processing system

Nadere informatie

TMap NEXT Test Engineer

TMap NEXT Test Engineer Voorbeeldexamen TMap NEXT Test Engineer Editie juli 2011 Copyright 2011 EXIN All rights reserved. No part of this publication may be published, reproduced, copied or stored in a data processing system

Nadere informatie

EISEN AAN TESTPLANNEN

EISEN AAN TESTPLANNEN EISEN AAN TESTPLANNEN Auteur : Datum : Versie :.. Status :.. Datum overdracht : Overgedragen aan : Inhoudsopgave 1 Inleiding...

Nadere informatie

ISTQB Foundation level. Een introductie. Algemene informatie voor medewerkers van: SYSQA B.V.

ISTQB Foundation level. Een introductie. Algemene informatie voor medewerkers van: SYSQA B.V. ISTQB Foundation level 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... 3

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

NGI-Noord. Mei 2007. Tim Koomen Leo van der Aalst Michiel Vroon

NGI-Noord. Mei 2007. Tim Koomen Leo van der Aalst Michiel Vroon NGI-Noord Mei 2007 Tim Koomen Leo van der Aalst Michiel Vroon TMap of TMap Next? TMap = methode TMap Next = boektitel TMap Next = externe communicatie. Waarom? Actualisering van de methode Testen integraal

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

PAT PT IT ST. ontwikkelaarstests. acceptatietests GT FAT

PAT PT IT ST. ontwikkelaarstests. acceptatietests GT FAT 42 Testen volgens TMap - Deel I Algemeen laat staan vergezeld van de voor de acceptatietest onmisbare documentatie, zoals de gebruikershandleiding. Geleidelijk aan is daarom de behoefte ontstaan om bij

Nadere informatie

Subwerkgroep Methoden. Toelichting inhoud en voortgang tot nu toe

Subwerkgroep Methoden. Toelichting inhoud en voortgang tot nu toe SPIDER werkgroep Requirements Management Subwerkgroep Methoden Toelichting inhoud en voortgang tot nu toe donderdag 17 januari 2008 Frans van Veen Bert Dubbelman Robert van Lieshout Erwin Bolwidt Jan-Willem

Nadere informatie

CHECKLIST GESTRUCTUREERD TESTEN. Doel. Toepassingsgebied

CHECKLIST GESTRUCTUREERD TESTEN. Doel. Toepassingsgebied Gepubliceerd in: Checklist Informatiemangement, Aflevering 29, 1999 CHECKLIST GESTRUCTUREERD TESTEN Doel Het doel van deze checklist is het bepalen van de sterke en zwakke punten van de huidige werkwijze

Nadere informatie

TMapNext. Een introductie. Algemene informatie voor medewerkers van: SYSQA B.V.

TMapNext. Een introductie. Algemene informatie voor medewerkers van: SYSQA B.V. TMapNext Een introductie Algemene informatie voor medewerkers van: SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 15 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 1.2 VERSIEBEHEER...FOUT! BLADWIJZER

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

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

Testaanpak: leidraad voor het kiezen van een testtechniek

Testaanpak: leidraad voor het kiezen van een testtechniek Testaanpak: leidraad voor het kiezen van een testtechniek SYSQA B.V. Almere Datum : 18 november 2012 Status : Definitief Opgesteld door : Organisatie: SYSQA B.V. Pagina 2 van 9 Inhoudsopgave 1 Inleiding...

Nadere informatie

Sjabloon detailtestplan. <>

Sjabloon detailtestplan. <<Organisatie>> Sjabloon detailtestplan SYSQA B.V. Almere Datum : Status : Opgesteld door : Organisatie SYSQA B.V. Pagina 2 van 18 Inhoudsopgave 1 Managementsamenvatting...

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

Mastertestplan <> <>

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

Nadere informatie

TMap in essenties Michiel Vroon Leo van der Aalst Rob Baarda

TMap in essenties Michiel Vroon Leo van der Aalst Rob Baarda TMap in essenties Michiel Vroon Leo van der Aalst Rob Baarda 1 Waarom? Actualisering van de methode Praktijkgericht Testen integraal onderdeel van grotere geheel Diverse lijnorganisatievormen mogelijk

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

RAD en testen. Een aanpak. Algemene informatie voor medewerkers van SYSQA B.V.

RAD en testen. Een aanpak. Algemene informatie voor medewerkers van SYSQA B.V. RAD en testen Een aanpak Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA Pagina 1 van 23 Managementsamenvatting Rapid Application Development (RAD) is een systeem-ontwikkelingsmethode

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

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

TMap NEXT Test Engineer

TMap NEXT Test Engineer Preparation Guide TMap NEXT Test Engineer Editie juni 2013 Copyright 2013 EXIN All rights reserved. No part of this publication may be published, reproduced, copied or stored in a data processing system

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

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

voorbeeldexamen TMap TMap NEXT Foundation editie juli 2009 inhoud 2 inleiding 3 voorbeeldexamen 15 antwoordindicatie 33 evaluatie TMPF_2.

voorbeeldexamen TMap TMap NEXT Foundation editie juli 2009 inhoud 2 inleiding 3 voorbeeldexamen 15 antwoordindicatie 33 evaluatie TMPF_2. voorbeeldexamen TMPF_2.0 TMap TMap NEXT Foundation editie juli 2009 inhoud 2 inleiding 3 voorbeeldexamen 15 antwoordindicatie 33 evaluatie EXIN Hét exameninstituut voor ICT ers Janssoenborch, Hoog Catharijne

Nadere informatie

Doel. Context VSNU UFO/INDELINGSINSTRUMENT FUNCTIEFAMILIE ICT FUNCTIONEEL (INFORMATIE) BEHEERDER VERSIE 1 MEI 2012

Doel. Context VSNU UFO/INDELINGSINSTRUMENT FUNCTIEFAMILIE ICT FUNCTIONEEL (INFORMATIE) BEHEERDER VERSIE 1 MEI 2012 Functioneel (informatie) beheerder Doel Zorgdragen voor het inrichten, aanpassen, vernieuwen en onderhouden van de informatievoorziening (processen, procedures en/of systemen), passend binnen het informatiebeleid

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

Checklist basisontwerp SDM II

Checklist basisontwerp SDM II Organisatie SYSQA B.V. Pagina 1 van 5 Checklist basisontwerp SDM II Documentatie. Zijn de uitgangspunten voor het basisontwerp Is een plan van aanpak Zijn er wijzigingen op het Software Quality Assurance

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

Ontwikkelaar ICT. Context. Doel

Ontwikkelaar ICT. Context. Doel Ontwikkelaar ICT Doel Ontwikkelen en ontwerpen van ICT-producten, binnen overeen te komen dan wel in een projectplan vastgelegde afspraken ten aanzien van tijd, budget en kwaliteit, opdat overeenkomstig

Nadere informatie

Test Process Improvement Benchmark. SPIder Conferentie 23 september Wim van Uden

Test Process Improvement Benchmark. SPIder Conferentie 23 september Wim van Uden Test Process Improvement Benchmark SPIder Conferentie 23 september Wim van Uden Agenda Korte inleiding TPI -model TPI benchmark overall Vergelijking branches DO s& DON Ts Test Process Improvement Optimaliseren

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

Testen Foundation (TestF.NL)

Testen Foundation (TestF.NL) (TestF.NL) EXIN Hét exameninstituut voor ICT ers Janssoenborch - Hoog Catharijne Godebaldkwartier 365 3511 DT Utrecht Postbus 19147 3501 DC Utrecht Nederland T +31 30 234 48 11 F +31 30 231 59 86 E info@exin.nl

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

Evo Evolutionary Project Management. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

Evo Evolutionary Project Management. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. Evo Evolutionary Project Management Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 10 Inhoudsopgave 1. INLEIDING... 3 2. EVO... 4 3. FASERING...

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

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

De brug tussen PRINCE2 en TMap

De brug tussen PRINCE2 en TMap De brug tussen PRINCE2 en TMap Rob Baarda Testnet, Nieuwegein 9 juni 2004 Sogeti Nederland B.V. Pagina 1 Agenda PRINCE2 kort TMap in PRINCE2 Tips Globale typering PRINCE2 Onder besturing van Board Op basis

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

De beheerrisico s van architectuur

De beheerrisico s van architectuur De beheerrisico s van architectuur Een overzicht van de ArChimate Risico Extensie versie 0.2 Bert Dingemans Inleiding Het implementeren van een (enterprise) architectuur brengt altijd risico s met zich

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

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

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

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

TestFrame. Een introductie. Algemene informatie voor medewerkers van: SYSQA B.V.

TestFrame. Een introductie. Algemene informatie voor medewerkers van: SYSQA B.V. TestFrame Een introductie Algemene informatie voor medewerkers van: SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 13 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 2 TESTFRAME... 4 2.1 TESTFRAME ALS

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

Testplan

Testplan <NAAM INFORMATIESYSTEEM/PROJECT> Testplan é 2000 Pag. 1 Inhoud 1. DOCUMENTGEGEVENS... 4 1.1 WIJZIGINGSHISTORIE... 4 1.2 DISTRIBUTIE... 4 1.3 OPENSTAANDE PUNTEN... 4 1.4 ACCORDERING... 4 1.5 WIJZIGINGSPROCEDURE...

Nadere informatie

TMAP NEXT. TMap in essenties

TMAP NEXT. TMap in essenties TMAP NEXT TMap in essenties auteurs: Aalst, L. van der, Broekman, B., Koomen, T., Vroon, M. gebaseerd op de originele publicatie in : TMap NEXT, voor resultaatgericht testen, Aalst, L. van der, Broekman,

Nadere informatie

Aandachtspunten inzet testtool. Een aanpak. Algemene informatie voor medewerkers van SYSQA B.V.

Aandachtspunten inzet testtool. Een aanpak. Algemene informatie voor medewerkers van SYSQA B.V. Aandachtspunten inzet testtool Een aanpak Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA BV Pagina 2 van 12 INHOUDSOPGAVE 1. INLEIDING...3 1.1 DOEL EN AFBAKENING...3 1.2 CAPTURE

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

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

Procesmanagement. Waarom processen beschrijven. Algra Consult

Procesmanagement. Waarom processen beschrijven. Algra Consult Procesmanagement Waarom processen beschrijven Algra Consult Datum: 22 oktober 2009 Inhoudsopgave 1. INLEIDING... 3 2. WAAROM PROCESMANAGEMENT?... 3 3. WAAROM PROCESSEN BESCHRIJVEN?... 3 4. PROCESASPECTEN...

Nadere informatie

SVHT-IT. Mission statement

SVHT-IT. Mission statement SVHT-IT Mission statement Wij leveren oplossingen en diensten aan het MKB op het gebied van ICT, waarbij service, flexibiliteit en een persoonlijke relatie met de klant voorop staan SVHT-IT is een onderneming

Nadere informatie

De tester als bruggenbouwer

De tester als bruggenbouwer De tester als bruggenbouwer Tim Koomen Testnet voorjaarsevenement 9 juni 2004 Agenda Bruggen Enkele bruggen toegelicht De bruggenbouwer Trends Sogeti Nederland B.V. Pagina 1 Bruggen Systeem Beheer Stuur

Nadere informatie

De SYSQA dienst auditing. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

De SYSQA dienst auditing. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. De SYSQA dienst auditing Een introductie 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

Van Risicoanalyse tot Teststrategie

Van Risicoanalyse tot Teststrategie Van Risicoanalyse tot Teststrategie Cees Dulfer, Sr. Testconsultant Rabobank Nederland TestNet, 2 november 2005 1/28 TestNet, 2 november 2005 2/28 Agenda Historie Testproces en positionering Product Risico

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

auteur: Leo van der Aalst gebaseerd op de originele white paper 2010, Sogeti Nederland B.V. te Vianen.

auteur: Leo van der Aalst gebaseerd op de originele white paper 2010, Sogeti Nederland B.V. te Vianen. TESTEN IN ONDERHOUD auteur: Leo van der Aalst gebaseerd op de originele white paper 2010, Sogeti Nederland B.V. te Vianen. Niets uit deze uitgave mag verveelvoudigd en/of openbaar worden gemaakt (voor

Nadere informatie

Functieprofiel: Beheerder ICT Functiecode: 0403

Functieprofiel: Beheerder ICT Functiecode: 0403 Functieprofiel: Beheerder ICT Functiecode: 0403 Doel Zorgdragen voor het doen functioneren van ICT-producten en de ICTinfrastructuur en het instandhouden van de kwaliteit daarvan, passend binnen het beleid

Nadere informatie

Oplossingsvrij specificeren

Oplossingsvrij specificeren Oplossingsvrij specificeren ir. J.P. Eelants, projectmanager Infrabouwproces CROW Samenvatting De methodiek van oplossingsvrij specificeren richt zich niet alleen op het formuleren van functionele eisen.

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

Van requirements naar teststrategie

Van requirements naar teststrategie Van requirements naar teststrategie Testnet 7 januari 009 Ruud Harreman Appie Pries Waarom dit onderwerp? Leveranciersperspectief Bestaande testmethodes geven weinig aanknopingspunten hoe requirements

Nadere informatie

voorbeeldexamen I-Tracks voorbeeldexamen ISDDF Information Systems Design and Development Foundation uitgave april 2005

voorbeeldexamen I-Tracks voorbeeldexamen ISDDF Information Systems Design and Development Foundation uitgave april 2005 voorbeeldexamen Information Systems Design and Development Foundation I-Tracks voorbeeldexamen ISDDF Information Systems Design and Development Foundation uitgave april 2005 inhoud 3 inleiding 4 voorbeeldexamen

Nadere informatie

Erwin van den Hul De stappen van een complexe risico analyse matrix naar concreet testen

Erwin van den Hul De stappen van een complexe risico analyse matrix naar concreet testen Titel, samenvatting en biografie Erwin van den ul De stappen van een complexe risico analyse matrix naar concreet testen Samenvatting: Zie volgende pagina. Biografie: Erwin heeft ruim 10 jaar aansprekende

Nadere informatie

Kwaliteitskosten onderzoek. Aanpak. Algemene informatie voor medewerkers van: SYSQA B.V.

Kwaliteitskosten onderzoek. Aanpak. Algemene informatie voor medewerkers van: SYSQA B.V. Kwaliteitskosten onderzoek Aanpak 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 2 KWALITEITSKOSTEN...

Nadere informatie

Clean code improves test quality

Clean code improves test quality Clean code improves test quality Michel Kroon, Senior Consultant, SIG TestNet Voorjaarsevenement 30 juni 2008 Arent Janszoon Ernststraat 595-H NL-1082 LD Amsterdam info@sig.nl www.sig.nl De Software Improvement

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

Test rapportage Waarom eigenlijk?

Test rapportage Waarom eigenlijk? Testrapportage Boodschappers van de koning? Test rapportage Waarom eigenlijk? TestNet voorjaarsevenement 2015 Jurian van de Laar Jurian van de Laar @JurianvdL 30 april 2015 @JurianvdL Jurian van de Laar

Nadere informatie

Het BiSL-model. Een whitepaper van The Lifecycle Company

Het BiSL-model. Een whitepaper van The Lifecycle Company Het BiSL-model Een whitepaper van The Lifecycle Company Met dit whitepaper bieden we u een overzicht op hooflijnen van het BiSL-model. U vindt een overzicht van de processen en per proces een beknopte

Nadere informatie

Tweede Kamer der Staten-Generaal

Tweede Kamer der Staten-Generaal Tweede Kamer der Staten-Generaal 2 Vergaderjaar 1987-1988 Rijksbegroting voor het jaar 1988 20 200 Hoofdstuk X Ministerie van Defensie Nr. 34 BRIEF VAN DE STAATSSECRETARIS VAN DEFENSIE Aan de Voorzitter

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

Gestructureerd testen van embedded software

Gestructureerd testen van embedded software Gestructureerd testen van embedded software Erik van Veenendaal / Rob Hendriks (Improve Quality Services BV) De risicofactor bij embedded software is veelal erg groot. De economische, juridische of zelfs

Nadere informatie

SDM II - System Development Methodology II. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

SDM II - System Development Methodology II. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. SDM II - System Development Methodology II Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 12 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 1.2

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

Test Automatisering? Mislukken Slagen gegarandeerd! Ruud Teunissen - Polteq Test Services BV

Test Automatisering? Mislukken Slagen gegarandeerd! Ruud Teunissen - Polteq Test Services BV Test Automatisering? Mislukken Slagen gegarandeerd! Ruud Teunissen - Polteq Test Services BV Mislukken Slagen gegarandeerd 2 Mislukken Slagen gegarandeerd Management verwacht onmiddellijk R.O.I. Doel:

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

Hoe voert u een acceptatietest van maatwerk-software uit?

Hoe voert u een acceptatietest van maatwerk-software uit? Wat is een acceptatietest? Waarom is een acceptatietest voor u als opdrachtgever belangrijk? Wat moet u testen? Wanneer kunt u met de acceptatietest beginnen? Hoe voert u een acceptatietest uit? Wat doet

Nadere informatie

Najaarsspecial Oktober 2013

Najaarsspecial Oktober 2013 Najaarsspecial Oktober 2013 Pagina 12 TESTEN IS GEEN KUNSTJE ; ADAPTIVITEIT MAAKT VAN TESTEN IN JOUW CONTEXT EEN KUNDE! Door Leo van der Aalst en Rik Marselis leo.vander.aalst@sogeti.nl rik.marselis@sogeti.nl

Nadere informatie

BISL Business Information Services Library. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

BISL Business Information Services Library. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. BISL Business Information Services Library 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

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

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

Chris Schotanus TestGrip: de aanpak voor testbeleid en testorganisatie

Chris Schotanus TestGrip: de aanpak voor testbeleid en testorganisatie Titel, samenvatting en biografie Chris Schotanus Samenvatting: In ICT in het algemeen en Software Testing in het bijzonder nemen we een aantal belangrijke zaken waar zoals Business eisen als een hoge quality-to-market

Nadere informatie

Praktijkgerichte aanpak voor End to End (E2E) testen

Praktijkgerichte aanpak voor End to End (E2E) testen Praktijkgerichte aanpak voor End to End (E2E) testen Gerard Numan gerard.numan@polteq.com Polteq 2014 E2E wil zeggen: End to End, van het ene uiterste einde naar het andere einde. E2E-processen lopen over

Nadere informatie

Eibert Dijkgraaf Kijk verder dan je test neus lang is: Life Cycle Testing Scan Voorjaarsevent Testnet: 30 juni 2008

Eibert Dijkgraaf Kijk verder dan je test neus lang is: Life Cycle Testing Scan Voorjaarsevent Testnet: 30 juni 2008 Titel, samenvatting en biografie Eibert Dijkgraaf Kijk verder dan je test neus lang is: Life Cycle Testing Scan Voorjaarsevent Testnet: 30 juni 2008 Samenvatting: Eibert Dijkgraaf (testconsultant Test

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

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

kwaliteitsmeterplus 4

kwaliteitsmeterplus 4 kwaliteitsmeterplus 4 Testen voor de toekomst Eenvoudig en intuïtief Werkproces georiënteerd Scheiding bevindingen en issues Hertest methode Schermafdruk en -opnames SaaS Open platform kwaliteitsmeterplus

Nadere informatie

Bedrijfsvoering en informatievoorziening; een geïntegreerde aanpak

Bedrijfsvoering en informatievoorziening; een geïntegreerde aanpak Bedrijfsvoering en informatievoorziening; een geïntegreerde aanpak door J.P. van Tongeren, van Tongeren & Trimp organisatie en informatiearchitecten te Den Haag Vóóraf Door de redactie is ons gevraagd

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

Medewerker administratieve processen en systemen

Medewerker administratieve processen en systemen processen en systemen Doel Voorbereiden, analyseren, ontwerpen, ontwikkelen, beheren en evalueren van procedures en inrichting van het administratieve proces en interne controles, rekening houdend met

Nadere informatie