TESTKRANT MAGAZINE VOOR DE NEDERLANDSE TESTER

Maat: px
Weergave met pagina beginnen:

Download "TESTKRANT MAGAZINE VOOR DE NEDERLANDSE TESTER"

Transcriptie

1 TESTKRANT MAGAZINE VOOR DE NEDERLANDSE TESTER Visual management binnen de testafdeling Meer resultaat en plezier met Kanban Derk-Jan de Grood En ook artikelen van Erik van Veenendaal Jeroen Mengerink Bryan Bakker Jaargang Editie 1 Gratis magazine van TestNieuws.nl - Meer info op

2 Voorwoord Een aantal maanden geleden bedacht ik dat er een Nederlandstalig glossy magazine voor testers moest komen. Naast het feit dat zo'n blad er namelijk nog niet was, is TestNieuws met bezoekers per jaar ook nog eens het uitgelezen platform om zo'n magazine te lanceren. Het plan was dat de artikelen werden aangeleverd door de Nederlandse testcommunity, waarna ik alles zou samenvoegen tot een mooi magazine. Dat laatste bleek toch iets meer voeten in de aarde te hebben dan gedacht. Na het uitschrijven van de "call for papers" kwamen de artikelen inderdaad binnen en kon het opmaken beginnen. Maar dat was toch wel even andere koek dan een powerpoint of factsheet in elkaar knutselen. Gelukkig leer ik snel en kreeg ik een hoop hulp van mijn grootste "vriend" Google. Alle in ons huis aanwezige bladen dienden op een gegeven moment als inspiratiebron. Van de Computer Totaal tot de Linda, ja zelfs de Donald Duck heb ik met andere ogen bekeken. Na de nodige mislukte pogingen kreeg ik het onder de knie en op een gegeven moment begon ik er zelfs plezier in te krijgen. Vanaf dat moment wist ik dat het goed zou komen. Na de heel wat spreekwoordelijke bloed, zweet en tranen ben ik dan ook heel trots dat ik, zij het iets later dan gepland, de eerste editie van de TestKrant mag aankondigen. In deze editie vinden jullie allereerst het hoofdartikel van Derk-Jan de Grood over Kanban. In verhaalvorm vertelt hij hoe drie managers samen ontdekken hoe visual management meer plezier brengt en het testen kan ondersteunen. Dan volgt Bryan Bakker met een ervaringsverhaal over Model Driven Development en de impact die het gebruik van formele modellen heeft op het testen. Zijn testers wellicht overbodig als de software wordt gegenereerd? Verder een artikel van Jeroen Mengerink waarin hij enkele situaties beschrijft die aangeven waar de toenemende vraag naar technische testers vandaan komt. Het laatste artikel is van Erik van Veenendaal over het langverwachte ISTQB advanced level. Hij geeft onder andere een volledig overzicht van de bijbehorende syllabus, door sommige al het ISTQB kroonjuweel genoemd. Hoewel ik al behoorlijk trots ben op deze eerste editie kan het natuurlijk altijd beter. Dus hebben jullie opmerkingen, aanmerkingen, suggesties, tips, pluimen, complimenten of uitzinnige lofbetuigingen, dan hoor ik dat graag. Mail ze dan naar Ook artikelen voor de volgende editie kunnen jullie naar dit adres mailen. Wanneer de volgende editie uitkomt weet ik nog niet, dat hangt mede af hoe deze eerste editie door jullie wordt ontvangen. Ik wens jullie veel leesplezier en uiteraard ook een fijne zomervakantie toe. Groet, Marco van der Spek Inhoudsopgave Voorwoord door Marco van der Spek Meer resultaat en plezier met kanban door Derk-Jan de Grood Model Driven Development en de impact op testen door Bryan Bakker Advertentie Test4gold door SQS Groeiende vraag naar technische testers door Jeroen Mengerink ISTQB Expert Level Verbeteren van het Testproces door Erik van Veenendaal TestKrant - Jaargang Editie 1

3 Meer resultaat en plezier met kanban Door Derk-Jan de Grood Het is vrijdagmiddag Simon, Suzanne en Maik hebben afgesproken bij het whiteboard. Zij willen weten of kanban waarde heeft voor hun testafdeling. Suzanne denkt aan de rol met bruin papier die beneden ligt, kijkt naar de post-its in haar hand en besluit dat ze deze net zo goed op het whiteboard kunnen plakken. Ze pakt de stift en schrijft op het bovenste post-it: Kanban binnen onze testafdeling. Ze plakt hem midden op het whiteboard en kijkt haar collega s aan. Zo goed?. Maik corrigeert haar. Eigenlijk is het niet kanban, maar visual management legt hij uit. Visual management binnen de testafdeling 3 TestKrant - Jaargang Editie 1

4 Kanban is een lean procesmanagement systeem dat erop gericht is om de flow te optimaliseren. Je gebruikt hiervoor een een kanbanbord, dat kan bestaan uit een whiteboard met verschillende kolommen erop. Elk van de kolommen vertegenwoordigt een stap in het proces. Dit proces wordt ook wel de value stream genoemd. Bestelling geplaatst Betaald Verstuurd Afgeleverd Door middel van post-its worden taken op het bord geplakt. Elke post-it, of taak, maakt gedurende zijn levensloop een reis van de linker kolom op het bord (de back-log), door alle stappen in het proces naar de meest rechter kolom (afgeronde taken). Suzanne voegt daar aan toe In organisaties die kanban doen, wordt elke ochtend een meeting gehouden bij het bord. Hierbij zijn alle teamleden betrokken. Kanban helpt om het werk te verdelen, maakt inzichtelijk waar de bottlenecks zitten en zorgt voor een optimale afhandeling van werkpakketten. Dat is precies wat we willen!, roept Simon enthousiast, Een betere beheersing van de testtaken en het vergroten van onze efficiëntie. Onze testafdeling heeft veel taken. We moeten reviewen, testen ontwerpen en uitvoeren, regressietesten uitvoeren. We werken aan verschillende projecten en releases en er loopt er een TPI traject. De business staat geregeld op de drempel met wijzigingen of productie- verstoringen. Een betere grip op onze activiteiten, dat klinkt goed. Daarbij ook nog kostbare testtijd besparen klinkt nog beter!. Maar, Maik is nog niet klaar: Bij visual management maken we gebruik van kanban, maar naast het kanbanbord hebben we nog twee andere borden. Dit zijn het keek op de week en verbeterbord. Op het keek op de week bord wordt de stuurinformatie bijgewerkt. Aan de hand van een aantal dashboards wordt bijgehouden wat de productie van het team is. Dit bord wordt gebruikt om de effecten van beslissingen en verbeteringen inzichtelijk te maken, maar maakt tevens de waarde van het team zichtbaar. Op het verbeterbord worden verbeterideeën vastgelegd. Omdat het hele team rond het bord staat en de voortgang bespreekt, komen er vaak bottlenecks en verbeteringen te sprake. Door deze te verzamelen, raken ze niet verloren en kunnen ze beheerst worden doorgevoerd. Goed, ik ben overtuigd zegt Suzanne, ze schrijft een nieuwe post-it en plakt deze over de eerste heen: Visual Management voor testafdelingen. Nu wordt het tijd voor het echte werk. Een goede brainstormsessie over de rol van visual management binnen testteams volgt. Hieronder delen zij een paar van de conclusies: Workflow? Dan kan kanban Kanban is toe te passen op veel verschillende processen. Eigenlijk is het toepasbaar zodra je een workflow hebt met een aantal vaste stappen die je doorloopt. Dat komt mooi uit want veel testafdelingen werken met een redelijk standaard workflow, die mogelijk zelfs in een algemene teststrategie is verwoord. Toch is het vaak moeilijk om overzicht te houden, omdat een afdeling werkt voor verschillende projecten met elk hun eigen projectmanagers. Betere beheersing van de testtaken en het vergroten van onze efficiëntie Daarnaast worden testafdelingen vaak betrokken bij het testen van productieverstoringen of wijzigingen die buiten projecten omgaan. 4 TestKrant - Jaargang Editie 1

5 Sander knikt instemmend. Overzicht houden is een probleem op onze testafdeling. We houden ons bezig met: Review van specificaties Opstellen van testgevallen Uitvoeren van testgevallen Hertesten van opgeloste bevindingen Uitvoeren van regressietesten Assisteren bij productieproblemen Doorvoeren van changes Wegwerken van testautomatiseringsbacklog Testverbeteringen en innovaties Dat zijn erg veel verschillende taken om het overzicht op te houden. Kanban helpt om een goed overzicht te houden op al deze activiteiten. Door de activiteiten te chuncken in kleinere werkpakketten, kan op het kanbanbord worden bijgehouden welke activiteiten onderhanden zijn of worden afgerond. Het overzicht maakt het mogelijk om een balans te houden tussen: hoge en lage prioriteit functies, operationele- en projectactiviteiten testverbeteringen en -innovaties en operationele activiteiten. Flow boven utilisatie Kanban is gebaseerd op de theory of constrains (TOC). TOC richt zich op een maximale throughput door het verwijderen van bottlenecks. Van oorsprong is dit toegepast op fabricageprocessen, waar, als je op utilisatie stuurt, elk van de teams hun deelproducten de workflow in drukken. Als er echter een bottleneck in het fabricageproces zit, bijvoorbeeld bij de integratie, ontstaan er grote stapels deelproducten en loopt het proces vast. Er worden geen extra eindproducten verkocht. Veel traditionele managers sturen nog op utilisatie en we betalen je om te werken is hun motto. Zo zorgen ze ervoor dat iedereen maximaal bezig is. Door het accent te verleggen van utilisatie naar flow, ontstaat er oog voor de bottlenecks. De focus verlegt zich naar het maximaliseren van het aantal afgeronde producten. Deze vertegenwoordigen businesswaarde. Er ontstaat een pull in plaats van een push waarbij in dit voorbeeld de integratieafdeling aangeeft hoeveel deelproducten ze kan verwerken. Binnen kanban werken we daarom met WIP-limieten. 5 TestKrant - Jaargang Editie 1

6 WIP staat voor work in progress en de WIP-limiet geeft aan hoeveel taken een team kan verwerken. WIP-limieten Als er voldoende deelproducten gemaakt zijn, zit een teamlid misschien eventjes niets te doen. Dat mag; immers we weten dat onze doorlooptijd optimaal is. Dit principe is natuurlijk prima te vertalen naar de eerdergenoemde testactiviteiten, legt Suzanne uit, De maximale flow levert een maximaal aantal geteste systeemonderdelen, changes, bugs of afgedekte risico s op die naar productie kunnen. 6 TestKrant - Jaargang Editie 1

7 Het is adaptief Bij kanban leg je niet alles van te voren vast, je bent dus als team zeer adaptief. Je kunt dus optimaal meebewegen als de inhoud van de releases wordt aangepast, de functionaliteit wijzigt of het team moet bijspringen bij productieverstoringen. Dit maakt dat het team echt risicogebaseerd kan werken. Elke dag wordt er opnieuw bepaald welke risico s aangepakt moeten worden. Nieuwe inzichten kunnen meteen worden meegenomen en het kanbanbord helpt daarbij om de resources te managen. Zo kunnen taken in de priority lane worden geplaatst, en met zeer veel spoed worden afgehandeld. De impact van wijzigingen wordt direct inzichtelijk. Omdat ook het management bij de daily meetings betrokken is, wordt duidelijk wanneer inzet ten koste gaat van geplande verbeterslagen. Grotere zichtbaarheid en betere samenwerking Daarnaast triggert kanban een grotere zichtbaarheid en een betere samenwerking. Met het bord als de nieuwe hang-out plaats, worden de testers binnen het competence center uitgedaagd om elkaar te helpen. Met zijn teamgenoten kan hij bespreken wat er nodig is om zijn taak zo snel mogelijk af te ronden. Maar het kan lonen om ook andere disciplines uit te nodigen bij de standing meetings. Suzanne: Ik sprak recent een klant van ons over dit voorstel en hij vertelde dat hij liever de testers laat aanschuiven bij de daily meetings van het ontwikkelteam. Een goed idee, reageert Simon, maar binnen zijn organisatie wordt agile ontwikkeld. Dat gaat niet op voor de testafdelingen die werken in meer traditionele organisaties, zoals de onze. In deze organisaties levert het veel betrokkenheid op als je iemand van de business, de releasemanager of iemand van het ontwikkelteam uitnodigt bij het kanbanbord van de testers. 7 TestKrant - Jaargang Editie 1

8 Het is belangrijk om als testafdeling je toegevoegde waarde voor de business zichtbaar te maken. Samenwerken is perfect hiervoor, omdat de mensen met wie je samenwerkt als geen ander weten welk verschil je maakt. Daarnaast is het belangrijk om een goed testverhaal te vertellen. Visual management is een in de schoot geworpen tool om dit te doen. De borden maken zeer inzichtelijk wat er gebeurt. Een manager kan elk moment van de dag naar een van de borden lopen en zelf zien wat de status is. Visual management zorgt ervoor dat ook anderen weten wat er gebeurt. Geïnteresseerden kunnen met eigen ogen zien, welk werk klaar is en wat er nog open staat. Dit bevordert betrokkenheid en betrekt belanghebbenden in de besluitvorming. Meer plezier, van workflow naar personal flow Hebben jullie weleens in de flow gezeten?, vraagt Maik ineens. Suzanne en Simon kijken elkaar aan. Dit is een onverwachte vraag. Ze zitten graag in de flow en dat weten zij van elkaar. Ze zoeken elkaar niet voor niets op voor brainstormsessies zoals die van vandaag. Blijkbaar is dit voor veel mensen een relevante vraag omdat flow niet voor iedereen vanzelfsprekend is. Maik licht zijn vraag toe: Welke manager wil dat zijn team onthouden? Maik, Simon en Suzanne in ieder geval niet. Enthousiast geven ze elkaar een high-five. Tevreden met het resultaat van deze eerste brainstorm maken ze een foto van het whiteboard. We moeten meer mensen in deze discussie betrekken, stelt Simon, we moeten nog veel leren, maar hiermee kunnen we vast meer halen uit onze bestaande testprocessen. Derk-Jan de Grood werkt als testexpert bij Valori. Hij adviseert organisaties bij het inrichten en verbeteren van hun testactiviteiten. Als productmanager werkt hij aan innovaties in het Valori dienstaanbod. Daarnaast spreekt en publiceert hij met groot enthousiasme over ontwikkelingen in het testvak. Veel mensen zitten in de flow als ze bezig zijn met hun hobby, niet op hun werk. Werken met lean, kanban en visual management zorgt ervoor dat mensen positief worden uitgedaagd. Ze hebben een plek in het team en komen veel sneller in de flow. Simon fronst niet begrijpend zijn wenkbrauwen, maar voordat hij kan vragen hoe dat dan komt, neemt Susanne het woord. Als je met kanban werkt, dan werk je samen. Het hele team werkt aan een gemeenschappelijk doel. Teamleden worden hierdoor ingezet op die dingen waar ze sterk in zijn en kunnen hierdoor meer zichzelf zijn. Je krijgt meer verantwoordelijkheid en hebt veel autonomie. Daarnaast krijg je directe feedback over je prestaties. Het bord maakt zichtbaar wat je hebt bereikt Ja, en zo wordt de workflow een persoonlijke flow, zegt Maik, Dit werkt stimulerend en maakt dat teams beter presteren en meer plezier hebben in hun werk. Meer resultaat en meer plezier? vat Simon het betoog samen. Maik en Suzanne knikken bevestigend. 8 TestKrant - Jaargang Editie 1

9 Model Driven Development en de impact op testen Door Bryan Bakker Bij mijn werkgever worden meerdere projecten uitgevoerd met behulp van Analytical Software Design (ASD) [1]. Deze suite biedt software engineers de mogelijkheid delen van software te generen aan de hand van formele modellen, het zogenaamde Model Driven Development (MDD). Het aantal fouten in deze gegenereerde code zou aanzienlijk kleiner moeten zijn dan in zelf geschreven code. Wat is de impact van model driven development op het test traject? Zijn testers overbodig als de software wordt gegenereerd? 9 TestKrant - Jaargang Editie 1

10 Bij een van onze klanten wordt de methode van model driven development gebruikt bij het ontwikkelen van software voor elektronen microscopen. Deze microscopen bieden een veel hogere vergrotingsfactor dan traditionele licht microscopen. Het is zelfs mogelijk om atoomstructuren zichtbaar te maken. Een belangrijk onderdeel van een dergelijk systeem is het vacuüm, dat nodig is voor het transport van de elektronen. Deze moeten zonder verstoring het specimen (object dat vergroot wordt) bereiken. Dit vacuüm subsysteem bestaat uit verschillende pompen, kleppen en meters om vacuüm te creëren en in stand te houden. Deze onderdelen worden aangestuurd door complexe software. In een recent project werd dit subsysteem onderworpen aan een redesign, hiervoor werd MDD gebruikt. Bij model driven development definieert de software ontwikkelaar het design van de software in modellen. De modellen moeten nauwkeurig gespecificeerd worden. Ook moeten ze volledig zijn en mogen geen fouten bevatten, zoals bijvoorbeeld deadlocks. Niet alleen het zogenaamde goed weer gedrag moet worden gemodelleerd, ook het slecht weer gedrag maakt onderdeel uit van de modellen. Dit model wordt automatisch geconverteerd naar een formeel wiskundig model. Op dit wiskundige model worden verschillende (automatische) verificaties uitgevoerd. Zo worden mogelijke deadlocks, race-condities of starvations in het design (het model) gedetecteerd en aan de ontwikkelaar gerapporteerd. Deze kan de fouten vervolgens in het model oplossen. Pas als alle fouten uit het design verwijderd zijn, is het mogelijk de code (in verschillende talen) te laten genereren. De code correspondeert met het wiskundige model en is daarmee ook vrij van deadlocks, raceconditions etc. In onderstaand figuur is dit proces schematisch weergegeven. Niet alle software die bij het redesign werd aangepakt is gegenereerd. Alleen kritieke en complexe onderdelen zijn op deze manier afgehandeld. ASD is uitermate geschikt voor het modelleren van constructies als state machines, gedrag beschreven met behulp van messagesequence-diagrams of complexe algoritmen. Ook communicatie vanuit software richting firmware of hardware is op deze manier te modelleren. De methode is daarmee zeer geschikt voor technische systemen, waar dergelijke constructies veel gebruikt worden, maar is zeker ook toepasbaar in andere omgevingen. Naast de software bevat het systeem nog andere disciplines zoals mechanica, elektronica en optica. De functionaliteit van deze disciplines is niet op deze manier gemodelleerd, dus uiteindelijk is slechts een klein (maar kritiek) gedeelte van het systeem gemodelleerd. Wat betekent dit voor de test activiteiten in het project? Model: - Precise - Complete - Correct Design errors Generate formal model Genrate defect free source code from verified model Formal model and verification Guaranteed equivalence Source code: - Java - MISCRA C - C++ - C# 10 TestKrant - Jaargang Editie 1

11 De functionele verificaties op systeem niveau (software en alle andere disciplines) moeten nog steeds gebeuren, of er nu wel of niet delen van de software zijn gegenereerd. In de modellen kunnen functionele fouten zitten, die zo ook in het systeem terecht zijn gekomen. Model driven development helpt hier niet direct bij, immers functioneel gedrag wordt niet automatisch geverifieerd. Hierbij geldt het rubbish in = rubbish out principe. Reviewen en executeren van de modellen voordat code wordt gegenereerd kan hier wel aanzienlijke verbeteringen brengen. Dit is vergelijkbaar met het reviewen van design documentatie. Test activiteiten op integratie vlak tussen software componenten onderling en tussen software en andere disciplines zijn ook nog steeds hard nodig. Juist de integratie tussen gemodelleerde componenten (met gegenereerde code) en niet gemodelleerde componenten (met handwritten code ) is zeker niet triviaal. Model driven development heeft daarentegen wel grote invloed op de test activiteiten die normaalgesproken door de ontwikkelaars zelf worden uitgevoerd: de component testen. De component testen die gericht zijn op de structuur van de code (white box) controleren op onder andere de aanwezigheid van programmeerfouten. Deze zullen door de aanpak van MDD niet meer aanwezig zijn in de gegenereerde code, althans dat is het idee. Component testen zijn dus in principe overbodig voor gegenereerde code. Eventuele black box aspecten van component testen zijn overigens nog wel waardevol. MDD heeft dus grote invloed op de testen van de ontwikkelaars. Blijven de overige test activiteiten dan exact hetzelfde? Nee, zeker niet. Gedurende de functionele verificaties zijn we de nodige problemen tegengekomen. Deze problemen waren terug te voeren op bijvoorbeeld onduidelijke requirements of voortschrijdend inzicht. Functionele testen zijn dus nog steeds zeer nuttig. Daarnaast hebben we uitgebreide reliability testen op systeem niveau uitgevoerd. Dus zowel de software als alle hardware werden met het testen meegenomen. Deze testen waren gericht op de wijzigingen in het system (het redesign). Al vrij snel kwamen we problemen in de hardware tegen, zoals slijtage van oudere onderdelen en onverwacht grote variatie in mechanische onderdelen. In vergelijkbare voorgaande projecten waarbij geen gebruik was gemaakt van MDD duurde het vele malen langer voordat dergelijke hardware problemen werden 11 TestKrant - Jaargang Editie 1

12 gevonden door reliability testen. Eerst werden talloze software problemen gevonden die allemaal geanalyseerd en opgelost moesten worden voordat het testen verder kon gaan. Pas in een veel later stadium, als de belangrijkste software problemen op het gebied van reliability opgelost waren kon er ook iets over hardware gezegd worden. Met de nieuwe aanpak zijn we dus in staat veel eerder de reliability daadwerkelijk te meten, in plaats van weken lang testen uit te voeren, problemen te vinden, te analyseren en op te lossen. Sterker nog: er is geen enkel reliability issue in de gegeneerde code gevonden tijdens deze testen. Een opmerkelijk resultaat. Want juist dit soort reliability issues, zoals deadlocks en/of raceconditions, veroorzaken vaak grote problemen gedurende projecten. Zeker als dergelijke problemen pas laat naar boven komen. Het redesign in deze case was onderdeel van een veel groter project, maar heeft dit project niet verstoord. Ook al betrof het een zeer grote wijziging. Zoals gezegd zijn de meeste testactiviteiten nog steeds noodzakelijk, maar MDD heeft ook op deze activiteiten invloed. Dit is mooi te zien met behulp van de Product Risico Analyse (PRA), bekend van TMap en ISTQB. In onderstand figuur is een voorbeeld van een PRA te zien. Als component 1 MDD heeft grote invloed op het test traject, testen blijft echter nog steeds noodzakelijk. nu wordt gerealiseerd met behulp van model driven development, dan zal er op de x-as van de impact niets veranderen. De impact van mogelijke fouten in component 1 blijft uiteraard exact gelijk. De likelihood daarentegen zal kleiner worden als component 1 met MDD wordt ontwikkeld en niet op de traditionele manier. Zo is het mogelijk dat component 1 in een ander kwadrant komt en op een andere manier getest kan worden. De kwaliteit van componenten ontwikkeld met MDD zullen naar verwachting (veel) minder programmeerfouten bevatten. Dit was in het hier beschreven project direct zichtbaar. De test engineers kunnen hun aandacht en tijd vervolgens Could test Must test 15 Likelihood 9 Comp1 MDD Comp2 Comp3 Won t test Impact Should test 12 TestKrant - Jaargang Editie 1

13 beter op andere testactiviteiten richten, gekoppeld aan hogere risico klassen. Door voortschrijdend inzicht zijn er toch wijzigingen aangebracht aan het ontwerp van het vacuüm subsysteem. Het model stelde de ontwikkelaars in staat deze wijzigingen snel aan te brengen met behoud van de kwaliteit. De modellen worden immers meteen (automatisch) geverifieerd op (programmeer) fouten. MDD past dan ook uitstekend in projecten die op een Agile manier worden uitgevoerd. MDD heeft grote invloed op het testtraject. Testen blijft echter nog steeds noodzakelijk. De ontwikkelaarstesten kunnen drastisch worden ingekort. Testen op integratie niveau en hoger blijven belangrijk, maar kunnen op een andere manier worden ingevuld. Dit past uitstekend in de aanpak van risk based testen (PRA). Daarnaast is in deze case duidelijk geworden dat MDD een zeer positieve invloed heeft op de reliability van de (gegenereerde) software. Alleen dit voordeel is voor systemen die een hoge reliability eisen al reden genoeg om MDD serieus te overwegen. Als gevolg van deze positieve ervaring met MDD worden op dit moment bij de klant meerdere redesigns op dezelfde manier uitgevoerd. [1] Voor meer informatie over ASD, Analytical Software Design, zie Bryan Bakker is werkzaam bij Bij Sioux Embedded Systems (www.sioux.eu). In 1998 is hij afgestuurd aan de TU Eindhoven (Technische Informatica). Bryan heeft enkele jaren gewerkt als software engineer, en heeft zich daarna gespecialiseerd op het testen van embedded software in multidisciplinaire omgevingen (software, mechanica, elektronica, optica) bij hightech bedrijven in bijvoorbeeld de medische sector, professionele beveiligingssystemen, semi-industrie en nano technologie. Daarnaast geeft Bryan regelmatig cursussen en lezingen op (internationale) congressen. 13 TestKrant - Jaargang Editie 1

14 DOE MEE! Laat zien hoe goed jij bent in testen Win een reis naar de Olympische Spelen 2012 in Londen Drie uitdagende games vormen de basis voor de Test 4 Gold competitie. Allemaal vragen ze verschillende skills die de basis vormen voor een succesvolle carrière als software tester. Ben je snel van begrip, analytisch en heb je een goed geheugen? Test jezelf en kijk of jij bij de nummer 1 in testen past. gold.nl

15 Groeiende vraag naar technische testers Door Jeroen Mengerink De wereld verandert en dat brengt andere eisen aan testers met zich mee. Vooral het technische aspect van testen komt steeds meer naar voren. De snelle opkomst van cloud computing zorgt ervoor dat veel functionaliteit uit de cloud kan worden afgenomen. Naast het testen bij de business of deze functionaliteit de processen goed ondersteunt, is ook technisch testen nodig. Om de functionaliteit te integreren met bestaande systemen, zal namelijk een technische koppeling nodig zijn. Daarnaast zal voor het monitoren van de correcte werking in productie testautomatisering ingericht moeten worden, waar ook weer technische testers voor nodig zijn. 15 TestKrant - Jaargang Editie 1

16 De andere grote hype die meespeelt bij de vraag naar technische kennis is Agile. Door het inzetten van multidisciplinaire teams, komt de tester dichter tegen de ontwikkelaar aan te zitten. De communicatie tussen deze partijen, die voorheen vooral via uitgebreide documentatie liep, zal nu direct plaatsvinden. Om deze communicatie soepel te laten verlopen, zullen de ontwikkelaars wat van testen moeten weten, maar zullen de testers dus ook kennis van ontwikkelen nodig hebben. Het iteratieve en incrementele karakter dat Agile heeft, vraagt ook om het steeds vaker uitvoeren van een regressietest. De noodzaak voor testautomatisering neemt hierdoor ook toe. In dit artikel beschrijf ik voor cloud, Agile en testautomatisering enkele situaties die aangeven waar de vraag naar technische testers vandaan komt Cloud Meer en meer bedrijven nemen diensten af uit de cloud, denk hierbij aan , CRM of zelfs hele omgevingen. Al deze diensten worden via het internet benaderd en moeten geïntegreerd worden in de huidige bedrijfsprocessen. Het testen of de communicatie met deze cloud services goed gaat is een technische bezigheid. Er zal goed gekeken moeten worden naar het berichtenverkeer, wat zonder GUI vaak beter bekeken kan worden. Het gebruik van cloud services heeft ook grote invloed op interne ontwikkeltrajecten. Wanneer ketens getest moeten worden vanwege interne aanpassingen, is het veelal ongewenst om dit te doen terwijl de koppeling met de (live) cloud service actief is. In deze gevallen zal dus een stub of mock gemaakt moeten worden, zodat de cloud service gesimuleerd kan worden en de processen getest kunnen worden zonder de productieversie van de cloud service te raken. In het geval van afspraken of contracten met de leverancier over de prestaties van de cloud service zal in productie gekeken moeten worden of de leverancier zich wel aan zijn afspraken houdt. Er ontstaat dus vraag naar frequente (of zelfs continue) tests die het gedrag van de service kunnen monitoren. Hiervoor is goede testautomatisering nodig, waar ik later in dit artikel op terugkom. Agile Bij Agile wordt uitgegaan van vier simpele basisprincipes: Mensen en hun onderlinge interactie boven processen en tools Werkende software boven allesomvattende documentatie Samenwerking met de klant boven contractonderhandelingen Inspelen op verandering boven het volgen van een plan Dat onderlinge interactie belangrijk is, is te merken in de multidisciplinaire teams. De minder uitgebreide documentatie vereist dat de mensen in de teams goed met elkaar communiceren over wat ze aan het doen zijn. Om te kunnen begrijpen wat andere teamleden doen, zal enige kennis van de aanwezige vakgebieden nodig zijn. Vandaar dat van de testers verwacht wordt dat zij in ieder geval basis programmeerkennis en -vaardigheden bezitten. Het is belangrijk om mee te kunnen discussiëren over software architectuur en mogelijke oplossingen. De oplossingsrichting kan namelijk door de teams bepaald worden. Het is belangrijk om mee te kunnen discussiëren Door het kort-cyclische karakter zullen ook vaak tests uitgevoerd worden op producten die nog niet volledig af zijn. Hiervoor zal de tester vaak technische voorzieningen in moeten zetten. Denk, net als bij cloud, aan het gebruik van drivers, stubs of mocks. Het maken of inrichten van deze testondersteunende voorzieningen zal door de testers aangegeven (en bij voorkeur ook gerealiseerd) moeten worden. In korte iteraties moet werkende software opgeleverd worden, die voortborduurt op opleveringen in eerdere iteraties. Elke iteratie komt er nieuwe functionaliteit bij, die in de volgende iteratie nog steeds moet werken. Ofwel, de regressietestset groeit gestaag en de tijd om de 16 TestKrant - Jaargang Editie 1

17 tests uit te voeren is beperkt. Het regelmatig uit moeten voeren, samen met de tijdsdruk, levert een goede business case voor testautomatisering. Het goed nadenken over en inzetten van testautomatisering zijn vereisten voor een goed Agile traject. Gezien de regelmatige opleveringen is het belangrijk om goed versie- en configuratiemanagement te hebben. Ook de testers zullen hier aan moeten bijdragen. Wanneer en hoe moet geïntegreerd worden en welke eisen worden aan de verschillende ontwikkelomgevingen gesteld? Technische kennis zal hier helpen om een beter en duidelijker beeld te krijgen van wat zal moeten gebeuren. Testautomatisering Dat aan testautomatisering technische aspecten zitten is niet te ontkennen. Aangezien zowel bij cloud als bij Agile testautomatisering naar voren komt, is voldoende aanleiding om hier specifieke aandacht aan te besteden. Zeker gezien het feit dat ook in andere trajecten steeds meer vraag is naar testautomatisering. Testautomatisering kan plaatsvinden op verschillende niveaus. De basis wordt gelegd in unit testen. Hoewel de unit tests over het algemeen door de ontwikkelaars gemaakt worden, betekent dit niet dat we hier als testers niets mee te maken hebben. De ontwikkelaars kunnen geholpen worden door het toepassen van structurele technieken, waar de testers over het algemeen meer kennis van hebben. Door middel van pair programming kan een tester hier ondersteuning bieden, door tijdens het maken van unit tests naast de programmeur te zitten om zo aan te geven welke testgevallen gemaakt moeten worden. Naast het helpen bij het opstellen, kunnen de unit tests natuurlijk ook gereviewd worden. Ook hier is weer kennis van en vaardigheden met programmeren nodig. Functionele testautomatisering ligt meer bij de testers. In de Agile trajecten is te zien dat de grafische interface regelmatig aangepast wordt, om de automatisering robuust te houden zal deze moeten plaatsvinden op de laag eronder. Het aanroepen van functies zonder de grafische interface te gebruiken, vereist kennis van de manier waarop geprogrammeerd is. Wanneer toch automatisering gemaakt wordt die de grafische interface gebruikt, zal deze op enige manier aangeroepen moeten worden. Hoewel het weinig technisch werk lijkt doordat bijvoorbeeld Fitnesse [1] of Cucumber [2] gebruikt kan worden door de testers, zal toch enig programmeerwerk nodig zijn. Het aanspreken van het testobject kan namelijk alleen maar wanneer voor Fitnesse en Cucumber een interpretatielaag aanwezig is. Meestal voldoen de standaard meegeleverde mogelijkheden niet en moet aanvullende functionaliteit geprogrammeerd worden. Vaak zal van de tester verwacht worden dat ook deze laag ingericht wordt. 17 TestKrant - Jaargang Editie 1

18 In meerdere contexten is vraag naar continue testen. Bij Agile om te zien of regressie optreedt naar aanleiding van nieuwe opleveringen, bij cloud om te monitoren of de leverancier zich aan zijn afspraken houdt, etc. De enige manier om continue (of in ieder geval frequente) testen goed uit te voeren, is door deze te automatiseren. Het nadenken over hoe dit te realiseren en het daadwerkelijk inrichten vraagt om kennis van architectuur, programmeren en testen. Conclusie De software die gemaakt wordt is steeds complexer. Dit vraagt niet alleen om meer technische kennis van ontwikkelaars, maar ook van testers. Van testers wordt steeds vaker verwacht dat zij kunnen programmeren (bij voorkeur in verschillende programmeertalen) en dat ze mee kunnen denken en discussiëren over de architectuur van de software. Bij het gebruik van de cloud is integratie met verschillende systemen nodig, waarbij het kunnen lezen van technische logging en het gebruik van drivers, stubs en mocks van de tester geëist wordt. Doordat bij Agile de tester dichter tegen de ontwikkelaar aanzit, zal ook de communicatie op een technischer niveau plaatsvinden. Daarnaast moet de tester bijblijven in de snel veranderende wereld, waar zowel Agile als cloud steeds vaker de standaard is. De enige manier om niet achter te raken, is het inzetten van testautomatisering. Hiervoor zullen ondersteunende tools niet alleen gebruikt, maar ook begrepen en ingericht moeten worden. Niet vreemd dus dat de vraag naar technische testers groeit. Blijf dus leren en verbreed je kennis, dan kunnen wij als test community voldoen aan deze vraag! Jeroen Mengerink werkt sinds 2008 bij Polteq en is testconsultant. Naast zijn werkzaamheden voor klanten is hij betrokken bij diverse testinnovaties. Jeroen is het eerste aanspreekpunt bij Agile--vraagstukken voor collega s en klanten. Hij is docent van een gevarieerd pakket aan testtrainingen, onder meer met onderwerpen als Agile, SOA en Cloud. Daarnaast ligt zijn persoonlijke interesse op het gebied van testautomatisering. Hij is een van de auteurs van het boek Cloutest over het testen van cloudservices. Ook is Jeroen regelmatig te zien als spreker op conferenties zoals onder andere Testnet, EuroStar en ChinaTest. [1] Meer info over Fitnesse kun je vinden op fitnesse.org/ [2] Meer info over Cucumber kun je vinden op https://github.com/cucumber/cucumber/wiki/ 18 TestKrant - Jaargang Editie 1

19 ISTQB Expert Level Verbeteren van het Testproces Door Erik van Veenendaal Met bijna certificaten is ISTQB veruit het meest succesvolle testopleidings- en certificatietraject in de wereld. Opvallend genoeg staat het kleine Nederland op de vijfde plaats betreffende het aantal certificaten. ISTQB is derhalve een de facto standaard geworden in onze testmarkt. Als we specifiek kijken naar Advanced level certificaten staat Nederland zelfs op de vierde plaats! Wij zijn derhalve mede koploper en veelal early adaptor, een goede reden om eens stil te staan bij de laatste nieuwe ontwikkeling: het derde ISTQB level c.q. het ISTQB Expert level en specifiek de syllabus Improving the Testing Process. In dit artikel een volledig overzicht van deze ISTQB syllabus, door sommige al het ISTQB kroonjuweel genoemd, en informatie over diverse gerelateerde zaken. 19 TestKrant - Jaargang Editie 1

20 ISTQB Expert Level status Laten we beginnen met het vaststellen van de huidige status van het ISTQB Expert level. Er schijnt nogal wat verwarring hieromtrent te bestaan in de (test-)markt. De ISTQB Expert level (EL) syllabus Improving the Testing Process is reeds volledig beschikbaar sinds oktober Ook de EL syllabus Test Manager is onlangs beschikbaar gekomen, inclusief een volledig proefexamen (beiden EL syllabi en het proefexamen zijn te downloaden van De Expert level syllabi Testautomatisering (verwacht najaar 2013) en Security Testen zijn momenteel in ontwikkeling. Ter ondersteuning van de syllabi zijn tevens diverse richtlijnen beschikbaar zoals bijvoorbeeld de EL examenrichtlijnen. Een aantal opleidingsbedrijven is momenteel druk bezig met het ontwikkelen van cursusmateriaal op basis van de nieuwe Expert level syllabus Improving the Testing Process, en exameninstituten zijn bezig met de ontwikkeling van EL examens. Ik verwacht dat de eerste EL Improving the Testing Process opleidingen aan het einde van dit jaar zullen worden geaccrediteerd. Om de implementatie van de syllabus en de deelnemers aan de opleiding te ondersteunen zijn Graham Bath en ik momenteel druk doende met het schrijven van een nieuw testboek op basis van deze syllabus. Kortom testers van Nederland, het ISTQB Expert level komt er aan! Wat is een expert? Ik weet dat veel testers, die het derde niveau bekijken en bestuderen, problemen hebben met het woord expert. Veel discussies gaan vervolgens over de vraag Wat is een expert?, en niet meer over de daadwerkelijke inhoud die wordt beschreven in de syllabus. Deze nieuwe syllabus heeft niet wereldwijd erkende testexperts zoals Martin Pol, Rex Black en Lee Copeland als doelgroep. Het heeft de testprofessionals, die veelal worden aangeduid als de lokale helden, als doelgroep. De medewerker in een organisatie waar je altijd terecht kunt als je een vraag hebt over testproces verbeteren; de persoon die het verbeterproces leidt in de organisatie of het project; de consultant die wordt ingehuurd voor het uitvoeren van het testproces assessment. Dat zijn voorbeelden van personen die veel meer behoren tot de doelgroep van de ISTQB EL syllabus. ISTQB definieert een expert als a person with special skills and knowledge representing mastery of a particular testing subject. [1] Een expert zijn betekent beschikken over en kunnen toepassen van gespecialiseerde kennis en vaardigheden verkregen tijdens opleidingen en vanuit praktijkervaring. Een testexpert is iemand die gedegen kennis en kunde heeft van testen in het algemeen, en diepgaande kennis en kunde in een specifiek testdomein, bijvoorbeeld testproces verbeteren. Diepgaande kennis en kunde betekent voldoende theoretische en praktijk bagage en daarmee in staat te zijn de richting een organisatie en/of project te beïnvloeden als het gaat om het ontwikkelen, implementeren of uitvoeren van activiteiten in het specifieke testdomein. Het is van belang te benadrukken dat, volgens ISTQB, een expert beschikt over zowel de theoretische kennis en de noodzakelijke vaardigheden om deze kennis toe te passen in praktijksituaties. Testers die volharden in de discussie of expert nu de juiste term is of niet, zijn veelal degene die theoretische beschouwingen leuk vinden en blijven hangen in de theorie. Praktijkmensen hebben het liever over de echte inhoud en de toegevoegde waarde die een syllabus voor hun werkzaamheden kan opleveren. Aan de lezer om te bepalen tot welke groep hij of zij behoort. Voor testers is van belang dat het derde niveau in het ISTQB opleidings- en certificatieschema is ontwikkeld en geïmplementeerd. Veel (test) certificatieschema s hebben drie niveau s beloofd in het verleden, maar nog nooit zijn deze beloften werkelijkheid geworden. ISTQB heeft het gedaan! Kortom testers van Nederland, het ISTQB Expert level komt er aan! De vraag of expert nu echt de beste term is, laat ik open en onbeantwoord. Echter, iemand die aan alle exit criteria van het Expert level voldoet zal een gedetailleerd en diepgaand begrip en grote praktische vaardigheden hebben op het gebied van testproces verbeteren. De exit criteria hebben niet slechts te maken met het slagen voor het examen (wat grotendeels zal bestaan uit open vragen), 20 TestKrant - Jaargang Editie 1

21 maar ook dient men minimaal vijf jaar testervaring te hebben en minimaal twee jaar ervaring op het gebied van testproces verbeteren. Er is zelfs een continu opleidingsproces gedefinieerd, implicerend dat degene die zichzelf op een gegeven moment expert mag noemen, dit niet automatisch mag doen voor de rest van zijn of haar leven. [2] Syllabus inhoud Wellicht goed om in het kort aan te geven wat nu echt aan bod komt in de syllabus en derhalve in de opleiding. In tegenstelling tot wat sommige denken, gaat het niet alleen over de testverbetermodellen zoals TPI-Next en TMMi. Uiteraard zijn deze modellen belangrijk maar is er veel meer te behandelen, leren en te bediscussiëren. In feite vind ik, dat (bijna) alles wat zou kunnen of dient te worden behandeld in de context van testverbeteren daadwerkelijk wordt behandeld. De syllabus geeft een nagenoeg volledig beeld van de state-of-thepractice ten aanzien van testproces verbeteren. Tezamen met Graham Bath, Isabel Evans en een groot aantal reviewers heb ik gewerkt aan wat volgens mij een zeer goede en gedegen syllabus is geworden. Context van verbeteren; een introductie waarin de deelnemer leert de noodzaak voor verbeteringen in het testproces te relateren aan de bedrijfsdoelstelling. Tevens wordt ingegaan op fundamentele concepten die veelal impliciet worden gebruikt bij verbetertrajecten zoals de visies van Garvin op productkwaliteit, de Deming cyclus en het EFQM raamwerk. Model gebaseerd verbeteren; een groot gedeelte van de opleiding wordt besteed aan de beschikbare modellen (o.a. CMMI, ISO 15504, TPI-Next, TMMi). Niet slechts vanuit het theoretisch perspectief, maar met name gericht op het toepassen van de modellen (zie ook werkplek opdrachten hierna). Ook de sterke en zwakke punten van de verschillende modellen worden behandeld. Analytisch gebaseerd verbeteren; veelal vergeten maar in aanvulling op de raamwerk modellen (vaak toegepast in een top-down benadering), kunnen bottom-up benaderingen wordt gebruikt. Vaak zijn deze in hoge mate 21 TestKrant - Jaargang Editie 1

22 effectief en efficiënt. Causale analyse, inspecties, foutpreventieprogramma s en GQM gebaseerde meetprogramma s worden in detail behandeld als onderdeel van analytisch gebaseerd verbeteren. Selecteren verbeteraanpak; het is van het grootste belang dat de deelnemers in staat zijn de verschillende aanpakken en benaderingen te vergelijken en diegene te kunnen selecteren die het beste past en de meeste toegevoegde waarde heeft binnen zijn/haar organisatie. Verbeterproces; veel aandacht wordt gegeven aan het verbeterproces zelf. Persoonlijk denk ik dat het verbeterproces plus aandacht voor veranderingsmanagement minstens zo belangrijk is als de keuze voor het juiste' model. Het verbeterproces dat wordt behandeld is gebaseerd op het door het Software Engineering Institute (SEI) ontwikkelde IDEAL verbeterproces. Uitvoerig wordt stil gestaan bij het analyseren van de huidige situatie en het uitvoeren van testproces assessments. Organisatie, rollen, kennis en kunde; de rol, vooren nadelen en opzet van een Test Proces Groep (TPG) worden besproken, evenals hoe om te gaan met testverbeteren in een situatie waarin testen remote, off-shore of zelfs outsourced plaats vindt. Een groot gedeelte binnen dit onderwerp gaat echter over die communicatieve en sociale vaardigheden die nodig zijn om een testverbeterprogramma te kunnen leiden en om succesvol een assessment uit te kunnen voeren. Veranderingsmanagement; testproces verbeteren gaat feitelijk om het veranderen van het gedrag van mensen en gaat dus ook over veranderingsmanagement. Alhoewel dit een onderwerp is dat op zich al genoeg omvat om te leiden tot een afzonderlijke Expert level module, komt dit belangrijke onderwerp ook ruimschoots aan bod in deze syllabus. Kritische succes factoren; het niet maken van de fouten die anderen reeds hebben gemaakt. Een lijst van kritische succes factoren wordt behandeld, gebaseerd op de praktijkervaringen van de auteurs en reviewers. Daarnaast wordt stil gestaan bij het test proces verbeter manifesto [3] als een mogelijke wijze om de verschillende kritische succes factoren in context te kunnen plaatsen. Aanpassen aan verschillende ontwikkelmodellen; testverbeteren in agile en iteratieve ontwikkelomgevingen wordt besproken en gepresenteerd. Middels voorbeelden wordt aangegeven hoe testverbetermodellen dienen te worden aangepast en toegepast om bruikbaar te zijn voor agile en/of interatieve ontwikkel-omgevingen. Werkplekopdrachten Zoals mag worden verwacht van een opleiding op dit niveau, is de primaire focus gericht op praktische oefeningen. Tijdens de Expert level opleiding, die op basis van deze syllabus 6 dagen duurt, wordt meer dan 60% besteed aan oefeningen en meningsvormende discussiesessies. Een heel interessant concept dat wordt toepast om er voor te zorgen dat deelnemers daadwerkelijk praktijkgerichte kunde verkrijgen, en niet slechts hebben geoefend met niet praktijk representatieve oefeningen, zijn de werkplekopdrachten. Van deelnemers wordt verwacht dat ze opdrachten uitvoeren in hun organisatie en daarover terugrapporteren in de opleiding. Als gevolg hiervan zal er ook communicatie tussen de docent en de deelnemer zijn buiten de opleidingsdagen, om vragen te beantwoorden en voortgang te bespreken. Dit betekent uiteraard mede dat de opleidingsdagen typisch zullen worden uitgespreid over een langere periode en niet aansluitend kunnen plaatsvinden. Voorbeelden van opdrachten op de werkplak zijn o.a.: Beoordelen van een testorganisatie ten opzichte van het TPI-Next of TMMi model Plannen en uitvoeren van assessment interviews Opstellen en presenteren van de samenvattende conclusie en bevindingen op basis van een uitgevoerd assessment Formuleren van aanbevelingen en actiepunten op het gebied van testprocesverbeteren op basis van de assessment resultaten en de uitgevoerde analyse Opstellen van een testverbeterplan (inclusief relevante stappen en acties) met in achtneming van veranderingsmanagement aspecten Evalueren van de kritische succes factoren bij een testverbeterproject 22 TestKrant - Jaargang Editie 1

23 Ik ben er persoonlijk van overtuigd dat het ISTQB Expert level in ruime mate van toegevoegde waarde zal zijn voor het testvak. Lokale helden met een interesse in testprocesverbeteren zullen in de opleiding op basis van deze nieuwe ISTQB syllabus hun kennis en kunde verder ontwikkelen. Het gaat om de praktijk, het ontwikkelen van praktische vaardigheden en niet slechts over theorie. Dit is hopelijk door middel van dit artikel in voldoende mate duidelijk gemaakt. De eerste Expert level syllabi zijn beschikbaar, dit is niet het einde, maar slechts een begin maar een mooie volgende stap. Het testvak neemt een volgende stap op weg naar volwassenheid. [1] Expert Level Modules Overview, V1.0 (2011), International Software Testing Qualifications Board [2] ISTQB Certified Tester Expert Level Certification Extension Policy, V1.0 (2008), International Software Testing Qualifications Board [3] E. van Veenendaal, Test Improvement Manifesto, in: Testing Experience, Issue 04/08, December 2008 Erik van Veenendaal is de oprichter van Improve Quality Services BV, een gespecialiseerde organisatie op het gebied van testen en kwaliteitsmanagement. Hij is internationaal erkend testexpert en auteur van diverse boeken en een groot aantal artikelen binnen het vakgebied. Hij is tevens één van de ontwikkelaars van de TMap testmethodiek en het TMMi test improvement model. Erik was vice-president van de International Software Testing Qualifications Board (ISTQB) van , één van de auteur van de Expert level syllabus Improving the Testing Process en is momenteel vice-chair van de TMMi Foundation. Hij is regelmatig keynote en tutorial spreker op internationale (test)conferenties en ontving in 2007 de European Testing Excellence Award voor zijn bijzondere bijdrage aan de ontwikkeling van het testvakgebied. Erik is bereikbaar via twitter #erikvveenendaal en via zijn website 23 TestKrant - Jaargang Editie 1

TESTKRANT MAGAZINE VOOR DE NEDERLANDSE TESTER

TESTKRANT MAGAZINE VOOR DE NEDERLANDSE TESTER TESTKRANT MAGAZINE VOOR DE NEDERLANDSE TESTER Visual management binnen de testafdeling Meer resultaat en plezier met Kanban Derk-Jan de Grood En ook artikelen van Erik van Veenendaal Jeroen Mengerink Bryan

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

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

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

TestNet Voorjaarsevenement 2010 Jurian van de Laar 12 mei 2010 info@improveqs.nl

TestNet Voorjaarsevenement 2010 Jurian van de Laar 12 mei 2010 info@improveqs.nl Testers helpen ontwikkelaars of andersom? TestNet Voorjaarsevenement 2010 Jurian van de Laar 12 mei 2010 info@improveqs.nl Improve Quality Services B.V. 2 Agenda Hoe veilig is een muur? Past Scrum ook

Nadere informatie

Agile Testen in de praktijk

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

Nadere informatie

BDD/Gherkin. Een introductie

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

Nadere informatie

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

Scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum agileagileagileagileagileagileagileagil

Scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum agileagileagileagileagileagileagileagil Scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum agileagileagileagileagileagileagileagil eagileagileagileagileagileagileagileagi leagileagileagileagileagileagileagileag

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

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

Factsheet CONTINUOUS VALUE DELIVERY Mirabeau

Factsheet CONTINUOUS VALUE DELIVERY Mirabeau Factsheet CONTINUOUS VALUE DELIVERY Mirabeau CONTINUOUS VALUE DELIVERY We zorgen ervoor dat u in elke volwassenheidsfase van uw digitale platform snel en continu waarde kunt toevoegen voor eindgebruikers.

Nadere informatie

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

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

Nadere informatie

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

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

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

Expert level Improving the testing process

Expert level Improving the testing process Expert level Improving the testing process Eerste praktijkervaringen Smaakmaker voor najaarsevent www.improveqs.nl (info@improveqs.nl) Eduard Hartog Isabelle Robrechts Version 1.1 Agenda Opbouw training

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

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

Adding value to test tooling Hoe en waarom DevOps de wereld van performance testen verandert

Adding value to test tooling Hoe en waarom DevOps de wereld van performance testen verandert Hoe en waarom DevOps de wereld van performance testen verandert Najaarsevenement 14 oktober 2015 Inleiding Wie zijn we Marc Koper: Specialist in performancetesten / testautomatisering HenkJaap van den

Nadere informatie

Verzamelde vragen en antwoorden Agile Applicatie ontwikkeling. Agile Methodiek en Technologie. Zest Application Professionals

Verzamelde vragen en antwoorden Agile Applicatie ontwikkeling. Agile Methodiek en Technologie. Zest Application Professionals Verzamelde vragen en antwoorden Agile Applicatie ontwikkeling Agile Methodiek en Technologie Zest Application Professionals Hoe is de aansluiting op ontwikkelmethoden voor Legacy-systemen? Out of the Box

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

ERP Testing. HP Nijhof. Testmanager. Testnet November 2005

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

Nadere informatie

WHITEPAPER IN 5 MINUTEN. 11. Scrum

WHITEPAPER IN 5 MINUTEN. 11. Scrum WHITEPAPER IN 5 MINUTEN A U G U S T U S 2 0 1 4 11. Scrum Deze whitepaper gaat over Scrum. Kort en bondig: Scrum is een software-ontwikkelmethode met vaste sprints van enkele weken waarin steeds een verbeterde

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

Leer/werk trajecten voor ICT professionals

Leer/werk trajecten voor ICT professionals Leer/werk trajecten voor ICT professionals Baanrecord De leer/werk trajecten zijn gericht op de huidige vraag in de ICT naar hoogwaardige professionals. In het huidige arbeidsklimaat is het noodzakelijk

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

Scrum. Een introductie

Scrum. Een introductie Organisatie SYSQA B.V. Pagina 1 van 10 Scrum Een introductie Almere 1999 Proud of it Pagina 1 van 10 Organisatie SYSQA B.V. Pagina 2 van 10 Inhoudsopgave 1 Inleiding... 3 2 Scrum... 4 3 Scrum rollen...

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

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

CURRICULUM VITAE. David Krosse. Personalia Naam Geboortedatum Woonplaats Geslacht Nationaliteit

CURRICULUM VITAE. David Krosse. Personalia Naam Geboortedatum Woonplaats Geslacht Nationaliteit CURRICULUM VITAE David Krosse Personalia Naam Geboortedatum Woonplaats Geslacht Nationaliteit 8 augustus 80 Arnhem Man Nederlands Profiel Ik ben een gedreven testmanager met 0 jaar ervaring in het test

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

Agile werken: zó doen we dat

Agile werken: zó doen we dat Agile werken: zó doen we dat Bij Freshheads werken we graag volgens de Agile aanpak. De voordelen? Verhoogde efficiëntie en flexibiliteit, snellere resultaten en grotere betrokkenheid. Maar hoe gaat het

Nadere informatie

Agile Beheer: Mythe of werkelijkheid? Odile Moreau BlinkLane Consulting NIOC 2013 - Arnhem, 5 april 2013

Agile Beheer: Mythe of werkelijkheid? Odile Moreau BlinkLane Consulting NIOC 2013 - Arnhem, 5 april 2013 Agile Beheer: Mythe of werkelijkheid? Odile Moreau BlinkLane Consulting NIOC 2013 - Arnhem, 5 april 2013 Achtergrond 2 Agile methoden zijn al een tijd heel populair geworden Zoals Scrum voor software ontwikkeling

Nadere informatie

Verandermanagement: Business as Usual

Verandermanagement: Business as Usual Verandermanagement: Samenvatting Voor organisaties is het inmiddels een vast gegeven dat hun processen en producten continue zullen moeten veranderen om zich te kunnen handhaven in een omgeving waar we

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

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

Offshoring & Testing. Verander een uitdaging in een kans. Door Ernst Labruyère. re Consultant ps_testware. 20 september 2007

Offshoring & Testing. Verander een uitdaging in een kans. Door Ernst Labruyère. re Consultant ps_testware. 20 september 2007 Offshoring & Testing Verander een uitdaging in een kans Door Ernst Labruyère re Consultant ps_testware 20 september 2007 Ernst Labruyere- Offshoring en Testing: : Verander een uitdaging in een kans - 1

Nadere informatie

Titel, samenvatting en biografie

Titel, samenvatting en biografie Titel, samenvatting en biografie \ Peter Wanders De Black Box Dialog methode Voorjaarsevent Testnet: 22 juni 2009 Samenvatting Nog nooit heb ik heb een klant horen zeggen: Enorm vervelend dat het IT project

Nadere informatie

WHITE PAPER. Agile/Scrum

WHITE PAPER. Agile/Scrum WHITE PAPER Agile/Scrum Belangrijkste kenmerk van Scrum is de ontwikkeling via een serie van korte - iteraties, in Scrum terminologie sprints genoemd. Introductie Heel in het kort gezegd is Scrum een Agile

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

Testverbetering met TMM bij Philips

Testverbetering met TMM bij Philips Testverbetering met TMM bij Philips Medical Systems Cardio/Vascular Jurian van de Laar Improve Quality Services Wim van Rooij Philips Medical Systems Philips Medical Systems C/V Imaging Systems X-Ray Cardio/Vascular

Nadere informatie

Agile ervaring Ir.ing. Erik van Daalen

Agile ervaring Ir.ing. Erik van Daalen Agile ervaring Ir.ing. Erik van Daalen Eneco Rotterdam 3 december 2013 03-12-2013 Agile Erik van Daalen 1 Hoofdsponsor Sponsors IPMA-N Jaarsponsors 03-12-2013 Agile Erik van Daalen 2 Korte introductie

Nadere informatie

Anand T hakur. Over Anand

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

Nadere informatie

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

Literatuur Projectmatig Werken

Literatuur Projectmatig Werken Literatuur Projectmatig Werken Onderstaande boeken behandelen de meest gebruikte methodieken van projectmatig werken. Prince 2 is vooral voor ICT-projecten geschikt. Overheden kiezen vaak voor een bepaalde

Nadere informatie

Vijf jaar agile. Hosanna of Drama?

Vijf jaar agile. Hosanna of Drama? Vijf jaar agile. Hosanna of Drama? Leo van der Aalst Fontys Hogeschool ICT, Sogeti In dit artikel wordt een top vijf van vier onderwerpen op het terrein van agile werken geschetst: vijf agile misvattingen,

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

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

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

Nadere informatie

Agile Consortium International Agile Master Assessment

Agile Consortium International Agile Master Assessment Agile Consortium International Agile Master Assessment Agile Master Assessment Info & Criteria Page 1 of 5 Version 1.0 Wat is het Agile Master Certificaat Het Agile Master Certificaat is een bewijs van

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

Lean trainingen. De trainingen gefaciliteerd door 12Mprove worden momenteel gemiddeld beoordeeld met een 9,4.

Lean trainingen. De trainingen gefaciliteerd door 12Mprove worden momenteel gemiddeld beoordeeld met een 9,4. Lean trainingen De trainingen zitten vol met actiegericht leren. Geen powerpoint - trainingen, maar met veel gebruik van flip- overs en tekeningen. Deze trainingen verzorgen wij samen met onze samenwerkingspartner

Nadere informatie

JIRA Handleiding. info@techtwo.nl www.techtwo.nl. Techtwo Internetdiensten Reduitlaan 29 4814DC Breda 076 532 2961

JIRA Handleiding. info@techtwo.nl www.techtwo.nl. Techtwo Internetdiensten Reduitlaan 29 4814DC Breda 076 532 2961 JIRA Handleiding Techtwo Internetdiensten Reduitlaan 29 4814DC Breda 076 532 2961 info@techtwo.nl www.techtwo.nl KvK West-Brabant: 20148962 BTW nummer: NL8203.67.990 Bank NL54RABO01304.58.406 Wat is JIRA

Nadere informatie

Kwaliteit in Agile: een gegeven?

Kwaliteit in Agile: een gegeven? QA in Agile: waste? Kwaliteit in Agile: een gegeven? Een praktijkvoorbeeld Arno Balemans senior Quality Assurance consultant Bussum, 29 september 2015 Kwaliteit in Agile 2015 2 Werkzaamheden In mijn opdrachten:

Nadere informatie

Christian Hoppenbrouwers Tools voor offshore testen Voorjaarsevent Testnet: 30 juni 2008

Christian Hoppenbrouwers Tools voor offshore testen Voorjaarsevent Testnet: 30 juni 2008 Titel, samenvatting en biografie Samenvatting: Christian Hoppenbrouwers Tools voor offshore testen Voorjaarsevent Testnet: 30 juni 2008 Steeds meer bedrijven offshoren hun IT activiteiten naar landen als

Nadere informatie

VERENIGINGSWIJZER.NL FINAL DOCUMENT

VERENIGINGSWIJZER.NL FINAL DOCUMENT Vrije Universiteit Amsterdam Faculteit der Exacte Wetenschappen Project Multimedia Peter van Ulden Studentnr. 1494759 VERENIGINGSWIJZER.NL FINAL DOCUMENT INHOUDSOPGAVE 1 Inleiding...3 2 Aanpak & Techniek...4

Nadere informatie

Agile systeemontwikkeling. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

Agile systeemontwikkeling. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. Agile systeemontwikkeling Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 10 Inhoudsopgave 1. Inleiding... 3 2. Terminologie... 4 3. Uitgangspunten...

Nadere informatie

CMM 3: levert het wat op?

CMM 3: levert het wat op? CMM 3: levert het wat op? Philips Analytical De noodzaak en voordelen van Software Process Improvement Wie is Philips Analytical? Waarom is voor ons software proces verbetering zo essentieel? Hoe hebben

Nadere informatie

Atos Origin bouwt betere software in minder tijd

Atos Origin bouwt betere software in minder tijd Atos Origin bouwt betere software in minder tijd De tijdige beslissing van Atos Origin om te investeren in Microsoft Visual Studio Team System leidt tot een beter geïntegreerde ontwikkelstraat. Lees hoe

Nadere informatie

your reference in testing services WorkShop Agile in de praktijk - Erik Boelen - 18 december 2008

your reference in testing services WorkShop Agile in de praktijk - Erik Boelen - 18 december 2008 your reference in testing services WorkShop Agile in de praktijk - Erik Boelen - 18 december 2008 Onderwerpen vandaag Geen theoretische achtergrond Gebaseerd op eigen praktijk Niet uit boeken te halen

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

Software Quality Assurance Plan

Software Quality Assurance Plan FACULTEIT WETENSCHAPPEN Software Quality Assurance Plan Software Engineering groep 3 Jeroen Van den haute Versie Datum Auteur Commentaar 0.1 09/11/2010 Jeroen Van den haute Eerste versie 0.2 12/11/2010

Nadere informatie

Testomgevingen beheer

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

Nadere informatie

Handout. Pagina 1. SYSQA B.V. Almere. Capability Maturity Model Integration (CMMI) Technische Universiteit Eindhoven SYSQA SYSQA.

Handout. Pagina 1. SYSQA B.V. Almere. Capability Maturity Model Integration (CMMI) Technische Universiteit Eindhoven SYSQA SYSQA. Capability Maturity Model Integration (CMMI) Technische Universiteit Eindhoven Johan Zandhuis SYSQA Start: 1999 Onafhankelijk Quality Assurance in IT 150 medewerkers (en groeiend) 2 SYSQA Operationeel

Nadere informatie

6. Project management

6. Project management 6. Project management Studentenversie Inleiding 1. Het proces van project management 2. Risico management "Project management gaat over het stellen van duidelijke doelen en het managen van tijd, materiaal,

Nadere informatie

Plan van Aanpak. project Tetris Packing

Plan van Aanpak. project Tetris Packing Plan van Aanpak project Tetris Packing Inleiding! 4 Projectomschrijving! 5 Producten! 5 Testplan! 5 Ontwerprapport! 5 Implementatierapport! 5 Testrapport! 5 Systeemdocumentatie! 5 Aanpak! 6 Projectmethodiek!

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

PLANET AGILE 17E BPUG SEMINAR

PLANET AGILE 17E BPUG SEMINAR PLANET AGILE 17E BPUG SEMINAR. Lean toegepast op PRINCE2 Projectmanagement is waste (maar noodzakelijk) Martin van Borselaer Mens-, organisatie- en procesverbeteraar Projectmanager/verandermanager & coach

Nadere informatie

Het CIBG ervaart een hogere kwaliteit met applicatie-ontwikkeling in Microsoft Visual Studio 2010

Het CIBG ervaart een hogere kwaliteit met applicatie-ontwikkeling in Microsoft Visual Studio 2010 Het CIBG ervaart een hogere kwaliteit met applicatie-ontwikkeling in Microsoft Visual Studio 2010 Organisatie Het CIBG is een uitvoeringsorganisatie van het ministerie van Volksgezondheid, Welzijn en Sport.

Nadere informatie

Advies. Advies over en ondersteuning bij het (initieel) inrichten/optimaliseren van de structuur van de(it Service Management)organisatie

Advies. Advies over en ondersteuning bij het (initieel) inrichten/optimaliseren van de structuur van de(it Service Management)organisatie DIENST Advies over en ondersteuning bij het (initieel) inrichten/optimaliseren van de structuur van de(it Service Management)organisatie Advies over en ondersteuning bij het initieel inrichten/optimaliseren

Nadere informatie

Testen = Monitoren. Hoe de werkzaamheden van de boodschapper van de koning gaan veranderen. Datum: 30 April 2015

Testen = Monitoren. Hoe de werkzaamheden van de boodschapper van de koning gaan veranderen. Datum: 30 April 2015 Testen = Monitoren Hoe de werkzaamheden van de boodschapper van de koning gaan veranderen. Spreker: Ide Koops Datum: 30 April 2015 1 2 Agenda Testrapportages in het verleden Impact nieuwe ontwikkelingen

Nadere informatie

Tips & Tricks: Tip van de maand januari 2009

Tips & Tricks: Tip van de maand januari 2009 Tips & Tricks: Tip van de maand januari 2009 Project Management met Teamcenter 2007 Door: Ramon van Raak Beheert u complexe projecten dan weet u als geen ander dat de projectvoorbereiding de basis legt

Nadere informatie

De kracht van een sociale organisatie

De kracht van een sociale organisatie De kracht van een sociale organisatie De toegevoegde waarde van zakelijke sociale oplossingen Maarten Verstraeten. www.netvlies.nl Prinsenkade 7 T 076 530 25 25 E mverstraeten@netvlies.nl 4811 VB Breda

Nadere informatie

TestNet Voorjaarsevenement 2010 Jurian van de Laar 12 mei 2010 info@improveqs.nl

TestNet Voorjaarsevenement 2010 Jurian van de Laar 12 mei 2010 info@improveqs.nl Testers helpen ontwikkelaars of andersom? TestNet Voorjaarsevenement 2010 Jurian van de Laar 12 mei 2010 info@improveqs.nl Improve Quality Services B.V. 2 Agenda Hoe veilig is een muur? Past Scrum ook

Nadere informatie

Quality Gates: De overdracht tussen ontwikkelaars en testers geregeld

Quality Gates: De overdracht tussen ontwikkelaars en testers geregeld Quality Gates: De overdracht tussen ontwikkelaars en testers geregeld Rik Marselis Senior Testadviseur Logica 2008. All rights reserved Even voorstellen: Rik Marselis Senior Testadviseur ruim 27 jaar IT

Nadere informatie

Procesgerichte IT BPM de link tussen bedrijf en IT

Procesgerichte IT BPM de link tussen bedrijf en IT 24 november 2010 Procesgerichte IT BPM de link tussen bedrijf en IT ir. Martin R. Meijer senior BPM/EAI consultant Agenda Business Process Management, een historisch overzicht BPM als bindmiddel geschikte

Nadere informatie

Process & IT: eerst KIEZEN maakt het DOEN daarna zoveel makkelijker

Process & IT: eerst KIEZEN maakt het DOEN daarna zoveel makkelijker Process & IT: eerst KIEZEN maakt het DOEN daarna zoveel makkelijker Wim Tindemans Manager Business Applications Business and Automation Solutions Egemin NV Agenda Probleemstelling Tegenstelling tussen

Nadere informatie

Georges Dockx JUISTE MARKETING. Voor kmo s en zelfstandigen die meer resultaat willen met minder budget

Georges Dockx JUISTE MARKETING. Voor kmo s en zelfstandigen die meer resultaat willen met minder budget Georges Dockx DE JUISTE MARKETING Voor kmo s en zelfstandigen die meer resultaat willen met minder budget Uitgegeven door Georges Dockx in samenwerking met BOEK MAKERIJ.be D/2015/Georges Dockx, auteur-uitgever

Nadere informatie

LSSN seminar Amsterdam 01-11-2012 Edwin Kippers Master Black Belt. Project Management

LSSN seminar Amsterdam 01-11-2012 Edwin Kippers Master Black Belt. Project Management Lean Six Sigma Scrum Niet alleen voor software projecten LSSN seminar Amsterdam 01-11-2012 Edwin Kippers Master Black Belt Project Management Project succes survey The Standish Group's report: "CHAOS Summary

Nadere informatie

RUM. requirements Management. SPIder session Project. driven by requirements 25th april. Risk assessed User

RUM. requirements Management. SPIder session Project. driven by requirements 25th april. Risk assessed User RUM Risk assessed User requirements Management - SPIder session Project driven by requirements 25th april Copyright 2006 ps_testware - Gijs Kuiper Risk assessed User requirement Management Personalia Gijs

Nadere informatie

Wees in control over uw digitale landschap

Wees in control over uw digitale landschap Managed Services Managed Services We zorgen ervoor dat uw complete beheerketen soepel functioneert, zodat uw eindgebruikers optimaal worden bediend. Zorgenvrij beheer is cruciaal voor de continuïteit van

Nadere informatie

VOICE OF THE CUSTOMER

VOICE OF THE CUSTOMER 4/20/ E-BOOK VOICE OF THE CUSTOMER Gratis e-book leansixsigmatools.nl Introductie Bij Six Sigma staat het denken vanuit de behoeften van de klant centraal. Juist de vertaling van de stem(men) van de klant(en)

Nadere informatie

NIEUW: - ISTQB Agile Tester Extension - CMAP Mobile App Testing - Testen van mobiele apps in de praktijk

NIEUW: - ISTQB Agile Tester Extension - CMAP Mobile App Testing - Testen van mobiele apps in de praktijk Polteq Testopleidingen 2014-2015 NIEUW: - ISTQB Agile Tester Extension - CMAP Mobile App Testing - Testen van mobiele apps in de praktijk ISTQB Foundation ISTQB Advanced TMap Next Test Engineer TMap Next

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

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

SMART requirements schrijven

SMART requirements schrijven SMART requirements schrijven Reverse Engineering als aanpak voor leren Requirements Kenniscentrum 27 maart 2012, 18:50 19:30 uur Hossein Chamani, docent en trainer bij Hogeschool Rotterdam 1 Introductie

Nadere informatie

Effectief testen in complexe omgeving 20-8-2012

Effectief testen in complexe omgeving 20-8-2012 Effectief testen in complexe omgeving 20-8-2012 How it came to be 20-8-2012 2 Indeling Wie ben ik? Wat doet TASS? Beschrijving ontwikkelgroepen Voor SCRUM Implementatie SCRUM Gerealiseerde verbeteringen

Nadere informatie

TESTEN IN DE LOGISTIEKE E-COMMERCEKETEN

TESTEN IN DE LOGISTIEKE E-COMMERCEKETEN TESTEN IN DE LOGISTIEKE E-COMMERCEKETEN Productinformatie Testen in de logistieke e-commerceketen Inhoudsopgave 1 Waarom testen in de logistieke e-commerceketen?... 4 1.1 Verschillende klantperspectieven...

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

Software Engineering (I00094) College 3:

Software Engineering (I00094) College 3: Software Engineering (I00094) College 3: Kwaliteit, organisatie en documentatie Marko van Eekelen marko@cs.ru.nl kamer HG02.074 1 Huidige planning 1. 6 feb: Het systeemontwikkelproces 2. 13 feb: Requirements-analyse

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

Agile in Projecten minimalisme of strak pak? Richard Weber PMP

Agile in Projecten minimalisme of strak pak? Richard Weber PMP Agile in Projecten minimalisme of strak pak? Richard Weber PMP De Spreker Richard Weber Directeur & oprichter Adviseur & coach Projectmanagement Profile Dynamics ICT & Bedrijfskundige achtergrond Trainer

Nadere informatie

EXIN Agile Scrum Foundation

EXIN Agile Scrum Foundation Voorbeeldexamen EXIN Agile Scrum Foundation Editie april 2014 Copyright 2014 EXIN All rights reserved. No part of this publication may be published, reproduced, copied or stored in a data processing system

Nadere informatie

Bekend zijn met de visie en inzet van procesmanagement in de eigen organisatie.

Bekend zijn met de visie en inzet van procesmanagement in de eigen organisatie. en werkwijze BPM awareness Inzicht in de toepassing van BPM op strategisch niveau in het algemeen en binnen de eigen organisatie. Kennismaken met BPM vanuit een strategisch perspectief Nut en toegevoegde

Nadere informatie

Functieprofiel Young Expert

Functieprofiel Young Expert 1 Laatst gewijzigd: 20-7-2015 Inhoudsopgave Inhoudsopgave... 2 1 Ervaringen opdoen... 3 1.1 Internationale ervaring in Ontwikkelingssamenwerkingsproject (OS)... 3 1.2 Nieuwe vaardigheden... 3 1.3 Intercultureel

Nadere informatie

PROJECT: ONTWIKKELOMGEVINGEN VIRTUELE TESTOMGEVINGEN

PROJECT: ONTWIKKELOMGEVINGEN VIRTUELE TESTOMGEVINGEN PROJECT: ONTWIKKELOMGEVINGEN VIRTUELE TESTOMGEVINGEN ( Project Initiation Document ) Datum voltooid: 20/03/2013 Auteur: Kevin Sanders Studentnummer: 2148839 Versie: 0.1 Status: Concept Documenthistorie

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

C.A.S.T. Make it as simple as possible, but not simpler. Make IT as simple as possible, but not simpler. Complexiteit. Einstein maakte het simpel

C.A.S.T. Make it as simple as possible, but not simpler. Make IT as simple as possible, but not simpler. Complexiteit. Einstein maakte het simpel Geautomatiseerd Testen Complexiteit Valori Meeting of Minds, 28 juni 2011 1 2 Einstein maakte het simpel Make it as simple as possible, but not simpler (Einstein) 3 4 Waar staat dit voor? Make IT as simple

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