2 TESTEN: HET RISK SPEL

Maat: px
Weergave met pagina beginnen:

Download "2 TESTEN: HET RISK SPEL"

Transcriptie

1 2 TESTEN: HET RISK SPEL 2.1 De relatie tussen testen en risico Eén van de moeilijkste onderdelen van testen is het vinden van een goede balans tussen de hoeveelheid tijd en geld die aan testen besteed wordt, ten opzichte van hoe en waar die testinspanning besteed moet worden en wat het testen moet opleveren. Dit speelt zowel bij het begin van testen (bij het opstellen van het testplan) als gedurende het testen en tegen het einde (wanneer moeten we stoppen). De moeilijkheid zit er met name in dat niet de testmanager maar de opdrachtgever van het testen deze beslissing moet nemen. De testmanager moet de opdrachtgever voorzien van voldoende informatie zodat deze een goed gefundeerde beslissing kan nemen. Bij een gestructureerd testproces zijn tijd en geld heel goed zichtbaar voor de opdrachtgever. Het is veel moeilijker om inzicht te geven in de andere kant van de balans, het te behalen resultaat en de af te dekken risico s. Hoewel de meeste opdrachtgevers tegenwoordig niet meer de illusie hebben dat ze foutloze software opgeleverd krijgen, blijft testen voor veel, met name niet-it, opdrachtgevers nog steeds een activiteit die eigenlijk zo kort mogelijk moet duren, maar waarbij er na afloop een vrijwel foutloos systeem moet overblijven. De beste manier voor het maken van de afweging is om de opdrachtgever de keuze voor te leggen tussen tijd en geld enerzijds, en met testen af te dekken productrisico s anderzijds. Het is daarmee een algemeen geaccepteerd principe van testen geworden dat dit gebaseerd moet zijn op de risico s van de software voor de organisatie. Deze risico s betreffen nadrukkelijk de productrisico s, dus de risico s ten aanzien van de kwaliteit van het product. Daarnaast zijn er ook andere categorieën risico s zoals project- of procesrisico s zoals mogelijke uitloop in tijd of geld of onvoldoende betrokkenheid van gebruikers bij het systeemontwerp. Deze categorieën van risico s worden niet rechtstreeks in overweging genomen bij de verdeling van de testinspanning over de te testen onderdelen van de software, er wordt alleen gekeken naar de gevolgen voor de productrisico s. 2.2 Aanpak voor teststrategie In Nederland zijn in de loop der jaren diverse aanpakken ontwikkeld om tot een zo goed mogelijke keuze te komen. Dit proces van gefundeerd kiezen wordt de teststrategie genoemd. Al in de eerste druk van TMap [Pol e.a., 1995] werd een techniek voor strategiebepaling beschreven. Deze aanpak/techniek is een aantal malen herzien met als laatste versie business driven testmanagement [Koomen e.a., 2007]. Ook zijn sinds 1995 andere aanpakken ontwikkeld, zoals Risk and Requirements Based Testing [van de Burgt e.a., 2003], PRISMA [van Veenendaal, 2006] en SmarTEST [Bouman, 2004]. Hoewel ook in het buitenland het principe van risico-gebaseerd testen wordt onderkend (zoals bijvoorbeeld in de ISTQB/ISEB certificeringsprogramma s voor testers), zijn concrete aanpakken/technieken minder snel aan te wijzen. Een bekend voorbeeld is het vrij formele Failure mode and effects analysis (FMEA). Deze methode Hoofdstuk 1 van TestNetWerkT 1

2 analyseert mogelijke faalwijzen en hun effecten om tijdig maatregelen (waaronder testen) te kunnen nemen die dit mogelijk falen voorkomen. FMEA kan goed gebruikt worden om de zwakke plekken in de software bloot te leggen waar extra grondig getest moet worden. Op hoofdlijnen doorlopen de verschillende aanpakken de volgende stappen om een teststrategie op te stellen: Figuur 2.1. Stappen opstellen teststrategie Betrekken deelnemers De testmanager wil nadrukkelijk de opdrachtgever (of vertegenwoordigers hiervan) betrekken bij de keuze van wat getest moet gaan worden en hoe zwaar. Omdat risico s de basis vormen voor deze keuze, moeten partijen betrokken worden die hier iets over kunnen zeggen. Omdat een risico gedefinieerd kan worden als kans maal schade, zijn deelnemers nodig die de kans en/of de schade kunnen inschatten. Vaak is hier een splitsing te zien tussen vertegenwoordigers van de opdrachtgever/business (bijvoorbeeld gebruikers, systeembeheerders, helpdesk) die schade kunnen inschatten en vertegenwoordigers van de IT (ontwerper, ontwikkelaar, QA, projectmanager) die de kans dat het systeem faalt kunnen inschatten Productrisicoanalyse Met deze deelnemers worden in een productrisicoanalyse (PRA) de risico s bepaald. Een PRA kan plaatsvinden in (één of meer) sessies, workshops of interviews. Het doel van de PRA is om het systeem op te delen in kleinere, testbare brokken met een gelijksoortige risiconiveau. Deze testdelen (onder namen als deelobjecten of clusters) betreffen meestal een combinatie van een kwaliteitsattribuut (functionaliteit, Hoofdstuk 1 van TestNetWerkT 2

3 performance, beveiliging) en een onderdeel van het systeem (deelsystemen, online/batch, front-end/back-end, schermen, ). Hierbij moet rekening gehouden worden met de scope van de PRA. Deze kan voor het totale testproces zijn of voor een individuele testsoort zoals systeem- of acceptatietest. In dat laatste geval zijn vaak vanuit het mastertestplan al bepaalde keuzes gemaakt welke kwaliteitsattributen in de testsoort getest moeten worden. Op welke manier de risico-labels op de testdelen worden aangebracht, is eigenlijk niet zo spannend meer. In de praktijk zien we classificaties met Hoog/Midden/Laag, A/B/C, met formules en cijfers, met percentages, MoSCoW, enzovoort. Belangrijke bijkomende voordelen van de PRA zijn dat de deelnemers tot een gezamenlijk beeld van de productrisico s komen waardoor latere bijsturing wordt vergemakkelijkt én dat het praten over productrisico s vaak ook leidt tot het constateren van omissies in de requirements en het ontwerp. Als bijvoorbeeld performance als groot risico wordt gezien, maar/en er geen eisen voor gedefinieerd zijn, is dit een belangrijk signaal voor het project Keuze licht/gemiddeld/zwaar testen Vervolgens wordt per testdeel bepaald hoe zwaar deze getest moet worden. Het ligt hierbij voor de hand om risicovolle delen grondiger te testen dan minder risicovolle delen. Op het niveau van het mastertestplan wordt daarnaast een keuze gemaakt (indien mogelijk) welke testsoorten ingericht gaan worden en welk testdeel in welke testsoort getest moet worden. Net als bij de PRA is het toekennen van testzwaarte een gemeenschappelijke keuze van de deelnemers. De opdrachtgever heeft hierbij vanzelfsprekend de belangrijkste stem. En eveneens als bij de PRA is het minder spannend op welke manier de zwaarte van testen wordt aangegeven: zo worden er bolletjes, plusjes of percentages gebruikt. Het is weliswaar mogelijk, maar normaal gesproken af te raden, om hier al een grotere mate van detail aan te brengen, tot de keuze voor toe te passen testontwerptechnieken toe. In de volgende stap worden de tests begroot en gepland en dit betekent regelmatig een herziening van de in deze stap gemaakte keuzes. Te vroeg teveel detail aanbrengen is dan zonde van de inspanning. Bij kleine projecten kan de PRA gecombineerd worden met de keuze voor licht/gemiddeld/zwaar testen, maar in de praktijk vinden beide activiteiten gescheiden plaats Begroten / plannen Nadat de deelnemers voorgaande activiteiten hebben doorlopen (en enthousiast voor allerlei grondige tests hebben gekozen), moet nu de vraag beantwoord worden of de gekozen testaanpak acceptabel is in termen van tijd en geld. Ook in het geval dat de hoeveelheid tijd en geld opgelegd wordt, moet deze schatting worden gemaakt, zodat discrepanties tussen gewenste testdekking en beschikbare middelen en tijd zichtbaar worden. Het begroten en plannen is een vrij specialistische taak die normaal gesproken door de testmanager wordt uitgevoerd. Voor het begroten van tests is weliswaar een scala aan technieken beschikbaar, maar het blijft altijd een moeilijk onderdeel waarbij de Hoofdstuk 1 van TestNetWerkT 3

4 uitkomsten van de verschillende technieken (én de uiteindelijk bestede tijd) enorm kunnen verschillen. Bij het plannen van de tests geeft de testmanager prioriteit aan de tests die de hoogste risico s afdekken. De testmanager koppelt vervolgens zijn of haar inschatting van tijd en kosten terug aan de opdrachtgever voor akkoord. In de praktijk blijkt dit nogal eens tegen te vallen. Er moet dan terug worden gegaan door de keuze voor licht/zwaar testen opnieuw te bekijken. Hierbij zijn testmanager en opdrachtgever betrokken, naar keuze aangevuld met één of meer andere deelnemers. Bij het kiezen voor sneller en goedkoper maken de opdrachtgever en andere deelnemers een bewuste keuze om productrisico s minder af te dekken met testen dan optimaal zou zijn en dus meer risico te lopen bij het in productie nemen van de software. Niettemin kan deze beslissing vanuit andere argumenten zoals bijvoorbeeld het moeten halen van de deadline door wettelijke voorschriften, verplichtingen of concurrentievoordeel wel degelijk een goede en rationele beslissing zijn. En in ieder geval ligt de beslissing nu bij de juiste persoon en niet bij de testmanager Keuze technieken Wanneer de opdrachtgever het eens is met de gekozen testaanpak, moeten de keuzes voor licht en zwaar testen nader gedetailleerd worden. Hoe test je namelijk iets grondig en hoe test je het licht? Vergelijk daarvoor testen met een zeef waar de software doorheen wordt gegooid en waar bepaalde typen bevindingen achterblijven. Een grondige test bestaat uit óf een fijnmazige zeef of uit meerdere typen zeven onder elkaar. Het is daarom ook niet voldoende om enkel verhoudingsgewijs extra uren toe te kennen aan een zwaar te testen onderdeel, want dat biedt te weinig zekerheid dat de extra uren ook resulteren in een groter kwaliteitsinzicht (of duidelijker: meer bevindingen). Om in de analogie met de zeef te blijven: de software wordt dan enkel meerdere keren door dezelfde zeef gegooid, met andere woorden de extra bedachte tests gaan geen nieuwe bevindingen opleveren. Om de best passende zeef te verkrijgen, heeft de tester een scala aan testontwerptechnieken tot beschikking, waarmee diverse aspecten op lichtere of grondigere manier getest kunnen worden. Bij deze keuze hoeft de opdrachtgever niet meer te worden betrokken, dit hoort tot de specifieke expertise van de testmanager. Het moment waarop de technieken worden toegewezen varieert. Bij voorkeur gebeurt dit al in het testplan, maar soms is het pas later in het traject zinvol, wanneer er meer duidelijkheid ontstaat over (de vorm van) de testbasis Tijdens het testen Hoewel het idee kan ontstaan dat na uitvoering van bovenstaande activiteiten het testkunstje alleen nog uitgevoerd hoeft te worden, is dat natuurlijk verre van waar. Hoe goed de initiële inschatting van risico s ook is gedaan, altijd blijken verderop in het traject bepaalde risico s groter of juist kleiner te zijn dan voorzien. Daarnaast kunnen onder tijdsdruk of andere omstandigheden sommige geplande tests niet worden uitgevoerd. Regelmatig moet de testmanager dan ook een inschatting maken of de testdekking nog wel in overeenstemming is met de (herziene) productrisico s. Feitelijk doorloopt hij/zij daarvoor een soort mini-strategie. De testmanager heeft in het testplan vaak marges in tijd, geld of testdekking afgesproken met de opdrachtgever waarbinnen geen toestemming voor wijzigingen gevraagd hoeft te worden. Buiten deze marges moet de mogelijke bijstelling van de strategie natuurlijk wel overlegd worden met de opdrachtgever en andere betrokken partijen. Hoofdstuk 1 van TestNetWerkT 4

5 2.3 Belangrijke uitdagingen Hoewel bovenstaande kan suggereren dat het opstellen van de teststrategie simpel is, laat de praktijk zien dat het opstellen van een goede strategie wel degelijk moeilijk is. Onderstaand wordt een aantal veelvoorkomende uitdagingen met mogelijke oplossingen beschreven: Gebruikers en opdrachtgever willen niet praten over testinvulling In sommige organisaties wordt het testen gezien als een pure en specialistische ITactiviteit. De gebruikers en opdrachtgever vanuit de business willen daarom niet meedoen aan de PRA en strategiebepaling. Met argumenten als wij snappen dit toch niet en we hebben het volste vertrouwen in jullie als testers wordt betrokkenheid ontweken. De testmanager kan met de volgende argumenten of maatregelen proberen deze partijen toch te betrekken: Testen is een risico-gebaseerde activiteit, waarbij een risico = faalkans x schade. De schade-component kan door niemand beter ingeschat worden dan door de gebruikers/business; Vaak wil opdrachtgever wél invloed uitoefenen op de beschikbare hoeveelheid tijd en geld voor testen. Maar hoe kun je daar een oordeel over geven als je niet meeneemt wat testen gaat opleveren/welke risico s het gaat afdekken? Geef een awareness-training of presentatie over testen Neem voor de strategiebepaling als vertrekpunt het begripskader van de gebruikers/business, bijvoorbeeld de bedrijfsprocessen of (business of user) requirements. Communicatiekloof In een breed uitgevoerde PRA zijn deelnemers van uiteenlopende aard vertegenwoordigd: gebruikers, ontwikkelaars, systeembeheerders, businessmanager, testmanager, enzovoort. De moeilijkheid van een goede PRA zit in de communicatie met en tussen de verschillende deelnemers. Waar het praten over kwaliteitsattributen en deelsystemen voor deelnemers met een IT-achtergrond goed te begrijpen is, is dit voor andere deelnemers (zoals gebruikers en opdrachtgever) vaak een stuk moeilijker. Als deze mensen bij elkaar komen in één sessie, kunnen gemakkelijk Babylonische spraakverwarringen en, erger, tegenstellingen en conflicten ontstaan. Om deze communicatiekloof te overbruggen, hanteren de aanpakken vaak een tussenstap. Door bijvoorbeeld te praten vanuit voorbeelden van risico s, requirements of bedrijfsprocessen wordt geprobeerd de PRA inzichtelijk te maken voor de niet-it deelnemers. Niettemin komt hier veel aan op de sociale vaardigheden van de testmanager. Wanneer het risico op communicatieproblemen te groot is, kan de testmanager er voor kiezen om eerst een inleidende test- en risicoworkshop te geven aan de deelnemers die onervaren/onbekend zijn met testen. Een andere mogelijkheid is dat de testmanager de PRA niet in één sessie doet maar de deelnemers over meerdere sessies verdeelt en/of interviews met bepaalde deelnemers houdt en dit zelf tot een strategie-eindresultaat smeedt dat aan de deelnemers voorgelegd wordt. Onvoldoende informatie beschikbaar Het komt vaak voor dat een PRA en strategie worden uitgevoerd terwijl er nog maar weinig informatie (zoals een functioneel ontwerp) over het systeem beschikbaar is. De testmanager moet voorafgaand aan de PRA zoveel mogelijk de informatie verzamelen die wel voorhanden is. Voorbeelden hiervan zijn requirements, use cases, user stories, prototypes, het oude systeem of vergelijkbare systemen en architectuurdocumentatie. Daarnaast kan aanvullende informatie geleverd worden door een aantal mensen (ontwerper, architect, superuser) te interviewen. De testmanager moet dan zorgen Hoofdstuk 1 van TestNetWerkT 5

6 dat alle deelnemers een zo goed mogelijk beeld van het te testen systeem krijgen, bijvoorbeeld door een uitlegsessie te organiseren, voordat de PRA start. Iteratief ontwikkelen De PRA en teststrategie worden normaal gesproken uitgevoerd met het beeld van het uiteindelijk op te leveren systeem voor ogen. In steeds meer organisaties wordt op iteratieve manier ontwikkeld, waarbij in een aantal incrementen het uiteindelijke systeem wordt opgeleverd. Elk increment moet getest worden. Het heeft echter weinig zin om de eerste increment al te gaan testen op bijvoorbeeld security als dit pas vanaf de derde increment ingebouwd gaat worden. De testmanager kan hiermee bijvoorbeeld omgaan door de PRA eenmalig voor het totale systeem uit te voeren, maar de strategie (keuze voor licht/zwaar testen) per increment. Andere varianten, zoals een PRA en strategie op mastertestplan-niveau en daarna een PRA en strategie per detailtestplan/increment zijn ook mogelijk. De omvang en doorlooptijd van de incrementen heeft grote invloed op deze keuze. Meerdere (test)partijen Voor een optimale strategie moeten alle testsoorten (inclusief toetssoorten) beschouwd worden. Met de huidige trend naar outsourcing van IT-activiteiten en het betrekken van componenten/services van derden vallen deze testsoorten vaak niet onder de verantwoordelijkheid van de eigen organisatie. Dit maakt afstemming moeilijker. Zo zit een testsoort van de outsourcingspartner er vaak niet op te wachten om bepaalde tests (extra) uit te voeren omdat dit vanuit het totaal bezien efficiënter is. De beste manier om toch een optimale strategie mogelijk te maken is daarom het (vooraf) maken van afspraken over de testaanpak met de andere partij. Dit kan als onderdeel van het contract of de Service Level Agreement (SLA). De termen generieke testafspraken of generiek mastertestplan worden hiervoor gebruikt. Wil of kan de andere partij geen inspraak op zijn testproces toestaan, dan moet de testmanager tenminste inzicht proberen te verkrijgen in de teststrategie van deze partij, zodat hier in de overige testsoorten rekening mee gehouden kan worden. Keuze strategie krijgt geen invulling De praktijk laat nog wel eens het volgende zien: er wordt met veel enthousiasme een gedetailleerde teststrategie opgesteld, met keurig allerlei keuzes welke onderdelen en/of aspecten licht of juist zwaar getest moet worden. Vervolgens gaan de testers aan de slag met het specificeren van de tests. Als er al een testontwerptechniek gebruikt wordt, dan is dit voor alle tests dezelfde. Nog vaker blijkt helemaal geen techniek gebruikt te worden en beslist de individuele tester op basis van eigen inzicht hoeveel testgevallen hij/zij voor een bepaald te testen onderdeel maakt, hoogstens gestuurd door de toegewezen hoeveelheid tijd. De koppeling met de opgestelde teststrategie is daarmee zoek. De teststrategie biedt zo slechts een schijnzekerheid aan de opdrachtgever met als grootste risico dat in productie uiteindelijk de verkeerde onderdelen grondig of juist licht getest blijken te zijn en een bovenmatig aantal productieverstoringen optreedt. Relatie projectrisicoanalyse Bij veel projecten wordt in een vroeg stadium een projectrisicoanalyse uitgevoerd. Hierin worden de belangrijke projectrisico s geanalyseerd zodat nog tijdig maatregelen genomen kunnen worden. Bij het aankondigen van de PRA krijgt de testmanager dan de terechte vraag of deze wel zinvol is en niet erg veel overlap heeft met deze projectrisicoanalyse. De belangrijkste argumenten die de testmanager kan gebruiken voor de PRA zijn: een projectrisicoanalyse richt zich op de proces- en projectrisico s, de PRA vanuit testen op de productrisico s. De projectrisicoanalyse heeft op het vlak van productrisico s niet de mate van detail die nodig is voor de PRA Hoofdstuk 1 van TestNetWerkT 6

7 een projectrisicoanalyse vindt meestal duidelijk vroeger in het project plaats dan de PRA. Voortschrijdend inzicht én vanuit de projectrisicoanalyse geïmplementeerde maatregelen betekenen dat de productrisico s in de PRA gewoonlijk nauwkeuriger en anders worden ingeschat. Hertests/onderhoud Er zijn veel meer systemen in onderhoud dan dat nieuwbouw plaatsvindt. Bij onderhoud kan niet de oorspronkelijke nieuwbouw-strategie van het systeem klakkeloos worden overgenomen. Dit heeft alles te maken met het gewijzigde risicoprofiel. De schade-component verandert als regel weinig, maar de faalkanscomponent is sterk geminimaliseerd door al het testen dat bij de nieuwbouw plaats heeft gevonden. Herhalen van alle nieuwbouwtests heeft dan ook alleen zin als dit tegen heel geringe inspanning (bijvoorbeeld doordat de tests geautomatiseerd zijn) kan plaatsvinden. Het is daarom logischer om de PRA en teststrategie op te stellen op basis van de wijzigingen én het systeem als geheel. Per wijziging wordt het risico (met name de faalkans-factor) ingeschat en wordt een keuze voor licht, middel of zwaar testen gemaakt. Daarnaast wordt het risico op regressie voor het systeem als geheel ingeschat en wordt hiervoor een (herbruikbare) regressietest ingepland. Ontwikkeltests niet betrokken Hoewel we bij het opstellen van de teststrategie voor het optimale effect zoveel mogelijk alle testsoorten willen betrekken, blijkt het erg moeilijk om de ontwikkeltestsoorten zoals unit- en unitintegratietest te betrekken. Er is in de praktijk nog een grote barrière tussen ontwikkelaars en (professionele) testers. Het idee is dat ontwikkelaars niet voorgeschreven willen krijgen hoe en met welke diepgang ze moeten testen. Veel testmanagers bemoeien zich dan ook niet met de ontwikkeltests. Toch hebben de testmanagers die dit wél gedaan hebben, vaak zeer aansprekende resultaten geboekt. Tenslotte zijn de ontwikkeltests de vroegste testsoorten en zoals bekend zijn vroege fouten meestal goedkope fouten. Commitment van de leidinggevende over de ontwikkelaars is een noodzakelijke randvoorwaarde, evenals de bereidheid van de ontwikkelaars om hun manier van testen onder de loep te nemen. 2.4 Toekomst Uit voorgaande is het belang duidelijk geworden van een goede, op risico s gebaseerde teststrategie voor de effectiviteit van het testproces. Hoewel het vanzelfsprekend klinkt ( Je kunt niet alles testen, dus je moet slim kiezen wat je gaat testen en hoe zwaar ), is het in de praktijk moeilijk, met grote uitdagingen op het vlak van communicatie, samenwerking en testinzicht. Het is niet nieuw in testen, wel is in de afgelopen jaren het risico-denken veel explicieter geworden. De vraag is daarom of de aanpak voor een teststrategie in de toekomst nog flink zal wijzigen. Ik denk niet dat het zal wijzigen in de zin dat het altijd een lastig traject zal blijven dat vaak onvoldoende uitgevoerd wordt en meestal van geval tot geval een eigen situationele invulling vraagt. Ik denk wel dat een aantal IT-ontwikkelingen invloed gaan hebben op de aanpak, zoals het gebruik van componenten of services van 3 e partijen, service georiënteerde architecturen en outsourcing. In al deze ontwikkelingen wordt hoge kwaliteit van de geleverde of ontwikkelde bouwstenen (componenten, services) steeds belangrijker. Het integreren van dergelijke bouwstenen tot een werkend systeem is namelijk dermate complex geworden dat onvoldoende kwaliteit van een bouwsteen het hele integratieproces frustreert, waarbij de complexiteit het erg moeilijk zal maken om aan te geven welke bouwsteen de problemen veroorzaakt. In toenemende mate zullen opdrachtgevers om een steeds formeler bewijs van kwaliteit vragen, tot certificatie van bouwstenen aan toe. Het leveren van een Hoofdstuk 1 van TestNetWerkT 7

8 kwaliteitsbewijs kan niet zonder een transparante teststrategie te overleggen. De uitdaging gaat eruit bestaan om de aanpak voor de teststrategie aan te laten sluiten op dit gevraagde en formele kwaliteitsbewijs. Referenties Pol, M, R. Teunissen, E. van Veenendaal (1995) Testen volgens TMap, Uitgeverij Tutein Nolthenius, ISBN10: ISBN13: (2 e druk) Bouman, E. (2004) Effectievere informatiesystemen door slim testen, Sdu Uitgevers, ISBN10: ISBN13: Veenendaal, E. van (2006) Practical Risk-Based Testing PRoduct RIsk MAnagement: the PRISMA method, white-paper Burgt, B. van de & I. Pinkster (2003) Succesvol testmanagement in de praktijk, Sdu Uitgevers, ISBN10: ISBN13: Koomen, T., L. van der Aalst, B. Broekman, M. Vroon (2006) TMap Next voor resultaatgericht testen, Uitgeverij Tutein Nolthenius, ISBN: ISBN13: Over de auteur Tim Koomen is sinds mei 2007 zelfstandig testconsultant en manager. Van 1988 tot en met 2007 is Sogeti zijn werkgever geweest, waar hij zich sinds 1992 met testen heeft beziggehouden. Hij is co-auteur van het boek TMap Next, Test Process Improvement (TPI ) en co-redacteur van TMap Test Topics. De boeken zijn in verschillende talen (Nederlands, Engels, Duits, Japans, Chinees) uitgegeven. Met grote regelmaat worden daarnaast zijn artikelen gepubliceerd en geeft hij trainingen en presentaties in binnen- en buitenland over een scala aan testonderwerpen (o.a. pakketimplementaties, iteratief ontwikkelen (met componenten), SOA, RUP, ontwikkeltesten, business intelligence, TPI en TMap). In 2003 ontving Tim de European Testing Excellence Award. Deze prijs wordt sinds 1998 jaarlijks uitgereikt aan een persoon die een significante bijdrage heeft geleverd aan het vak van software testen in Europa. Hoofdstuk 1 van TestNetWerkT 8

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

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

Risk Based Testing. TestNet Voorjaarsbijeenkomst. Johan Vink. A reality check

Risk Based Testing. TestNet Voorjaarsbijeenkomst. Johan Vink. A reality check Risk Based Testing A reality check TestNet Voorjaarsbijeenkomst Johan Vink Even voorstellen - Johan Vink - 42 jaar testervaring - 15 jaar betaald - Test competence leader Risk Based Testing, a reality

Nadere informatie

Tim Koomen Op weg naar een hoger niveau testorganisatie Najaarsevent TestNet: 22 september 2009

Tim Koomen Op weg naar een hoger niveau testorganisatie Najaarsevent TestNet: 22 september 2009 Titel, samenvatting en biografie Samenvatting Tim Koomen Najaarsevent TestNet: 22 september 2009 Veel organisaties beginnen met het verbeteren van testen door één of andere vorm van testorganisatie (test

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

TMap NEXT Test Manager

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

Nadere informatie

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

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

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

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

Een duivelse samenwerking (Projectmanagement vs. Testmanagement) Albrie Beemer & Erik Bits 18 april 2012

Een duivelse samenwerking (Projectmanagement vs. Testmanagement) Albrie Beemer & Erik Bits 18 april 2012 Een duivelse samenwerking (Projectmanagement vs. Testmanagement) Albrie Beemer & Erik Bits 18 april 2012 Het duivelsvierkant Agenda Introductie 19.00u 19.10u Klassiek Projectmanagement: Prince 2 Testmanagement:

Nadere informatie

Mastertestplan <<Naam project>> <<Organisatie>>

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

Nadere informatie

Product Risico Analyse

Product Risico Analyse Product Risico Analyse Jurian van de Laar TestNet Avond 9 oktober 2013 www.improveqs.nl (info@improveqs.nl) Versie 2.0 1 Herkenbaar? In ons testproces wordt product risico analyse toegepast Wij gebruiken

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

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

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

Cecile Davis & Leo van der Aalst cecile.davis@sogeti.nl & leo.vander.aalst@sogeti.nl

Cecile Davis & Leo van der Aalst cecile.davis@sogeti.nl & leo.vander.aalst@sogeti.nl (fr)agile Balance Cecile Davis & Leo van der Aalst cecile.davis@sogeti.nl & leo.vander.aalst@sogeti.nl Voorstelronde Naam Organisatie Ervaring met testen in agile omgevingen Verwachting 2 Agenda 09:30

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

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

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

TMap Process Template voor Visual Studio Het

TMap Process Template voor Visual Studio Het Testen TMap Process Template voor Visual Studio 2010 TESTAANPAK VOOR EFFICIËNT GEBRUIK VS2010 ALM TOOLS Rob Kuijt en Clemens Reijnen Begin jaren 90 brak het besef door dat testen niet iets is dat een ontwikkelaar

Nadere informatie

Werkgroep ISO29119. TestNet thema-avond 9 oktober 2014

Werkgroep ISO29119. TestNet thema-avond 9 oktober 2014 Werkgroep ISO29119 TestNet thema-avond 9 oktober 2014 Is dit n gezonde maaltijd? Ja toch!! Om jezelf een oordeel te kunnen vormen heb je informatie nodig!! Vandaag brengen we kennis en informatie bij elkaar

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

TMAP NEXT. BDTM voor opdrachtgevers

TMAP NEXT. BDTM voor opdrachtgevers TMAP NEXT BDTM voor opdrachtgevers auteurs: Aalst, L. van der, Baarda, R., Roodenrijs, E., Vink, J., Visser, B. gebaseerd op de originele publicatie in: TMap NEXT, Business Driven Test Management, Aalst,

Nadere informatie

Test Management Assessment

Test Management Assessment Test Management Assessment Bart Knaack 1 Spreker wie ben ik? Bart Knaack Testmanager LogicaCMG Medewerker Test Research Centre Huidige opdracht: Legacy transformation testing bij Nationale Nederlanden.

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

Samenvatting TMap Next Voor resultaatgericht testen

Samenvatting TMap Next Voor resultaatgericht testen SAMENVATTING Samenvatting TMap Next Voor resultaatgericht testen Versie 1.0 ML september & oktober 2010 Inhoudsopgave ALGEMEEN... 4 1. INLEIDING... 4 2. KADER EN BELANG VAN TESTEN... 5 2.1. PLAATS VAN

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

van TESTmanagement naar testmanagement

van TESTmanagement naar testmanagement Ontwikkelingen in testmanagement: van TESTmanagement naar testmanagement Presenta9e TestNet Voorjaarsevenement 10 mei 2011 Peter Logman & Arno Dijkmans Agenda Wie zijn wij? TESTmanagement Sleutelmomenten

Nadere informatie

Testen en QA bij pakketimplementaties

Testen en QA bij pakketimplementaties Testen en QA bij pakketimplementaties Eric Begeer Sogeti Nederland B.V. Testnet 5 november 2003 Agenda Waarom maken organisaties gebruik van pakketten? Welke risico s lopen ze hierbij? Welke maatregelen

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

Business Intelligence Teststrategie

Business Intelligence Teststrategie Business Intelligence Teststrategie een teststrategie volgens TMap NEXT Schiphol, 30 september 2009 Bart Vrenegoor, Sogeti Nederland B.V. Programma Waarom een teststrategie? Opstellen BI-Teststrategie

Nadere informatie

Titel, samenvatting en biografie

Titel, samenvatting en biografie Titel, samenvatting en biografie Nathalie Rooseboom de Vries van Delft Teststrategie prioritering gedaan door middel van mens georiënteerde analyse Najaarsevent Testnet: 16 september 2008 Samenvatting:

Nadere informatie

Testen+ Testaanpak Sogeti testteam bij de Friesland Bank. Versie: 13 februari 2012 André Louwes / Arjan van der Haar

Testen+ Testaanpak Sogeti testteam bij de Friesland Bank. Versie: 13 februari 2012 André Louwes / Arjan van der Haar Testen+ Testaanpak Sogeti testteam bij de Friesland Bank Versie: 13 februari 2012 André Louwes / Arjan van der Haar Testen+ Voorstellen André Louwes Senior Testmanager (Sogeti) Manager testline (Friesland

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

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

Productrisicoanalyse in de praktijk

Productrisicoanalyse in de praktijk Productrisicoanalyse in de praktijk Kees Blokland Polteq IT Services BV Agenda Intro Voorbereiding Aandachtspunten voorbereiding Bijeenkomst risicoanalyse Aandachtspunten bijeenkomst risicoanalyse Bepaling

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

PRISMA is een geregistreerde merknaam van Improve Quality Services BV

PRISMA is een geregistreerde merknaam van Improve Quality Services BV CHECKLIST RISK-BASED TESTEN Doel Het doel van deze checklist is het bepalen van een gedifferentieerde testaanpak op basis van technische en bedrijfsmatige productrisico s. Met behulp van de checklist wordt

Nadere informatie

Op weg naar een hoger niveau testorganisatie. Tim Koomen TestNet najaarsevenement 2009

Op weg naar een hoger niveau testorganisatie. Tim Koomen TestNet najaarsevenement 2009 Op weg naar een hoger niveau testorganisatie Tim Koomen TestNet najaarsevenement 2009 1 Start Test resource pool Test factory Basic Change Method Seite 2 Einde Start Test resource pool Test factory Basic

Nadere informatie

1,3 miljoen regels mission critical code omzetten naar C++, hoe test je dat?

1,3 miljoen regels mission critical code omzetten naar C++, hoe test je dat? 1,3 miljoen regels mission critical code omzetten naar C++, hoe test je dat? XXXXXX Najaarsevenement 2016 Jaap Kuilman 11 oktober 2016 Introductie Jaap Kuilman Testconsultant bij InTraffic Ervaring in

Nadere informatie

Algemene kennis op het gebied van systeemontwikkeling en een half jaar tot een jaar werkervaring in het vakgebied testen. Niet van toepassing

Algemene kennis op het gebied van systeemontwikkeling en een half jaar tot een jaar werkervaring in het vakgebied testen. Niet van toepassing Exam requirements TMap NEXT Foundation (TMPF.NL) Publicatiedatum 10-05-2010 Startdatum 01-07-2007 Samenvatting TMap NEXT Foundation is gebaseerd op de vernieuwde versie van TMap, zoals beschreven in het

Nadere informatie

Riskpoker - Confirmation - Planningpoker. Opfrissing TMap NEXT in scrum en toelichting op de opdracht Leo van der Aalst - Jos Punter - Hans Lantink

Riskpoker - Confirmation - Planningpoker. Opfrissing TMap NEXT in scrum en toelichting op de opdracht Leo van der Aalst - Jos Punter - Hans Lantink Riskpoker - Confirmation - Planningpoker 10-7-2013 Opfrissing TMap NEXT in scrum en toelichting op de opdracht Leo van der Aalst - Jos Punter - Hans Lantink 1 Presentatie (sprint) backlog items 1 2 3 4

Nadere informatie

Anko Tijman Een agile teststrategie op basis van MoSCoW

Anko Tijman Een agile teststrategie op basis van MoSCoW Titel, samenvatting en biografie Anko Tijman Een agile teststrategie op basis van MoSCoW Samenvatting: Deze presentatie behandelt de toepassing van de teststrategie vanuit een agile perspectief: welke

Nadere informatie

Factsheet Crowd Testen

Factsheet Crowd Testen Factsheet Crowd Testen www.testbats.com Uw klanten eisen tegenwoordig hoge kwaliteit van uw desktop applicatie, webapplicatie of mobile app. Onder alle omstandigheden en op elk apparaat. Daarom eist u

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

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

Sjabloon testplan op basis van SYSQA -teststrategieaanpak. <<Organisatie>>

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

Te hoog gemikte silver bullets missen doel Te hoog gemikte silver bullets missen doel

Te hoog gemikte silver bullets missen doel Te hoog gemikte silver bullets missen doel Te hoog gemikte silver bullets missen doel TestNet Voorjaarsevenement 2013 13-05-2013 Tom Heintzberger Praegus Ltd. Te hoog gemikte silver bullets missen doel 1-4-2013 1 Agile & testen? Want Geen geautomatiseerde

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

Verbeteren bij de Belastingdienst: Niet in de cloud maar beide benen op de grond

Verbeteren bij de Belastingdienst: Niet in de cloud maar beide benen op de grond Verbeteren bij de Belastingdienst: Niet in de cloud maar beide benen op de grond Mieke van Tongeren Bart Broekman Belastingdienst - Cluster IV 1 Mieke van Tongeren mj.van.tongeren@belastingdienst.nl 06-18304456

Nadere informatie

Testen van Datawarehouses en Informa2e. Kan het 2x zo snel, 2x zo goedkoop en 2x zo volledig?

Testen van Datawarehouses en Informa2e. Kan het 2x zo snel, 2x zo goedkoop en 2x zo volledig? Testen van Datawarehouses en Informa2e Kan het 2x zo snel, 2x zo goedkoop en 2x zo volledig? Wat verwachten we van DWH testen? 1. 2. 3. 4. 5. Gestructureerd Bekende afwijkingen Herhaalbaar (regressietesten)

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

Agile Testing isn t Risking IT! Bram Bronneberg Test Manager Logica - CGI

Agile Testing isn t Risking IT! Bram Bronneberg Test Manager Logica - CGI Agile Testing isn t Risking IT! Bram Bronneberg Test Manager Logica - CGI B.W.F.P.M. BRONNEBERG TEST MANAGER UIREMENT & QUALITY MANAGEMENT Introductie Q & A Achtergrond Agile Testing isn t Risking IT!

Nadere informatie

Marc Koper Performancetesten voor dummies

Marc Koper Performancetesten voor dummies Titel, samenvatting en biografie Marc Koper Performancetesten voor dummies Samenvatting: Systemen worden met de dag complexer met vaak ook nog veel koppelingen naar andere systemen. Maar men verwacht wel

Nadere informatie

10 trends in Performance testen of: wat hebben we écht te bieden?

10 trends in Performance testen of: wat hebben we écht te bieden? 10 trends in Performance testen of: wat hebben we écht te bieden? Martijn Ruff 30 mei 2012 Agenda Even voorstellen... Introductie 10 Trends Conclusies KETENBEWAKING TM 2 Even voorstellen... KETENBEWAKING

Nadere informatie

Het managen van een onderwijsorganisatie

Het managen van een onderwijsorganisatie Het managen van een onderwijsorganisatie Een bedrijfskundige aanpak met takenplaatje.nl Inhoud 1. Inleiding: vrijheid in gebondenheid 2. Het definieren van budgetgroepen 3. Vaststellen van de hoogte van

Nadere informatie

Whitepaper. Outsourcing. Uitbesteden ICT: Wat, waarom, aan wie en hoe? 1/6. www.nobeloutsourcing.nl

Whitepaper. Outsourcing. Uitbesteden ICT: Wat, waarom, aan wie en hoe? 1/6. www.nobeloutsourcing.nl Uitbesteden ICT: Wat, waarom, aan wie en hoe? 1/6 Inhoud Uitbesteden ICT: Wat, waarom, aan wie en hoe? 3 Relatie tussen ICT en 3 Outsourcen ICT: Wat? 3 Cloud Services 3 Service Level Agreement 3 Software

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

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

Gestructureerde Testaanpak

Gestructureerde Testaanpak Gestructureerde Testaanpak Gestructureerde Testaanpak; Agenda Introductie Waarom, hoe? Van dagelijkse praktijk naar structuur. Voordelen, Extra s Vragen Gestructureerde Testaanpak; Introductie. Bas Koreman

Nadere informatie

14/11/2010. Een duurzame testaanpak voor een veranderd informatiesysteem. Agenda. Wie is Albert?

14/11/2010. Een duurzame testaanpak voor een veranderd informatiesysteem. Agenda. Wie is Albert? Een duurzame testaanpak voor een veranderd informatiesysteem Albert Mohan & Han Toan Lim Agenda Introductie Koffiepauze Afronding testproject Afsluiting No. 2 Wie is Albert? Albert Mohan Testmanager, Testadviseur

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

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

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

Statistisch Testen Voorwaarden voor succesvolle toepassing ontbreken

Statistisch Testen Voorwaarden voor succesvolle toepassing ontbreken Statistisch Testen Voorwaarden voor succesvolle toepassing ontbreken Erik van Veenendaal (Improve Quality Services BV) Natuurlijk is statistisch testen een uitstekend idee. De vraag is echter of we als

Nadere informatie

Linkedin discussie: Hoe kan je best geld besparen op testen?

Linkedin discussie: Hoe kan je best geld besparen op testen? Linkedin discussie: Hoe kan je best geld besparen op testen? Snelle besparingen In deze tijden moet iedereen besparen. Dit wordt natuurlijk ook verwacht van een testteam: Waar kan je binnen testen besparen?

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

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

Testrisicoanalyse. Introductie

Testrisicoanalyse. Introductie 7 Testrisicoanalyse 7.1 Introductie Veel testtrajecten zijn tegenwoordig gebaseerd op risico s. Bij risicogebaseerd testen (RBT) bepaalt het risico dat de organisatie loopt als het systeem in gebruik wordt

Nadere informatie

Het ISACA RISK IT Framework voor Testers. Omgaan met risico s Risk Appetite Onderzoeken Maatregelen

Het ISACA RISK IT Framework voor Testers. Omgaan met risico s Risk Appetite Onderzoeken Maatregelen 1 Het ISACA RISK IT Framework voor Testers Omgaan met risico s Risk Appetite Onderzoeken Maatregelen 2 Wie is Jaap Ir. J. van der Leer CRISC CGEIT CISA 43 jaar in de IT werkzaam. 22 jaar ervaring in IT

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

Achter de schermen bij TPI Testscholen, kiezen of mixen?de praktijk

Achter de schermen bij TPI Testscholen, kiezen of mixen?de praktijk Achter de schermen bij TPI Testscholen, kiezen of mixen?de praktijk Wim ten Tusscher - Polteq TestNet najaarsevenement 2013 17 januari 2013 To be or not to be (een succesvolle tester) Context driven school

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

Tmap Dag 2015. Ik test, jij test, wij testen. Testen binnen een Wendbare Belastingdienst. 29 september 2015. Laurens Kremer

Tmap Dag 2015. Ik test, jij test, wij testen. Testen binnen een Wendbare Belastingdienst. 29 september 2015. Laurens Kremer Tmap Dag 2015 Ik test, jij test, wij testen Testen binnen een Wendbare Belastingdienst 29 september 2015 Laurens Kremer Introductie Naam: Laurens Kremer, SPC, CISA Rol: Agile coach Informatie Management

Nadere informatie

TMap NEXT Test Manager

TMap NEXT Test Manager Voorbeeldexamen TMap NEXT Test Manager Editie februari 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

Managers moeten beslissingen nemen over IT, maar hebben weinig kennis. Eli de Vries

Managers moeten beslissingen nemen over IT, maar hebben weinig kennis. Eli de Vries Managers moeten beslissingen nemen over IT, maar hebben weinig kennis Eli de Vries Managers moeten beslissingen nemen over IT, maar hebben weinig kennis Managers moeten beslissingen nemen over IT, maar

Nadere informatie

Van Samenhang naar Verbinding

Van Samenhang naar Verbinding Van Samenhang naar Verbinding Sogeti Page 2 VAN SAMENHANG NAAR VERBINDING Keuzes, keuzes, keuzes. Wie wordt niet horendol van alle technologische ontwikkelingen. Degene die het hoofd koel houdt is de winnaar.

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

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

Opleidingsaanbod: testopleidingen.com

Opleidingsaanbod: testopleidingen.com (Business, (IT) Projectmanagement, Quality Management, etc.) TMap NEXT Test Engineer(NL/ENG) Examentraining TMap NEXT Test Engineer E-learning TMap NEXT Test Engineer Certificering TMap NEXT Test Engineer

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

Van testproces tot testvak... en verder

Van testproces tot testvak... en verder V8.0 publ. Van testproces tot testvak... en verder Jurian van de Laar TestNet Jubileumevenement 15 mei 2017 Movers en shakers!! Ik heb ooit een ISTQB en/of TMap- opleiding gevolgd! Ik werk in een multi-disciplinair

Nadere informatie

TMap Next zoals het hoort!

TMap Next zoals het hoort! TMap Next zoals het hoort! Bart Broekman info@bartbroekman.nl Partner van Het verhaal en de moraal Aanleiding: Slimme mensen die domme dingen doen De kern van hoe het hoort Omdraaien van de volgorde Van

Nadere informatie

Incore Solutions Learning By Doing

Incore Solutions Learning By Doing Incore Solutions Learning By Doing Incore Solutions Gestart in November 2007 Consultants zijn ervaren met bedrijfsprocessen en met Business Intelligence Alle expertise onder 1 dak voor een succesvolle

Nadere informatie

Kasper Hanselman De speelse geest slaat alles stuk (Lucebert)

Kasper Hanselman De speelse geest slaat alles stuk (Lucebert) Titel, samenvatting en biografie Kasper Hanselman De speelse geest slaat alles stuk (Lucebert) Samenvatting: Whitebox tests worden (weer) steeds noodzakelijker: In Nederland zijn wij de afgelopen jaren

Nadere informatie

Inhoudsopgave. Bewust willen en kunnen 4. Performance Support 5. Informele organisatie 5. Waarom is het zo moeilijk? 6

Inhoudsopgave. Bewust willen en kunnen 4. Performance Support 5. Informele organisatie 5. Waarom is het zo moeilijk? 6 Inleiding De afgelopen vijftien jaar hebben we veel ervaring opgedaan met het doorvoeren van operationele efficiencyverbeteringen in combinatie met ITtrajecten. Vaak waren organisaties hiertoe gedwongen

Nadere informatie

Requirements en testen. Een introductie. Algemene informatie voor medewerkers van: SYSQA B.V.

Requirements en testen. Een introductie. Algemene informatie voor medewerkers van: SYSQA B.V. Requirements en testen 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

Agile Risico Analyse (ARA)

Agile Risico Analyse (ARA) Agile Risico Analyse (ARA) Gijs Op de Beek 1 Inhoud 1. Opening 2. Waarom 3. Traditionele PRA vormen 4. Agile Risico Analyse 5. Beheersen van Risico s 6. Monitoren van Risico s Sogeti presentatie ARA 2017

Nadere informatie

Testen en BASEL II. Dennis Janssen. Agenda. Wat is BASEL II? Testen van BASEL II op hoofdlijnen

Testen en BASEL II. Dennis Janssen. Agenda. Wat is BASEL II? Testen van BASEL II op hoofdlijnen Testen en BASEL II Dennis Janssen Test Research Centre LogicaCMG 1 Agenda Wat is BASEL II? Testen van BASEL II op hoofdlijnen BASEL II als hulpmiddel om positie testen te versterken Samenvatting 2 1 Basel

Nadere informatie

Testplan IpMEDT3 project

Testplan IpMEDT3 project Testplan IpMEDT3 project Versie: 1.0 Groepsbegeleider: Bob Zadok Blok Groepsleden: Luuk Gortzak (s1062708) Jens Brokaar (s1066589) Ellis Stroet (s1066586)

Nadere informatie

Thomas Veltman Praktisch usability testen Najaarsevent TestNet: 22 september 2009

Thomas Veltman Praktisch usability testen Najaarsevent TestNet: 22 september 2009 Titel, samenvatting en biografie Samenvatting Thomas Veltman Praktisch usability testen Najaarsevent TestNet: 22 september 2009 Er zijn een aantal opvallende verschillen in de benadering van testen van

Nadere informatie

Vrijgaveadvies. Project <naam 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

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

Risk And Requirement Based Testing bij Acerta

Risk And Requirement Based Testing bij Acerta Risk And Requirement Based Testing bij Acerta Bart.Dooms@acerta.be Testverantwoordelijke Acerta November 2005 RRBT bij Acerta AGENDA Acerta? Risk en Requirements Based Testing (RRBT)? Hoe? Risicoanalyse

Nadere informatie

Testen van digitale leeromgevingen bij ThiemeMeulenhoff. Een Exploratory testaanpak in een veranderende wereld.

Testen van digitale leeromgevingen bij ThiemeMeulenhoff. Een Exploratory testaanpak in een veranderende wereld. Testen van digitale leeromgevingen bij ThiemeMeulenhoff Een Exploratory testaanpak in een veranderende wereld. Hallo! Rob van Steenbergen Tester sinds 1996 Diverse rollen Sinds 2008: Chickenwings Test

Nadere informatie

Dirk van Dael Wanneer iedereen jouw cijfers wil zien Voorjaarsevent Testnet: 22 juni 2009

Dirk van Dael Wanneer iedereen jouw cijfers wil zien Voorjaarsevent Testnet: 22 juni 2009 Titel, samenvatting en biografie Samenvatting: Dirk van Dael Wanneer iedereen jouw cijfers wil zien Voorjaarsevent Testnet: 22 juni 2009 Succesvolle softwareontwikkeling en -testen is zelden toeval. Achter

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

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

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

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