Testen2.1 Ordina s visie op Agile testen door Eric Jimmink, Anko Tijman, en vele anderen. illustraties: Waldemar van den Hof

Maat: px
Weergave met pagina beginnen:

Download "Testen2.1 Ordina s visie op Agile testen door Eric Jimmink, Anko Tijman, en vele anderen. illustraties: Waldemar van den Hof"

Transcriptie

1 Testen2.1 Ordina s visie op Agile testen door Eric Jimmink, Anko Tijman, en vele anderen. illustraties: Waldemar van den Hof Inleiding In deze tekst staat in het kort, welke visie Ordina heeft op Agile testen, en wat de ervaringen zijn bij het in praktijk brengen van die visie. In het derde jaar na het uitbrengen van Testen2.0 is het logischerwijs tijd voor Testen2.1! Waar in 2.0 bewust de focus werd gelegd op de Agile mindset en de achtergronden van de Agile methodieken, is 2.1 meer concreet gericht op implementatie in projecten. Leeswijzer Globaal is dit boekje opgebouwd uit 4 delen: 1. Testen2.1 - De visie / methodische beschrijving 2. Teamwork2.1 - De praktische invulling van de samenwerking, en voorbeelden van het gebruik van Tools 3. Testen2.1 zonder het label Agile - Toepassen van Agile testen in projecten 4. Groeien naar Testen2.1 - Het implementatietraject voor een organisatie Aan het einde staan geen Templates en Quick Reference Cards. Wel locaties waar dergelijke documenten kunnen worden gedownload, want we geloven wel in het delen van kennis met de community. Tot besluit een aantal nuttige links, referenties, en een woordenlijst. DEEL 1: Testen2.1 De visie op Agile testen Heel in het kort houdt effectief Agile werken in, dat alle werkzaamheden die nodig zijn om te komen werkende (geteste!) software, in een zo kort mogelijk tijdsbestek moet worden uitgevoerd. Aan de hand van een overzichtplaatje wordt nader toegelicht, hoe het multidisciplinaire team het werk en daarmee het testen invult. Vroeg en multidisciplinair testen De business vraagt om een proces voor de totstandkoming van software waarbij ze tussentijds sturing kan geven aan het resultaat op basis van voortschrijdend inzicht, en de time-to-market wordt verkort. In dat licht is zo vroeg mogelijk testen een vereiste. Immers, snelle feedback kan veel dubbel werk vermijden. Bovendien wordt daarmee het testen van het kritieke pad van het project af gehaald. Testen wordt nadrukkelijk multidisciplinair: enerzijds omdat de feedback op alle terreinen moet worden gegeven (requirements, code, functioneel en overig applicatiegedrag), anderzijds omdat het gehele team interactie heeft met de klant en feedback op elkaars werk moet leveren om een gezamenlijk doel te behalen. In één plaatje tonen we de belangrijkste testactiviteiten die het multidisciplinaire team doet om kwalitatief hoogwaardige software te realiseren:

2 Acceptance TDD / Specificatie met voorbeelden De klant staat nadrukkelijk aan het roer, en heeft een belangrijke taak om het multidisciplinaire team te faciliteren bij de beeldvorming. Doelstelling moet zijn dat het team in staat wordt gesteld om in één keer het juiste product te maken voor de business. De ATDD cyclus omvat 4 stappen ( Discuss - Distill - Develop - Demo ), die herhaaldelijk worden doorlopen: 1. Bespreken. De eerste formulering van een user story ( requirement) roept doorgaans vragen op bij het team. Wat is bijvoorbeeld de intentie van de opdrachtgever, de achterliggende vraag van de business? Verder zal het team vragen hebben over een mogelijke invulling van de vraag; wanneer is het goed genoeg? 2. Distilleren. Uit de discussie komen voorbeelden naar voren, welke waar mogelijk één op één vertaald kunnen worden naar geautomatiseerde tests (checks). Die testen zijn slechts checks: een vaste tabel met uitgangssituaties, acties, en verwachte uitkomsten. 3. Bouwen. Het team gaat het onderdeel van het product vervolgens bouwen en daarbij zorg dragen dat alle checks groen zijn bij de demo. 4. Demonstreren. Het behaalde resultaat wordt getoond aan de opdrachtgever. Er wordt feedback gegeven, en indien akkoord gaat het team door met het Bespreken van de volgende user story. De term 'Demonstreren' klinkt wellicht alsof er op dat moment formele acceptatie plaats vindt. En soms zal dat ook zo zijn, wanneer de demo wordt uitgevoerd in het kader van een oplevering van een iteratie. De cyclus kan ook meermalen worden doorlopen gedurende een iteratie; dan zal er meer sprake zijn van informele acceptatie op de demo-momenten. Als een team goed loopt en de klant veelvuldig of

3 doorlopend betrokken is bij het proces, dan is de gewenste vorm van samenwerking er een, waarbij er sprake is van continue acceptatie. Bij de klantorganisatie zijn doorgaans functioneel beheerders en eindgebruikers betrokken bij het proces van formele acceptatie van het eindproduct. Wanneer die gebruikers niet de tijd hebben gehad om het product te zien groeien, dan is er een groot risico voor het project, dat het niet direct verkrijgen van de handtekening leidt tot vertraging van het project als geheel. De emotionele acceptatie gaat veel vloeiender als de gebruikers tussentijds het product hebben gezien, er wellicht mee hebben gewerkt, en een deel van hun feedback / wensen verwerkt zien in het eindresultaat. De formele acceptatie wordt daarmee gereduceerd tot een formaliteit, en is zo van het kritieke pad af. Aan het begin van een project zijn veelal niet alle namen bekend van de personen die namens de business betrokken moeten worden (of: willen worden) bij het acceptatieproces. Ook is het vooraf moeilijk in te schatten hoeveel tijd die opgetrommelde testers daadwerkelijk vrij kunnen maken voor het project. Geef het proces daarom wat tijd: nodig eindgebruikers uit voor de demo aan het einde van een iteratie, en geef ze de tijd om even te spelen met de applicatie. Na ongeveer 3 iteraties ontstaat er dan een vaste kern van enthousiaste mensen, die erbij blijven voor de rest van het traject. Anticipeer erop dat minstens een derde van de mensen afhaakt in verband met andere prioriteiten. Specificatie met voorbeelden Een groot voordeel van ATDD is, dat het alle partijen tot elkaar brengt en samenwerking stimuleert. Als specificaties worden opgezet in door de business leesbare taal met veel voorbeelden, en worden bijgehouden gedurende het traject, dan vervullen deze de rol van levende documentatie. Het is dus niet meer nodig en zelfs niet meer wenselijk, om de requirements tevens in een Word document bij te houden. De voor iedereen toegankelijke specificaties worden daarmee leidend als documentatie. Dat die specificaties tevens de vorm hebben van uitvoerbare testen waarmee snelle feedback kan worden gegenereerd, is een heel nuttig bijverschijnsel, maar niet de primaire waarde voor de business. Voor het latere beheer geeft het heel veel rust, dat de specificaties altijd up-to-date zijn, direct gekoppeld zijn aan de code, en uitvoerbaar blijven als testen. Een essentieel punt is evenwel, dat de testen duidelijk aangeven, wat de achterliggende bedoeling van de business erbij is. Bij het onderhoudbaar maken van het geheel, is het belangrijk dat business en IT mensen hetzelfde jargon gaan hanteren, d.w.z. dat de terminologie van de business terug te vinden is in de specificaties en daarmee de voorbeelden, en ook in de code. Het bijwerken van documentatie is doorgaans moeilijk, omdat er gezocht moet worden naar de juiste plek in een document. Het gebruik van testen als documentatie lost dit probleem op: een test die moet worden bijgewerkt valt vanzelf op, omdat deze rood is geworden. Gebruik verder tags om het overzicht te bewaren. Unit- en integratietesten De beste resultaten worden bereikt wanneer het gehele team het werk zodanig inricht dat er zo vroeg mogelijk feedback wordt gegenereerd. Een noodzakelijke voorwaarde voor het effectief kunnen samenwerken, is continue integratie (CI). Dit houdt in dat alle code in een gezamenlijk versiebeheersysteem wordt bewaard, en een automatisch proces de wijzigingen (check-ins) detecteert en periodiek compileert tot één gezamenlijk product. Zo wordt er automatisch hele snelle feedback gegeven

4 indien er inconsistenties in de codebase zitten, bijvoorbeeld omdat programmeurs conflicterende aannames maken. De juiste werking van de code kan geborgd worden, door ieder klein stukje van de code te valideren middels het schrijven van testcode. Die testcode (unit test) wordt vervolgens aangeroepen bij iedere continuous integration build van het systeem. Juist omdat het de bedoeling is om alle unit testen voortdurend te draaien, is het belangrijk dat ze snel worden uitgevoerd. Dit wordt deels gerealiseerd door units geïsoleerd te testen, en de interactie met andere onderdelen te vervangen door zogenaamde mock objects. Dat neemt niet weg dat er tijdrovende testen kunnen bestaan. Veel teams kiezen ervoor om dergelijke tijdrovende testen uit te sluiten van de CI build, en te plaatsen in een apart build proces dat bijvoorbeeld s nachts wordt gedraaid: de nightly build. Het verdient aanbeveling om dit al vanaf het begin van het project op te zetten en te oefenen zodat een test snel kan worden verplaatst tussen de twee build processen. Veel teams gaan nog een stap verder, door uitgebreide unit testen te schrijven vóórdat de bijbehorende productiecode wordt gerealiseerd. Dit gebruik wordt Test Driven Development genoemd. Dit is nadrukkelijk een iteratief proces van kleine, beheerste stapjes waarbij de focus ligt op het goed krijgen van het design en het borgen van de onderhoudbaarheid. Stappen voor het toepassen van Test Driven Development (Red Green Refactor): 1. Voeg één of meer tests toe (voor een nog te schrijven stukje code) 2. Voer alle tests uit en zie er op toe dat de nieuw toegevoegde tests falen 3. Schrijf een minimum aan code om de tests te doen slagen 4. Draai alle tests opnieuw; nu moeten ze allemaal groen zijn 5. Refactor de code: maak het eenvoudiger c.q. beter onderhoudbaar 6. Voer nogmaals alle testen uit Stap 5, refactoring, is een integraal onderdeel van TDD. Het nadenken of een eerste oplossing misschien eenvoudiger kan, en die vereenvoudiging dan ook daadwerkelijk doorvoeren, vermindert de kans op fouten. Ook verbetert die werkwijze het overzicht, en het vertrouwen dat de gekozen unit testen voldoende dekking hebben. Veel teams hanteren reviews of pair programming om te zorgen dat alle code en alle unit tests aan een second opinion worden onderworpen. De code wordt nog beter onderhoudbaar, omdat gedachtekronkels worden beperkt en er meer mogelijkheden voor refactoring worden onderkend. Bovendien vindt er op die manier meer uitwisseling van kennis plaats. Een tester die voldoende technisch onderlegd is om de code en de unit testen te reviewen, zal dat zeker niet uit de weg gaan. Immers, vanuit zijn expertise kan hij aanvullingen aandragen, en overlap met zijn eigen testen tegen gaan. Overigens geldt dat wanneer een programmeur een korte uitleg (walkthrough) bij de code geeft, iedere tester in staat zou moeten zijn om de unit testen te lezen, en aanwijzingen te geven voor aanvullende testgevallen. Is de code na zo n uitleg nog onvoldoende leesbaar, dan is die code waarschijnlijk ook niet zo goed onderhoudbaar. Bij het top-down uitwerken van een requirement volgens TDD, zal een programmeur regelmatig mock objects nodig hebben voor onderdelen, die hij of zij over enkele minuten wil gaan schrijven. Dat roept enige weerstand op. Een pragmatische insteek is prima, zolang het maar geen afbreuk doet aan het doel van de exercitie, namelijk het goed krijgen van het design. Kijk uit voor de mini waterval! Als een team heel kwaliteitsbewust is, moet men er voor waken dat de ene testactiviteit de andere testactiviteit niet gaat hinderen. Als een team bijvoorbeeld heel veel unit testen schrijft voor iedere feature, dan moet het wel zo zijn dat de testers een testbaar product ontvangen om hun testen op uit te voeren, lang voordat alle checks zijn geïmplementeerd. De checks en de onderzoekende testen moeten beiden worden uitgevoerd voordat een fragment van het product Done kan worden genoemd. Er is echter géén regel dat alle checks moeten zijn voltooid voordat het onderzoekende testen kan gaan beginnen! Uit onze ervaringen blijkt dat de meeste effectieve aanpak eentje is waarbij op een pragmatische manier de beschikbare hoeveelheid testtijd wordt gemaximaliseerd.

5 Al deze unit testen zijn in feite geen testen, maar checks: de focus ligt op het borgen dat de code goed in elkaar zit omdat alle checks steeds moeten slagen. Het gedrag van de applicatie als geheel kan daarna worden onderzocht door te gaan testen. Beide invalshoeken vullen elkaar aan. Dat wil zeggen: de programmeur die bevestigend test om de juiste werking aan te tonen, vindt andere fouten dan de tester die sceptisch ingesteld te werk gaat en in de huid kruipt van een ondeugende gebruiker. Waar het mogelijk is om testen op integratieniveau te automatiseren, loont dat zeker de moeite. De praktijk leert namelijk dat op het integratieniveau veel fouten optreden. Het controleren van de bedrijfregels kan in de regel wel op dit niveau, maar niet op het niveau van de unit testen. Vaak is er niet alleen sprake van een iets hoger integratieniveau in de zin dat de verschillende units samenkomen tot eenheden in termen van de business processen. Veelal is er ook sprake van het gebruik van externe bronnen, zoals webservices en databases. De implementatie van integratietesten kan in de regel met precies dezelfde tools als unit testen worden uitgevoerd. Alleen is de focus nu anders: het gaat met name om het controleren van de interfaces, niet zozeer om de juistheid van de code en het design. Ook geldt hier het principe van testen in isolatie: voor het testen van één integratie worden onderdelen die eigenlijk buiten de scope van de test vallen, vervangen door stubs of mock objects. Omdat veel integratietesten relatief langzaam zullen zijn (het aanroepen van een webservice kan zomaar een volle seconde vergen), zullen veel integratietesten terecht komen in een nightly build. Nog meer dan bij de unit testen geldt dat dit een uitgelezen mogelijkheid biedt voor het samenwerken tussen testers en programmeurs. Samen bezitten ze testexpertise en kennis van het automatiseren van testen. Het testen van database interactie is een bijzondere tak van sport. Er zijn frameworks om een database op dezelfde manier te behandelen als een object in een unit test. Enkele uitzonderingen daargelaten, is de uitvoeringssnelheid (*) echter zodanig, dat veel van dergelijke testen in een nightly build zouden thuishoren. De ervaring leert dat fouten in bijvoorbeeld het opslaan van gegevens in een database, erg moeilijk te vinden zijn bij testen op een hoger niveau zoals een gebruikersinterface. Het advies is dus om dergelijke testen wel degelijk uit te voeren. Een complicerende factor is het moderne gebruik om te werken met frameworks, welke database queries genereren bij een data model. In zo n geval is het weinig zinvol om op het laagste niveau veel inspanning te steken in het checken van de juiste werking van de gegenereerde code. Kies in plaats daarvan voor het uitvoeren van veel (integratie)testen op een iets hoger niveau, zodat duidelijk is dat de bedrijfsregels goed worden ondersteund met de gekozen oplossing. (*): Hierboven werd gesteld dat database queries langzaam zijn. Er is echter een belangrijke uitzondering, die geleidelijk aan populariteit wint. In memory database systemen zijn dermate veel sneller dan reguliere database systemen, dat nagenoeg iedere query in een test gewoon snel genoeg is voor de CI build. Ook als men geen gebruik maakt van een in memory database systeem, is het natuurlijk wel mogelijk om een deel van de unit testen op de database toe te laten tot de CI build. Voeg gewoon logging toe, zodat duidelijk wordt hoeveel tijd (doorgaans uitgedrukt in milliseconden) een test vergt. Zodoende kan gericht worden gekozen voor het plaatsen van de test in de CI build of de nightly build. Exploratory Testen Eenvoudig gepresenteerd, komt Exploratory Testen (ET) neer op het tegelijk specificeren en uitvoeren van testen. Er worden en passant dus wel degelijk specificatietechnieken gebruikt, en het proces is wezenlijk meer dan error guessing. De reden dat er binnen een Agile context vaak voor gekozen wordt om te beginnen met Exploratory Testen, is dat er veel waarde wordt gehecht aan het snel geven van feedback. (Als er met een minimum aan voorbereidingstijd begonnen kan worden met de testuitvoer, dan kunnen bevindingen zeer goedkoop hersteld worden, omdat de materie bij de programmeur nog vers in het geheugen ligt.) Op basis van de eerste ervaringen kan dan besloten worden om verder te gaan met een andere testtechniek. Om effectief met elkaar samen te werken en voor elkaar te kunnen bijspringen, is het in een Agile project belangrijk om inzage te geven in hoe er getest wordt. Immers, het kan gebeuren dat de persoon die de test uitvoert, een andere is dan degene die de test heeft voorbereid. Is er bij Exploratory Testing dan ook sprake van testvoorbereiding? Ja. Het is een goed gebruik om eerst een zogenaamde test charter op te stellen. Daarin staan geen uitgewerkte testgevallen, maar wel (globaal) wat er getest gaat worden, met

6 welke intenties en aandachtspunten de test wordt uitgevoerd, en in welk tijdsbestek. Het is gebruikelijk om ET uit te voeren als een time-boxed activiteit. Als techniek schrijft ET voor dat na afloop van de timebox de charter is aangevuld met de testresultaten, en dat er in een korte nabespreking (debriefing) wordt besloten welk vervolg er aan de test wordt gegeven. Maak de charters c.q. testsessies ook niet te lang, beslist niet langer dan 4 uur. Vaak is 90 minuten al ruim voldoende. In veel gevallen lijken de globaal beschreven testsituaties op een checklist. De uitvoerende tester wordt gevraagd om zich beslist niet te beperken tot de beschreven testen, maar gaandeweg nieuwe testen te formuleren en uit te voeren op basis van de eerste ervaringen en bevindingen. Tijdens het uitvoeren van de testen moet de charter dus niet alleen wordt aangevuld met de testresultaten en bevindingen. Er moet ook (kort) worden beschreven welke testsituaties er gaandeweg zijn toegevoegd en uitgevoerd. De ingevulde testcharter hoort na de sessie (en de debriefing) te worden bewaard en toegevoegd aan de oplevering aan het einde van de iteratie. Als er veel charters zijn (8 of meer), of wanneer functionele delen zijn opgesplitst en ondergebracht in meerdere charters, voeg dan ook een overzichtsdocument toe. Fouten zijn vaak geclusterd De ervaring leert dat fouten binnen software vrijwel nooit gelijkmatig zijn verspreid over de applicatie. Er zijn altijd onderdelen die eruit springen en meer fouten opleveren, bijvoorbeeld omdat de materie als zeer complex werd ervaren, of de requirements niet goed zijn begrepen. Een time-boxed (Exploratory) test kan goed gebruikt worden als graadmeter voor een onderdeel. Daarna kan het team besluiten wat de beste vervolgactie is: stoppen met testen, fouten corrigeren en verder testen met een meer formele testtechniek, of zelfs het kiezen van een andere oplossing of het herschrijven van de code. Een tester die Exploratory Testing als techniek toepast, maakt gebruik van het ervaringsfeit, dat fouten veelal geclusterd voorkomen. Waar een fout wordt gevonden, loont het de moeite om juist in die omgeving verder te zoeken naar fouten. Ook is het waarschijnlijk dat een gerelateerde fout elders in de code voorkomt: soms wordt een fout nu eenmaal pas gevonden nadat deze als tekst of als gedachtekronkel is gedupliceerd. Uitvoering van Exploratory Testen zal grotendeels handmatig plaatsvinden. Tools kunnen goed ingezet worden voor bijvoorbeeld het versnellen van het bereiken van de uitgangssituatie voor een test. Ook kan er in sommige gevallen gespeeld worden met parameters in scripts, om zodoende variatie aan te brengen in het gebruikersgedrag. Bij Exploratory Testing worden er wel degelijk testtechnieken gebruikt. Vaak gebeurt dat echter en passant, op basis van routine. Een ervaren tester past bijvoorbeeld grenswaarden toe, zonder deze te hoeven uitschrijven. Ook heuristieken zijn onderdeel van het arsenaal dat een tester toepast. Stel bijvoorbeeld dat een testcharter neerkomt op het onderzoeken van de validaties in een aantal schermen van een gebruikersinterface. De meest voorkomende fout in validaties, is dat ze afwezig of onvolledig zijn. Daarnaast kan het gemakkelijk voorkomen dat grenswaarde controles verkeerd zijn geïmplementeerd. Het uitschrijven van alle controles die worden uitgevoerd voegt weinig waarde toe. Maak gewoon algemene afspraken over de voor de hand liggende controles, en leg deze ergens vast in een checklist. Denk daarbij aan het leeg laten van verplichte velden, het proberen van onjuiste waarden en tekens in tekstvelden, en grenswaarden voor numerieke velden. In de testcharter horen naast de schermen alleen de bedrijfsregels vermeld te staan, die expliciet moeten worden gecontroleerd. Tijdens de uitvoering hoeft in de testcharter dan alleen de voortgang te worden vermeld, welke bevindingen er naar voren kwamen, en welke vervolgacties (verdere testen op basis van de bevindingen) er gekozen zijn. Niet functioneel testen In principe horen alle testsoorten binnen de iteratie te worden uitgevoerd, teneinde de feedback lus zo kort mogelijk te houden. Dat geldt dus ook voor testen van kwaliteitsattributen zoals performance en security. Richt daartoe één of meer aparte testomgevingen in, welke niet gebruikt worden voor de functionele testen. De praktijk leert overigens dat in bijna alle gevallen er veel meer waarde gehecht wordt aan informele metingen dan aan exacte metingen op basis van gecontroleerde omgevingen en de bijbehorende (dure) tools. Een programmeur heeft namelijk genoeg aan indicatieve metingen en trends voor het aanbrengen van correcties. Een beheerafdeling wil vooral bewezen zien dat de performance niet meer dan lineair achteruit gaat.

7 Het is belangrijk om deze testen van kwaliteitsattributen op de juiste plaats uit te zetten in de tijd. Een eventuele correctie kan namelijk heel duur zijn, omdat het vaak niet zozeer de code is die wordt aangepast, als wel de onderliggende architectuur. Richt daarom in ieder project een zogenaamd Proof of Concept in, waarop de metingen van de gekozen kwaliteitsattributen vroegtijdig kan plaatsvinden. Sowieso is het wenselijk dat er sprake is van een doelgerichte architectuur, waarbij de testbaarheid van het geheel in het achterhoofd wordt gehouden. Een goed gebruik is bijvoorbeeld de separation of concerns; dit houdt in dat afgebakende onderdelen (vaak: lagen) in een applicatie zich met verschillende zaken bezighouden. Als bijvoorbeeld de bedrijfsregels deels verstopt zitten in de database, dan is het waarschijnlijk moeilijk om als team het overzicht te behouden, en te bepalen hoe een wijziging getest moet worden. Zijn er heel veel kritische onderdelen, in de zin dat er bijna iedere iteratie nieuwe onderdelen bijkomen die getest moeten worden op bijvoorbeeld performance, dan zal het Proof of Concept geen uitsluitsel geven. Richt in dat geval de testen zodanig in, dat deze binnen de iteratie kunnen worden uitgevoerd. Kies bewust voor een beperkte levensduur van het merendeel van de testen, omdat het beheer ervan in latere iteraties kostbaar zal zijn. Selecteer aan het einde van iteratie slechts een deel van de testen om aan te houden als onderdeel van de regressie suite. Binnen de iteratie is dus het advies dus: doe zoveel mogelijk als onderdeel van de Definition of Done. Dat neemt niet weg dat er een zekere testverplichting over blijft aan het einde van de rit. Projectmatig moet de intentie zijn, dat een test aan het einde een bevestigend karakter krijgt. Als de risico s vooraf goed zijn ingeschat, zijn er in de slotfase geen dure verrassingen meer. Voor sommige testen is het heel moeilijk om deze in te passen in de Agile procescyclus. Denk daarbij bijvoorbeeld aan het testen met ketenpartners, die er zelf een andere release cyclus op na houden. Dan is het belangrijk om goede afspraken te maken over het testen van de interfaces. Voor de eigen ontwikkeling is het prima om het merendeel van de testen binnen de iteratie uit te voeren tegen stubs. Voorafgaande aan het live gaan van een product zal men de test met zo min mogelijk stubs willen uitvoeren. Die testuitvoering alsmede eventuele herstelwerkzaamheden zitten per definitie op het kritieke pad; vroeg testen moet dit tot een minimum beperken. Definition of Done Het team legt vast welke kwaliteitsstappen ze gaan uitvoeren om te komen tot een kwalitatief goede oplevering van een productierijp systeem. Dat kwaliteitskader (de zogenaamde Definition of Done) geeft veel richting aan het werk van het team. Tijdsinschattingen worden nauwkeuriger, en de opdeling van het werk eenvoudiger. Verwachtingen bij de klant worden expliciet gemanaged. Namens de business is het niet alleen de product owner die criteria kan opleggen, waar iedere oplevering aan moet voldoen. Ook een beheerafdeling heeft doorgaans eisen, die het team moet overnemen, en zal incalculeren bij het inschatten van het werk. De Definition of Done is ook mede bepalend voor de benodigde samenstelling van het team. Ontbreekt er een vaardigheid aan het team welke nodig is om alle stappen in de Definition of Done tot een goed einde te brengen, dan is dat een goede aanleiding voor het uitbreiden van het team. Indien een organisatie beleid heeft aangaande de inhoud van een Definition of Done, dan biedt dat een belangrijke mogelijkheid voor commercieel succes. De kwaliteit van het product kan en moet benadrukt worden, in plaats van de lage prijs waarvoor het wordt gerealiseerd. Documentatie bij oplevering De op te leveren documentatie moet onderdeel zijn van de afspraken omtrent de Definition of Done. Het team zal zelf een beeld hebben van de benodigde systeemdocumentatie; een beheerafdeling kan daar allicht nadere eisen aan stellen. Het is in elk geval billijk om te verlangen dat op het moment van oplevering de documenten up-to-date zijn met de realisatie van het product. Veel teams werken met gegenereerde systeemdocumentatie, die bijvoorbeeld door het gebruik van labels in de code en in het versiebeheersysteem de wijzigingen en de release notes kunnen oplepelen. Doordat het een geautomatiseerd proces betreft, is het team er geen tijd aan kwijt, en worden er geen fouten in gemaakt (anders dan het achterwege laten van de labels). Een ander voor de hand liggend minimum om op te leveren, is in termen van de business een formulering van wat er nieuw in een release zit. Gelukkig biedt het proces daar een eenvoudige invulling voor: er moet allicht een lijst zijn van alle user stories die voldoen aan de Definition of Done. Houd die lijst dus goed bij, en let er op dat de user

8 stories zo veel mogelijk geformuleerd zijn in termen van de business. In feite is deze stap gegarandeerd, als het team op een goede manier ATDD / specificeren met voorbeelden heeft ingericht en ingebed in de organisatie. Vanuit testoogpunt is het belangrijk dat de opgeleverde testware leesbaar is voor het nageslacht. Dit is namelijk een valkuil voor veel teams: dat de programmeurs hun zaakjes goed voor elkaar hebben en de code volledig in source control hebben, en dat de testware achter blijft. Tester is een rol, geen functie Voor veel testen is tijdige uitvoering van de test belangrijker dan de testkennis van de persoon die de uitvoert. Slechts een klein deel van de testen vereist bij de uitvoering de expertise van de expert. Door zo veel mogelijk testen uit te laten voeren door de bouwers, kunnen zij zorg dragen voor het automatiseren en het beheren daarvan. Al met al verandert de richting van de werkverschaffing. De tester is niet langer het afvoerputje waar het gehele team zijn testwerk op uitstort. In plaats daarvan zorgt de testspecialist (Gojko Adzic: test architect ) ervoor dat de juiste dingen getest worden en reikt hij of zij de testtaken aan voor de bouwers. Een goed voorbeeld van een teamlid voor wie testen een rol zal zijn, is de ontwerper of analist. Het is mogelijk dat in de latere iteraties een substantieel deel van de analyse al is uitgevoerd, in de zin dat het geen dagtaak meer is. Voor het team is het dan heel waardevol, als die persoon wel fulltime bij het team blijft, en actief meehelpt met testen. Het betreft immers iemand met uitgebreide kennis van het gewenste gedrag van het systeem. Domein testers en Systeem testers In vrijwel ieder project is er behoefte aan een testaanpak op twee verschillende fronten. Denk bijvoorbeeld aan een service geörienteerde oplossing (SOA): op een hoog niveau waar de services worden samengevoegd tot business processen, is het voor het testen randvoorwaardelijk dat de afzonderlijke services al uitvoerig zijn getest. Op dat hoge niveau worden de testsituaties omschreven in termen van de business, en worden de testen uitgevoerd in samenwerking met domeinspecialisten. Een tester op dat niveau moet domeinkennis kunnen toepassen, en goed kunnen communiceren en meedenken met mensen van de business. Voor het testen van de afzonderlijke services is een heel andere aanpak nodig. Dat vergt namelijk rechtstreeks contact met de bouwers binnen het team, gebruik van specialistische tools, en kennis van het implementatieplatform. Daarbij worden vaker formele testspecificatietechnieken gebruikt. De benodigde vaardigheden voor deze systeemtesters zijn daarmee wezenlijk verschillend van de vaardigheden voor domeintesters. Het is goed als een tester zich op beide terreinen ontwikkelt. Echter: vrijwel iedere tester heeft slechts de affiniteit en de potentie om op één van beide terreinen te excelleren, als Domeintester of als Systeemtester. De aanbeveling is om als organisatie verschillende carrièrepaden en opleidingen aan te bieden, en mensen dus te laten kiezen. Binnen een multidisciplinair team zijn beide rollen (d.w.z. de rol van domeintester en de rol van systeemtester) nodig. Als het team op beide rollen een testspecialist wil hebben, dan heeft dat consequenties voor de gewenste grootte van het team. De Scrum theorie wordt vaak uitgelegd als: teams van (4)5 tot 7 personen met een zekere voorkeur voor de kleinere teamgrootte. Onze voorkeur (gebaseerd op ervaringen uit de praktijk) gaat uit naar een team van 6 tot 9 personen met daarin 2 of 3 testspecialisten. Om beide testrollen goed uit de verf te laten komen ligt de minimum grootte voor het team nu eenmaal ietsje hoger.

9 Duale rollen Het werk vraagt een zeker mate van flexibele inzet. De benodigde inspanning per discipline varieert in de tijd. Het is daarom zeer wenselijk als enkele teamleden in staat zijn om meer dan één rol in te vullen. Bijvoorbeeld: ontwerper of programmeur, en tester. Hoeveel mensen zullen een dergelijke duale rol kiezen, als de organisatie dat niet ondersteunt met een carrièrepad dat goed wordt gewaardeerd? Het gaat niet alleen om de financiële aspecten. Hoogstwaarschijnlijk heeft een medewerker meer tijd nodig om up-to-date te blijven in twee disciplines dan in één vakgebied. Het beschikbaar stellen van uren voor het bijhouden van de vakgebieden zou een goed extraatje kunnen zijn voor die medewerkers. Hen naar meer trainingen en conferenties toe sturen zou ook heel positief worden ontvangen. Team == Product Een kwalitatief hoogstaand product maken vereist een heel goed lopend team. Is er iets mis in de onderlinge communicatie, of ontbreekt er iets aan de kennis en vaardigheden van de teamleden, dan zal dat zijn weerslag hebben op het eindproduct. Als de klant onvoldoende tijd kan vrijmaken voor het team, of niet met passie de intenties achter de vraagstelling voor het product kan verwoorden, dan beperkt dat de mogelijkheden om samen te komen tot een prachtige creatieve oplossing. De attitude van de teamleden moet in de eerste plaats resultaatgericht zijn. Dat houdt in dat er geen persoonlijke doelen worden nagestreefd, maar één gezamenlijk doel. Alle activiteiten van de teamleden moeten bijdragen in het als team voldoen aan de Definition of Done. In een iteratief proces is het een natuurlijk en onvermijdelijk fenomeen, dat er in de slotfase meer testwerk is dan in het begin. Van de teamleden wordt verwacht dat ze testtaken volledig gemotiveerd oppakken, ook als dat niet hun specialisme is. Wanneer een team begint met een Agile werkwijze, dan zal het zo zijn dat lang niet iedereen even test infected is. Ook in ervaren team zal het zijn dat er voor de testspecialist niet alleen een rol is weggelegd in het aanreiken van testgevallen, maar juist ook in het overdragen van testkennis. Evenzo zal een tester kennis opbouwen van het implementatieplatform, en kan iedereen domeinkennis leren uit de interactie met de klant. Als organisatie is het belangrijk om een lerende omgeving te creëren voor het team, en het team niet alleen aan te sturen of af te rekenen op productiviteit op de korte termijn. Geef tijd voor individuele ontwikkeling. Dit gaat zich later terug betalen. Houd teams bij elkaar, en maak gebruik van teamleden met duale rollen om accentverschuivingen in de werklast op te vangen. Als team is het belangrijk om te leren van de fouten die er gemaakt worden. Ook als het goed lijkt te gaan, kan vrijwel ieder team nog verbeterpunten aandragen voor zowel hun eigen proces, als de organisatie om hen heen. Retrospectives (evaluaties per iteratie) zijn hiervoor een uitstekend middel; sla die stap in het proces dus nooit over. Teamleden kunnen actief van elkaar leren, door veel aan kennisoverdracht te doen, en regelmatig taken uit te voeren buiten het eigen specialisme. Pair programming kan voor heel veel taken worden toegepast. Voor wat betreft het lerende effect worden de beste resultaten bereikt als de expert niet als bestuurder achter de knoppen zit, maar als

10 navigator. Ook de kwaliteit van het eindresultaat is in die opstelling vaak beter, omdat de juiste persoon in de corrigerende rol zit. Als de meest ervaren medewerker achter de knoppen zou zitten, dan is er al gauw een drempel, die de leerling belemmert in het uitspreken van twijfel over de juistheid. We kunnen dit vergelijken met de luchtvaart: daar hebben ze geconstateerd dat de landing het meest veilig is wanneer deze wordt uitgevoerd door de copiloot. Waar nodig zal de captain niet schromen om in te grijpen. Collective test ownership Een algemeen toegepaste werkwijze vanuit Extreme Programming (XP) is collective code ownership. Dat houdt in dat alle teamleden gezamenlijk de code beheren, volledige inzage hebben, en bijvoorbeeld ook de fouten oplossen in code die door een ander is geschreven. Dat impliceert dat er één gezamenlijk systeem moet zijn voor het beheren van de code, en uiteraard is het ook alleen werkbaar als er tevens continuous integration wordt toegepast. Voorts moet er sprake zijn van veel uitwisseling van kennis, bijvoorbeeld door middel van reviews of pair programming. Sommige teams gaan nog een stap verder, door ook alle testware in source control te plaatsen, en deze als team gezamenlijk te beheren. Elisabeth Hendrickson noemt dat: collective test ownership. Om collective test ownership in praktijk mogelijk te maken, heeft een team nog meer nodig. Coding standards zullen ook moeten worden doorgetrokken naar testdocumenten en testcode. Testen worden zo dicht mogelijk gekoppeld aan de code. De vertaalslag van requirements naar testen moet duidelijk en traceerbaar zijn. Bij wijzigingen in de code of in de requirements moet het gehele team over voldoende overzicht beschikken, om adequaat te kunnen beslissen over de testen die moeten worden uitgevoerd, en hoe deze verder moeten worden beheerd. Veel van de testen worden geautomatiseerd. Het inrichten van de testautomatisering wordt belegd bij de bouwers binnen het team en de testers zorgen dat de juiste zaken getest worden. Het beheer van de testen komt daarna bij alle leden van het team te liggen. Dat houdt in dat kennis actief moet worden gedeeld, en er regelmatig in paren zal worden gewerkt. Gelijkheid binnen het team Het klinkt zo gemakkelijk: gelijke monniken, gelijke kappen. Het is echter wel een hele mentaliteitsverandering om collective test ownership in te voeren, en beslist eentje die weerstand oproept. Nog altijd zien veel programmeurs het testen als monnikenwerk, iets waar ze bewust niet voor hebben gekozen. Toch kan het zomaar gebeuren, dat van een programmeur of een analist wordt verlangd, dat hij of zij enthousiast gaat meehelpen met het uitvoeren van testen die niet zijn geautomatiseerd! Bereidheid om werk uit te voeren en zich te ontwikkelen buiten de eigen comfort zone is dus zeker een vereiste. Uiteraard geldt dat voor alle teamleden, ongeacht hun rol. Wat ook belangrijk is voor de benodigde gelijkheid binnen het team, is dat iedereen wordt behandeld als een volwaardige professional, die niet hoeft te worden beknot in zijn of haar rechten. Geef dus een tester gewoon schrijfrechten op de code en de unit tests, en geef een bouwer de mogelijkheid om met één druk op de knop de inhoud van een compleet testscript te wissen. Ze zijn immers allemaal professioneel genoeg om hun rechten niet te misbruiken (en alles staat toch in source control). Wat vermeden wordt met het uitdelen van full control, is dat er berichtenverkeer buiten de codebase nodig is. Dat laatste levert alleen maar verwarring en vertraging op, en is dus een vorm van verspilling. Een medewerker die onvoldoende technisch onderlegd is om zelfstandig een test te implementeren of aan te passen, kan deze allicht wel met een paar commentaarregeltjes omschrijven in de code. Maak afspraken over de te gebruiken tags in de testcode, en richt het build proces er op in. Als een team er serieus werk van wil maken om gezamenlijk de testen te beheren, dan moet de testcode zo veel mogelijk gezien worden als reguliere code. Testcode heeft onderhoud nodig. Testcode moet op een onderhoudbare wijze worden opgezet. Allicht moeten teamleden elkaars testcode reviewen. Mogelijk komt er uit zo n review, dat een test eenvoudiger kan, of bijvoorbeeld herhalingen bevat. Kortom: refactoring van testcode zou ook bespreekbaar moeten zijn. Het enige probleem daarbij is dat er geen vangnet van geautomatiseerde testen voorhanden lijkt te zijn, om wijzigingen aan de testcode mee te borgen. Dat is echter niet helemaal waar: houd bij het refactoren van testcode de productiecode constant, en zie er op toe dat de testen groen blijven!

11 Samenvattend: wat is nu de rol van de tester? Het testen moet zo veel mogelijk van het kritieke pad van het project af, vroeg beginnen en zo veel mogelijk parallel met de bouw worden uitgevoerd. Daarmee is de tijd van validatie door een onafhankelijk QA team voorbij. Veel checks worden nu al uitgevoerd door de bouwers in een multidisciplinair team. De testspecialist binnen zo n team heeft verschillende rollen, waarvan testuitvoerder er slechts ééntje is. Voorts is de tester: Dirigent. Hij zorgt er voor, dat de overige teamleden de juiste dingen testen, en dat dit alles harmonieus gebeurt. Teamspeler. Hij kan snel schakelen, en feedback leveren waar dat op dat moment nodig is voor het team. Analist. Het samen verbeteren van de requirements (voorbeelden?) geeft richting aan het verdere testen. Kennisdeler. Door testkennis te delen met andere teamleden, stelt hij hen in staat effectiever te testen. Bruggenbouwer. De tester communiceert met vrijwel alle rollen in de business en het IT project. Wees dus objectief als tester, en deel je kennis. Behoud het overzicht, en zorg dat eenieder elkaar vindt en helpt met het geven van vroege feedback.

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

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

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

Agile testen - kwaliteit onder controle

Agile testen - kwaliteit onder controle Agile testen - kwaliteit onder controle Marc Evers Piecemeal Growth Anko Tijman Ordina TestNet 16 maart 2006 www.testnet.org Agenda Wat betekent agile en agile testen Kwaliteitsborging in agile projecten

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

Scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum agileagileagileagileagileagileagileagil

Scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum agileagileagileagileagileagileagileagil Scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum agileagileagileagileagileagileagileagil eagileagileagileagileagileagileagileagi leagileagileagileagileagileagileagileag

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

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

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

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

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

Nadere informatie

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

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

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

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

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

Webtesten onder schaarste

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

Nadere informatie

Ontwikkelmethoden en technieken. Ontwikkelmethoden & Technieken HC 2

Ontwikkelmethoden en technieken. Ontwikkelmethoden & Technieken HC 2 Ontwikkelmethoden en technieken 1 Vandaag Een kleine geschiedenis (vervolg) Klein stukje XP Afbakening verwachtingen 2 Werkwijze theorie Lesstof Presentaties Boek Aantekeningen Introductie/overzicht Week

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

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

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 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

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

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

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

Nadere informatie

voorpublicatie TESTEN2.0 TM de praktijk van agile testen Testen 2.0 agile testen vooraankondiging.indd 1 11-9-2008 11:35:52

voorpublicatie TESTEN2.0 TM de praktijk van agile testen Testen 2.0 agile testen vooraankondiging.indd 1 11-9-2008 11:35:52 voorpublicatie TESTEN2.0 TM de praktijk van agile testen Testen 2.0 agile testen vooraankondiging.indd 1 11-9-2008 11:35:52 In november 2008 publiceert Ordina het boek Testen2.0 TM. De praktijk van agile

Nadere informatie

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

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

Nadere informatie

Wie ben ik? Agile Software Development. Het waterval model. Inhoud

Wie ben ik? Agile Software Development. Het waterval model. Inhoud gile Software Development Februari 2008, Philippe Dirkse Wie ben ik? 2002: fgestudeerd TU/e 1999-2005: Mondo izzarro, rystal Interactive, Siemens tea 2005 heden: PTS: Leica Microsystems SES/MiPlaza Inhoud

Nadere informatie

Agile bij grote administratieve systemen. Omgaan met requirements

Agile bij grote administratieve systemen. Omgaan met requirements Agile bij grote administratieve systemen Omgaan met requirements 1 Agenda Wat is een groot systeem? Aanpak van een groot systeem Agile alignment Agile en requirements (en architectuur) Agile en governance

Nadere informatie

Agile/Scrum Foundation

Agile/Scrum Foundation Agile/Scrum Foundation Wil je continu grip houden op (langlopende) projecten? Leer de theorie van Agile en hoe Scrum een oplossing biedt om projecten binnen tijd en budget te realiseren Leer welke verantwoordelijkheden

Nadere informatie

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

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

Nadere informatie

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

Ministerie van Infrastructuur en Milieu Beheerst naar beheer

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

Nadere informatie

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

Ontwikkelen en testen van e-business: beheerste dynamiek

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

Nadere informatie

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

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

Nadere informatie

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

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

TFS als perfecte tool voor Scrum

TFS als perfecte tool voor Scrum TFS als perfecte tool voor Scrum René van Osnabrugge renevo@delta-n.nl About me René van Osnabrugge Communicate @renevo renevo@delta-n.nl http://osnabrugge.wordpress.com Agenda Wat is Scrum? Wat is ALM

Nadere informatie

De Agile Analist. Henk Jan Huizer

De Agile Analist. Henk Jan Huizer De Agile Analist Henk Jan Huizer Software Ontwikkeling Dat is Software Ontwikkeling is Voor veel organisaties van steeds grote belang! Agile Software ontwikkeling Is een aanpak die past bij het type werk

Nadere informatie

Oplossingen voor het testen van objectgeoriënteerde software

Oplossingen voor het testen van objectgeoriënteerde software Oplossingen voor het testen van objectgeoriënteerde software Pieter van den Hombergh Fontys Hogeschool voor Techniek en Logistiek Software Engineering 14 maart 2013 HOM/FHTeL Oplossingen voor het testen

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

Service Virtualization @RABOBANK

Service Virtualization @RABOBANK Service Virtualization @RABOBANK TMA Dag 2015 eter Claassen RABOBANK Marc van Lint - IBM Agenda 1. Rabobank Context 2. DevOps Vision 3. roof en Implementeren 4. Voorbeelden 5. Ervaringen & Best ractices

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

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

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

Customer Case: WoningNet

Customer Case: WoningNet Customer Case: WoningNet WoningNet en Webservices Woonruimtebemiddeling Shared service center Business uitdaging Architectuur visie Woonruimtebemiddeling Woningzoekende Corporatiemedewerker Corporatiemedewerker

Nadere informatie

Chris de Kok 223548 TDI 3. Vak: Software Architectuur Datum: 21-01-2008 Docent: Fons van Kesteren

Chris de Kok 223548 TDI 3. Vak: Software Architectuur Datum: 21-01-2008 Docent: Fons van Kesteren Chris de Kok 223548 TDI 3 Vak: Software Architectuur Datum: 21-01-2008 Docent: Fons van Kesteren Inhoud Inleiding... 3 Black box / White box... 3 XP... 3 SimpleTest... 3 Eclipse plugin... 4 GroupTest...

Nadere informatie

1. De watervalmethode... 2. 2. Agile softwareontwikkeling... 2. 3. Iteratief werken... 3. 4. Agile technieken voor teams... 3

1. De watervalmethode... 2. 2. Agile softwareontwikkeling... 2. 3. Iteratief werken... 3. 4. Agile technieken voor teams... 3 Naar Voren: Tijdschrift voor webwerkers» Artikel #155 Agile (web)ontwikkeling Omarm de verandering Als ICT-professional heb je het liefst dat de klant exact weet wat hij wil, dat jij exact weet hoe je

Nadere informatie

Ervaringen met het opzetten van een MDD omgeving

Ervaringen met het opzetten van een MDD omgeving Ervaringen met het opzetten van een MDD omgeving Introductie (1/3) Eric Jan Malotaux Software architect Mod4j Software architect Ordina Johan Vogelzang Developer Mod4j Projectleider Java ontwikkelstraat

Nadere informatie

SmartScrum: Agile én duurzaam

SmartScrum: Agile én duurzaam SmartScrum: Agile én duurzaam SmartScrum: slimmer, sneller, goedkoper! 20% tot 30% snellere time-to-market 20% tot 30% kostenbesparing 100% voorspelbaar 100% duurzaam 100% begrijpelijk PNA Group lanceert

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

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

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

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

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

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

WAT BETEKENT BUSINESS AGILITY VOOR UW ONTWIKKELSTRAAT? SAMENVATTING BUSINESS AGILITY ITERATIEVE AANPAK ONTWIKKELSTRAAT

WAT BETEKENT BUSINESS AGILITY VOOR UW ONTWIKKELSTRAAT? SAMENVATTING BUSINESS AGILITY ITERATIEVE AANPAK ONTWIKKELSTRAAT WAT BETEKENT BUSINESS AGILITY VOOR UW ONTWIKKELSTRAAT? SAMENVATTING Voor het bereiken van business agility is meer nodig dan een juiste architectuur en is een iteratieve aanpak essentieel. Daarvoor is

Nadere informatie

Ontwikkelmethoden en technieken. Ontwikkelmethoden & Technieken HC 4

Ontwikkelmethoden en technieken. Ontwikkelmethoden & Technieken HC 4 Ontwikkelmethoden en technieken 1 Projectinrichting Ontwikkelmethoden & Technieken HC 34 2 Vandaag Terugblik? Projectinrichting Afsluiting Leestip Introductie/overzicht Week 1 Afbakening Verwachtingen

Nadere informatie

Project methodiek. Auxilium BV Oude Delft 48 2611 CD Delft. T: 015-261 23 16 F: 015-213 34 83 E: info@auxilium.nl

Project methodiek. Auxilium BV Oude Delft 48 2611 CD Delft. T: 015-261 23 16 F: 015-213 34 83 E: info@auxilium.nl Project methodiek Auxilium BV Oude Delft 48 2611 CD Delft T: 015-261 23 16 F: 015-213 34 83 E: info@auxilium.nl Inhoud 1 PROJECTMETHODIEK... 3 1.1 TIME-BOXING... 3 1.2 USER-STORIES EN STORY-POINTS... 3

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

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

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

Nadere informatie

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

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

Agile, Scrum en Kanban in de praktijk

Agile, Scrum en Kanban in de praktijk Agile, Scrum en Kanban in de praktijk Wat is agile en wat kenmerkt agile projecten? Agile in de praktijk: rollen, teams en best practices Hoe om te gaan met requirements in agile projecten? Hoe agile projecten

Nadere informatie

Leiderschap in een organisatie met technische professionals

Leiderschap in een organisatie met technische professionals Quintor Leiderschap in een organisatie met technische professionals Johan Tillema CEO Quintor Professionele softwareontwikkeling ICT Architectuur Java,.NET en Mobile Informatieanalyse Opgericht in 2005

Nadere informatie

Software Quality Assurance Plan

Software Quality Assurance Plan Software Quality Assurance Plan GameTrac Versie Datum Auteur(s) Opmerking 1.0 10-12-2010 Bram Bruyninckx Eerste iteratie 1 Door hieronder te tekenen verklaart u akkoord te zijn met dit document en zijn

Nadere informatie

Resultaat gerichter Testen

Resultaat gerichter Testen Resultaat gerichter Testen Verandering van test beleid bij Rabobank International De Rabobank 1 Rabobank International Information Systems &Development IS&D Global Services & IT Risk Management Strategy

Nadere informatie

Testing University. A fool with a tool is still a fool

Testing University. A fool with a tool is still a fool Testing University A fool with a tool is still a fool Test Tooling is een must Must? Test Tooling? 2 Als je iets moet kun je dan wel de juiste keuzes maken? Moeten Willen 3 Van moeten naar willen Moeten

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

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

Wat drijft het werkveld?

Wat drijft het werkveld? Wat drijft het werkveld? Presentatie uitkomsten survey Jacob Brunekreef, Fontys ICT Jacob Brunekreef Meer dan 25 jaar werkzaam in de IT Nu: Projectleider EQuA project, Fontys ICT Adviseur / trainer bij

Nadere informatie

Professionele softwareontwikkeling PRODUCTIVITEIT EN KWALITEIT MET FOCUS OP DE GEHELE LEVENSDUUR VAN APPLICATIES

Professionele softwareontwikkeling PRODUCTIVITEIT EN KWALITEIT MET FOCUS OP DE GEHELE LEVENSDUUR VAN APPLICATIES Professionele softwareontwikkeling PRODUCTIVITEIT EN KWALITEIT MET FOCUS OP DE GEHELE LEVENSDUUR VAN APPLICATIES ONZE VISIE OP PROFESSIONEEL SOFTWARE ONTWIKKELEN Bij succesvolle softwareontwikkeling draait

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

Portal Planning Process

Portal Planning Process BROCHURE Portal Planning Process SAMENWERKEN AAN EEN WAARDEVOL PORTAAL BROCHURE PORTAL PLANNING PROCESS 2 Axians PORTAL PLANNING PROCESS BROCHURE Inhoud Introductie 4 3 Portal Planning Process 5 4 Uitdagingen

Nadere informatie

Parasoft toepassingen

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

Nadere informatie

Stichting VraagWijzer Nederland. Notitie Resultaatgericht werken in het Sociale Domein

Stichting VraagWijzer Nederland. Notitie Resultaatgericht werken in het Sociale Domein Stichting VraagWijzer Nederland Notitie Resultaatgericht werken in het Sociale Domein Per 1 januari 2015 hebben de Jeugdwet, de Participatiewet en de Wmo 2015 hun intrede gedaan. De invoering van deze

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

VAN USE CASE NAAR TEST CASE ORDINA SMART COMPETENCE CENTER

VAN USE CASE NAAR TEST CASE ORDINA SMART COMPETENCE CENTER VAN USE CASE NAAR TEST CASE ORDINA SMART COMPETENCE CENTER Sander Hoogendoorn Versie 1.0 15 april 2002 Documentbeheer Versie Datum Auteur Omschrijving 0.1 15 April 2002 Sander Hoogendoorn 0.2 15 april

Nadere informatie

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

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

Nadere informatie

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

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

Nadere informatie

Projectmatig 2 - werken voor lokale overheden

Projectmatig 2 - werken voor lokale overheden STUDIEDAG Projectmatig werken in lokale overheden LEUVEN 27 oktober 2011 Projectmatig werken in de lokale sector Katlijn Perneel, Partner, ParFinis Projectmatig 2 - werken voor lokale overheden 1 Inhoud

Nadere informatie

Oplossingen voor het testen van objectgeoriënteerde software. Oplossingen voor het testen van. Overzicht. Pieter van den Hombergh.

Oplossingen voor het testen van objectgeoriënteerde software. Oplossingen voor het testen van. Overzicht. Pieter van den Hombergh. Oplossingen voor het testen van objectgeoriënteerde software Pieter van den Hombergh Fontys Hogeschool voor Techniek en Logistiek Software Engineering 14 maart 2013 HOM/FHTeL Oplossingen voor het testen

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

Functioneel beheer in Nederland

Functioneel beheer in Nederland Functioneel beheer in Nederland Achtergrond Op initiatief van Marjet Smits (ad Matres), Martijn Buurman (Functioneel-beheerder.com) en Günther Nijmeijer (inmezzo) is eind 2012 de eerste verkiezing voor

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

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

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

Nadere informatie

MDA in de praktijk. Freek Bosch, Business Unit Manager Amsterdam, 4 juni 2009

MDA in de praktijk. Freek Bosch, Business Unit Manager Amsterdam, 4 juni 2009 Functional Model Driven Development MDA in de praktijk Freek Bosch, Business Unit Manager Amsterdam, 4 juni 2009 FMDD agenda FMDD Waarom FMMD De praktijk Wat is FMDD Ervaringen en lessons learned Ervaringen

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

Marc Koper/ Bas M. Dam A Tool with a Fool is only a tool Voorjaarsevent Testnet: 30 juni 2008

Marc Koper/ Bas M. Dam A Tool with a Fool is only a tool Voorjaarsevent Testnet: 30 juni 2008 Titel, samenvatting en biografie Samenvatting: Marc Koper/ Bas M. Dam A Tool with a Fool is only a tool Voorjaarsevent Testnet: 30 juni 2008 Voor het uitvoeren van testen zijn diverse uitstekende tools

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

Overdracht van project naar beheer. Beheer is ook Agile!

Overdracht van project naar beheer. Beheer is ook Agile! Overdracht van project naar beheer. Beheer is ook Agile! Belangrijkste doelen Project: Binnen tijd en geld een nieuw of aangepast product of dienst aan de klant leveren. Beheer: Het garanderen van continuïteit

Nadere informatie

Stel je voor. Agile pilot en retrospectives bij Ericsson. SPIder Conferentie 2 oktober 2007

Stel je voor. Agile pilot en retrospectives bij Ericsson. SPIder Conferentie 2 oktober 2007 Stel je voor. Agile pilot en retrospectives bij Ericsson Nicole Belilos Marc Verschueren Topic Embedded Systems Ericsson Telecommunicatie R&D SPIder Conferentie 2 oktober 2007 Inhoud Even voorstellen Agile

Nadere informatie

Testen binnen agile methoden Anko Tijman

Testen binnen agile methoden Anko Tijman Testen binnen agile methoden Anko Tijman Introductie sinds 1997 in software testen testcoördinator Van Meijel Automatisering verbeterproces aansluiten bij extreme Programming agile proces 2 Testen binnen

Nadere informatie

Inleiding ontwikkelmethoden

Inleiding ontwikkelmethoden Inleiding ontwikkelmethoden 1 Ontwikkelmethoden en Technieken POMT HC1 2 Ronald de Waal Opleiding TU Delft: industrieel ontwerpen Diverse softwarebedrijven, internet ontwerp vanaf 1994 Docent systeemontwikkeling

Nadere informatie

B.Sc. Informatica Module 4: Data & Informatie

B.Sc. Informatica Module 4: Data & Informatie B.Sc. Informatica Module 4: Data & Informatie Djoerd Hiemstra, Klaas Sikkel, Luís Ferreira Pires, Maurice van Keulen, en Jan Kamphuis 1 Inleiding Studenten hebben in modules 1 en 2 geleerd om moeilijke

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

DevOps Waarom moeilijk doen 31 oktober 2013. als het samen kan

DevOps Waarom moeilijk doen 31 oktober 2013. als het samen kan DEVOPS?! INLEIDING Wat gaan we doen? 18:00 Introductie 19:00 Uitleg open space 19:30 Koffie + start open space 20:30 Wrap-up INLEIDING Even vooraf Samen Duurzaam Innoveren INLEIDING Ik ben Jan Buurman

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

Gewone jongens die mooie dingen maken. Wat we doen en hoe we het doen

Gewone jongens die mooie dingen maken. Wat we doen en hoe we het doen Gewone jongens die mooie dingen maken Wat we doen en hoe we het doen Wij zijn studio fonkel Wij zijn Studio Fonkel en wij maken mooie dingen. Of het nu gaat om een website, webapplicatie, landkaart of

Nadere informatie

Grenzeloos vertrouwen in een tool!?

Grenzeloos vertrouwen in een tool!? Grenzeloos vertrouwen in een tool!? TestNet voorjaarsevenement Maandag 30 juni 2008 Rick de Jong Agenda Korte introductie Kritische kijk op het gebruik van tools Intake en selectie van tools Het omarmen

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