2 TESTEN: HET RISK SPEL

TKo_Testen het risk-spel_v1 95 Testen: het 'risk' spel

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’ versie 2.0, 15 mei 2007

1


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.

2.2.1

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.

2.2.2

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’ versie 2.0, 15 mei 2007

2


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.

2.2.3

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.

2.2.4

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’ versie 2.0, 15 mei 2007

3


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.

2.2.5

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.

2.2.6

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’ versie 2.0, 15 mei 2007

4


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 testen 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’ versie 2.0, 15 mei 2007

5


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’ versie 2.0, 15 mei 2007

6


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 3e 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’ versie 2.0, 15 mei 2007

7


“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: 9072194586 | ISBN13: 9789072194589 (2e druk) Bouman, E. (2004) Effectievere informatiesystemen door slim testen, Sdu Uitgevers, ISBN10: 9044009516 | ISBN13: 9789044009514 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: 9044005545 | ISBN13: 9789044005547 Koomen, T., L. van der Aalst, B. Broekman, M. Vroon (2006) TMap® Next voor resultaatgericht testen, Uitgeverij Tutein Nolthenius, ISBN: 9072194799 | ISBN13: 9789072194794

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’ versie 2.0, 15 mei 2007

8

2 TESTEN: HET RISK SPEL

Recommend Documents