Whitepaper. Kwaliteit binnen Agile

Save this PDF as:
 WORD  PNG  TXT  JPG

Maat: px
Weergave met pagina beginnen:

Download "Whitepaper. Kwaliteit binnen Agile"

Transcriptie

1 Whitepaper Kwaliteit binnen Agile Paul Meek en Henri ter Steeg en Versie 1.0 ( ) Web linkit-projects.nl

2 Inleiding Agile is hot. Agile projecten beloven sneller software te leveren, die na elke iteratie onmiddellijk in productie kan. Daarnaast zou de software beter moeten zijn. Dus sneller en beter, daar moeten de klanten toch wel tevreden mee zijn? Business managers zijn tegenwoordig ook meer aware en vragen soms letterlijk aan hun ICT-afdeling om een meer agile aanpak. Toch lossen agile projecten in de praktijk vaak deze beloftes niet in. Het één op één toepassen van de regels van bijvoorbeeld Scrum blijkt vaak onvoldoende. Het goed begrijpen van de principes van agile software development kan al een hoop ellende voorkomen. Theoretische kennis (opgedaan in een eenmalige cursus al dan niet met certificering) en het dogmatisch toepassen van de agile procedures en regeltjes alleen is onvoldoende garantie voor succes. Elk project kan weliswaar putten uit dezelfde pot met agile methoden, technieken en tools, maar wat als de ingezette set in de context van een specifiek project onvoldoende blijken te werken? In agile software development projecten wordt een applicatie iteratief gebouwd. Hierbij wordt gestuurd op business value : de functionaliteit (en ook non-functionals) die voor de business de meeste waarde opleveren, worden als eerste gebouwd. Uiteraard kan een applicatie pas in productie worden gegeven als de applicatie van voren naar achteren werkt. Vandaar dat we ons in de eerste iteraties richten op de architectural baseline. Meer hierover kunt U vinden in de eerste whitepaper van dit drieluik. Het iteratief opzetten van een applicatie houdt in, dat de kans groot is, dat we bepaalde stukken functionaliteit, die we in eerdere iteraties hebben gebouwd in latere iteraties zullen raken. Ook zal het ontwerp van de applicatie gedurende de uitvoering van de iteraties voortdurend evolueren. De snelheid van het team wordt gemeten in nieuwe opgeleverde werkende software (ofwel functionaliteit). We kunnen alleen voldoende snelheid behouden, indien we niet te veel tijd kwijt zijn aan bug fixing vanuit eerdere iteraties. Daarnaast moet het integreren van nieuwe functionaliteit in de bestaande software zonder al te veel extra inspanning mogelijk blijven. Dit kan alleen als de bestaande basis (i.e. reeds gebouwde software) van voldoende kwaliteit is en blijft. Dus moet er gedurende de uitvoering van de iteraties voortdurend aandacht te worden besteed aan kwaliteit van de software. Lean development kent als één van haar principes build quality into the system. Door dit principe op een goede wijze toe te passen, kunnen we waarborgen dat de software van voldoende kwaliteit blijft gedurende alle iteraties in een project, een ook daarna in het onderhoud. Deze whitepaper is het tweede deel in een drieluik over kwaliteit binnen agile sofware development. Hoe kunnen we ervoor zorgen dat de sofware, die een agile project elke iteratie opnieuw oplevert, inderdaad van hoge kwaliteit is. Immers, pas dan heeft de business lead (product owner in Scrum terminologie) werkelijk de keuze om na elke iteratie in productie te gaan met de opgeleverde software. Daarnaast dient een team snelheid te kunnen vasthouden door elke iteratie weer voldoende nieuwe functionaliteit op te leveren. In deze whitepaper gaan we verder in op het kwaliteitsaspect building the thing right. De vorige whitepaper behandelde het aspect building the right thing. De derde en laatste whitepaper zal ingaan op fitness for change. 2

3 Terminologie Alvorens in te gaan op het antwoord hoe we kwaliteit kunnen garanderen in een agile project omgeving, dienen we eerst de volgende termen nader te verklaren: agile en kwaliteit. Voor een korte introductie in agile ontwikkelen, zie de bijlage van de vorige whitepaper (Building the right thing). Kwaliteit in het heden is geen garantie voor kwaliteit in de toekomst Wat is kwaliteit? Een simpele, algemene definitie van kwaliteit is de mate waarin het geleverde aan de verwachtingen van de klant voldoet. Volgens ISO 8402 is kwaliteit: het geheel van eigenschappen en kenmerken van een product of dienst dat van belang is voor het voldoen aan vastgestelde of vanzelfsprekende behoeften. De auteur Joseph Juran beschrijft kwaliteit als fitness for use en Prince2 hanteert de definitie fitness for purpose of conforms to requirements. Kwaliteit ( Fitness for purpose ) kan worden gesplitst in: Building the right thing In de eerste plaats moet je de juiste requirements ontwikkelen ( building the right thing ), en deze moet je op de juiste wijze implementeren ( buidling the thing right ). Binnen Linkit projects is fitness for purpose alleen niet voldoende. Het is mooi, dat de software nu precies doet wat de klant ervan verwacht. Maar wat als de verwachtingen van de klant wijzigen, bijvoorbeeld als gevolg van veranderingen in de markt? Iedereen kent de uitspraak resultaten behaald in het verleden bieden geen garantie voor de toekomst. Met kwaliteit is dit net zo: kwaliteit in het heden is geen garantie voor kwaliteit in de toekomst. De software dient te kunnen meebewegen met de eisen en wensen van de klant. En dan wel in het tempo van die klant! Om software van blijvende waarde te laten zijn voor de klant, dient de software mee te kunnen bewegen met de eisen en wensen van de klant. En dan wel in het tempo van de klant! En niet alleen na het project, maar ook al gedurende het project Dit houdt in dat we naast fitness for purpose ook fitness for change als een belangrijke pijler van kwaliteit zien. 3

4 Binnen agile software development bestaan diverse feedback cylci op verschillende niveau s. Feedback cycles Hét middel om te bepalen of we blijvend op de goede weg zijn is terugkoppeling. Terugkoppeling van gebruikers, beheerders, testers, mede-ontwikkelaars, etc. Een belangrijk onderscheid tussen agile en traditionele ontwikkelprocessen, zoals waterval en het V-model, zijn de korte iteraties (sprints in Scrum) binnen agile. We kunnen de feedback cycli binnen agile presenteren als schillen, zoals bij een ui. Meer naar buiten zijn de feedback cycli langer en komt de feedback voornamelijk van business community, gebruikers en product owner. Dit is voornamelijk feedback op het kwaliteitsaspect building the right thing. Meer naar binnen toe zijn de feedback cycli korter en komt de feedback meer vanuit het team zelf en komt daardoor het kwaliteitsaspect building the thing right meer in beeld. In dit stuk zullen de feedback cycli pair programming, TDD (test driven development), continuous integration en de daily standup ter sprake komen. Vanuit een technische invalshoek komen achtereenvolgens test driven development en continuous integration aan bod. Het uitgangspunt hierbij is de veranderingsbehoefte ten opzichte van een eenmalige oplevering. Vervolgens wordt de rol van pair programming en de daily standup belicht vanuit het building the thing right perspectief. 4

5 Hoe zorgen we ervoor dat (continue) veranderingen geen negatieve invloed hebben op de kwaliteit van de bestaande werkende software? Eén van de belangrijkste uitdagingen bij building the thing right is het combineren van werkende software met het reageren op veranderingen. Bij iedere iteratie dient immers werkende software opgeleverd te worden. Bovendien kan de klant besluiten (delen van) de reeds opgeleverde software in een volgende iteratie te wijzigen of uit te breiden. Voor ontwikkelaars en de te bouwen software heeft dit grote gevolgen. Software gebouwd voor de ene functie staat immers niet los van de software voor de andere functie. Er is vaak sprake van code die gedeeld wordt door verschillende functies. Dit kan variëren van code voor het domein model, herbruikbare componenten in de presentatie laag tot utility functies voor database toegang. Dit hergebruik van code zorgt zowel voor reductie van de kosten voor de ontwikkeling als voor consistent gedrag van de applicatie. Kortom, een goede zaak. Echter, als hergebruikte code wordt aangepast voor de ene functie, heeft dit soms onbedoelde (en ongewenste) consequenties voor andere functies. Dit is de belangrijkste oorzaak voor het ontstaan van defects (bugs), want de code van een applicatie wordt al snel complexer dan de beste ontwikkelaar kan bevatten. Bij de waterval methodiek is het lastig om correct werkende applicatie op te leveren, door wijzigingen tijdens het ontwikkelproces en integratie van diverse componenten. Bij agile werken wordt dit probleem verveelvoudigd, aangezien we na iedere iteratie werkende software op willen leveren! Hier zullen we dus structureel een oplossing voor moeten vinden. Een veel gebruikte oplossing is het zo veel mogelijk automatiseren van testen. Testen Bij de waterval methodiek was de oplossing simpel: testen! De gebruikers en hiertoe opgeleide testers testen de applicatie door na oplevering alle functies door te testen. Dit zouden we natuurlijk ook kunnen doen na iedere iteratie. Zoals echter uit bovenstaande relaas blijkt, is het testen van de functies die in de laatste iteratie zijn opgeleverd echter niet voldoende. De gehele applicatie zal opnieuw doorgetest moeten worden. Een kostbare en tijdrovende operatie. Een veel gebruikte oplossing voor dit probleem is het automatiseren van het testen. Ok, probleem opgelost! We gaan alle functionele tests gewoon automatiseren. Tools genoeg tegenwoordig voor het testen van (bijvoorbeeld) web applicaties: Selenium, Watir, WatiN, WebDriver, etc. Al snel komen we er dan achter, dat geautomatiseerd testen via de user interface zo z n eigen issues heeft. Het uitvoeren van de testen duurt vaak lang (bij enkele honderden testen hebben we het vaak al over een doorlooptijd die uitgedrukt wordt in uren). Bovendien falen deze tests vrij eenvoudig door simpele veranderingen in de layout van de pagina. De vraag is: kunnen we op een ander niveau stabielere en snellere tests definieren? 5

6 Middels een unit test wordt het verwachte gedrag van een klein stukje software gedocumenteerd en getest. Unit tests Dit zijn testen die door de ontwikkelaar worden gemaakt door het schrijven van een testfunctie. Hiermee wordt een klein stukje software getest. Of eigenlijk: het verwachte gedrag van een functie wordt gedocumenteerd en gecontroleerd. Het gebruiken van unit testen heeft als voordeel dat deze snel kunnen worden uitgevoerd en dat ze stabieler zijn dan testen op de user interface. Nadeel is, dat ondanks (vele) unit tests de applicatie als geheel alsnog niet hoeft te werken. Daarom wordt vaak een combinatie van unit tests en functionele tests op de user interface gebruikt. Op de user interface wordt dan het happy path getest, terwijl de uitzonderingssituaties d.m.v. unit tests worden uitgevoerd. De term Test Driven Development staat voor een vorm van ontwikkelen, waarbij eerst de (falende) testen worden geschreven. Daarna wordt de minimale functionaliteit toegevoegd om de test te laten slagen. Het toevoegen van functionaliteit vereist dat er eerst een test wordt toegevoegd. Het technisch ontwerp van de code wordt vervolgens afgeleid van de benodigde functionaliteit. Voordeel van deze manier van werken is, dat de code ook goed bruikbaar is. Het werd immers al vanuit de testen gebruikt! Wanneer zijn we volledig, wanneer zijn we klaar? Volledigheid De volgende vraag die we onszelf kunnen stellen is, hoe volledig we zijn met bovenstaande testen. Hoeveel van de functionaliteit wordt eigenlijk geraakt door onze testen? Als we dit kunnen bepalen, weten we ook waar we het grootste risico lopen op het ontstaan van fouten. Dit noemen we code coverage. Er zijn tools om dit te meten. Tijdens het uitvoeren van de testen wordt gemonitored welke statements zijn uitgevoerd. Het resultaat wordt uitgedrukt in een percentage. 85% code coverage betekent dus dat 85% van alle statements in onze (productie) code is uitgevoerd door onze testen. De vraag is of 100% code coverage een doel moet zijn. Code coverage is een maatstaf om inzicht te krijgen in de mate waarin de applicatie is getest. Het schrijven van tests kost echter ook tijd en deze moeten bovendien worden onderhouden. Er dient een afweging te worden gemaakt tussen de hoeveelheid testen en het risico dat men loopt. Ook al is 100% code coverage vereist, het is niet de holy grail. Code coverage gaat namelijk alleen over de zelf geschreven code en niet over de executiepaden in de aangeroepen framework- of library code. Een ander executie pad in de aangeroepen code, kan namelijk ook nog tot ongewenste resultaten leiden. Een voorbeeld hiervan is het statement: return x / y; Als we dit in de testfunctie alleen testen met x=1 en y=2, dan is er 100% coverage voor dit statement. Wordt de functie in productie uitgevoerd met x=1 en y=0, dan treedt er in de meeste talen een divide by zero fout op. Deze fout wordt immers vanuit het onderliggende framework gegenereerd. De afhandeling van deze fout is niet getest, ondanks de 100% coverage van de eigen code! 6

7 Hoe snel zijn aanpassingen doorgevoerd? Onderhoudbaarheid De mate waarin de applicatie geautomatiseerd wordt getest, bepaalt hoe snel nieuwe bugs boven water komen. Het bepaalt echter niet, hoe snel aanpassingen op de code kunnen worden doorgevoerd. In een agile project is dat zeer relevant, het onderhoud op bestaande code begint immers al bij de 2e iteratie! Natuurlijk is het erg moeilijk om een abstract concept als onderhoudbaarheid te bepalen van de code. Er zijn wel een aantal software metrics die een correlatie hebben met de onderhoudbaarheid. De meest bruikbare voor ons is de Cyclomatic Complexity. Dit is een mooie naam voor een eenvoudig principe. De cyclomatic complexity is (bij benadering) gelijk aan het aantal mogelijke executiepaden door een functie, dus ieder control statement (if, for, while) hoogt de complexity met 1 op. Er is een duidelijk verband gevonden tussen de complexiteit en het aantal fouten. Onderzoek wijst uit dat bij een complexiteit van 11 de kans op fouten 28% is, dit 50% wordt bij een complexiteit van 38 en de kans op fouten 98% is bij een complexiteit van 74. Door het SEI (Software Engineering Institute) worden de volgende richtlijnen aangehouden omtrent cyclomatic complexity: Complexity Risico 1-10 eenvoudige functie, weinig risico meer complexiteit, matig risico complexe functie, hoog risico >= 51 niet te testen functie, erg hoog risico Zelf hanteren we bij nieuwe projecten een harde limiet op de complexiteit van 10. Dit levert soms andere technische keuzes op (bijv. bij case statements). Dit incidentele extra werk weegt echter ruimschoots op tegen de beter onderhoudbare code. Het toepassen van alleen deze metric om de onderhoudbaarheid te borgen, is zeer effectief. Dit komt doordat de relatie tussen oorzaak (de code) en gevolg (de complexiteit) eenduidig is. Bovendien is er een duidelijke grens te stellen. In het begin vraagt dit enige creativiteit van ontwikkelaars, daarna zijn de patronen duidelijk. 7

8 Hoe krijgen we voldoende en op tijd feedback op de kwaliteitseisen die we stellen aan de software? Continuous Integration Nu we onze software testen met behulp van unit tests en de kwaliteit van de code kunnen bepalen middels metrics, wordt het tijd om dit te valideren. Als we het aan de individuele ontwikkelaars overlaten om de testen te draaien, komt deze er al snel achter dat er testen falen waar zijn eigen wijzigingen niet de oorzaak van zijn. En dan de moeite nemen om uit te zoeken welke testen wel falen als gevolg van de eigen wijzigingen is vaak een te hoge drempel. Wat maakt het nog uit of er 16 of 17 testen falen? We kunnen dit beter op een structurele wijze oplossen. Hiervoor kunnen we een zgn build server gebruiken. Dit is een proces dat meestal op een aparte (virtuele) server draait. Dit proces monitort de centrale software repository op wijzigingen. Zodra er een wijziging is aangebracht, wordt op de build server de software gecompileerd en worden de testen gedraaid. De test coverage en complexity worden bepaald. Het resultaat is dat de build ofwel is geslaagd, ofwel is gefaald. Een build is alleen geslaagd als de software met succes kan worden gecompileerd, alle testen succesvol zijn uitgevoerd, de test coverage boven de afgesproken threshold zit en de complexity kleiner is dan de afgesproken threshold. Als een van de stappen faalt, wordt de volledige build beschouwd als gefaald. Hiernaast een voorbeeld van een setup zoals die voor een.net project is gehanteerd. De feedback vanuit de build server werd hier gegeven door Homer Simpson sounds op de developer machines: Geslaagde build: Woohoo! Gefaalde build: WAAAH! Het is aan te raden het volledige team direct feedback te geven als een build faalt d.m.v. een auditief of visueel signaal. De consequenties voor het team dienen duidelijk te zijn: degene die de betreffende wijziging in de repository heeft aangebracht, zorgt ervoor dat dit zo snel mogelijk wordt hersteld. De overige teamleden voeren geen wijzigingen door in de repository, totdat de build weer is geslaagd. Het is bovendien goed gebruik om in het ontwikkelteam af te spreken, dat men pas naar huis gaat als de build weer geslaagd is. Er is niks zo frustrerend als s ochtends binnenkomen en constateren dat degene die gisteren de build falend heeft achtergelaten, vandaag pas tegen de middag binnenkomt. Veel ontwikkelaars draaien om deze reden ditzelfde build proces vaak op hun eigen ontwikkel PC, voordat de centrale repository wordt bijgewerkt. 8

9 Nuke and Pave Een van de eisen aan een build server, waarbij testen worden uitgevoerd, is dat er geen afhankelijkheden zijn. We willen dat het resultaat van de testen voorspelbaar is. Als bijvoorbeeld getest wordt met gegevens uit een database, mag het niet zo zijn dat testen falen omdat iemand iets in deze database wijzigt. Een oplossing hiervoor is de zogenaamde nuke-and-pave strategie. Hierbij wordt als onderdeel van het build proces de database (structuur) verwijderd (nuke) en vervolgens weer opgebouwd (pave), inclusief de data die nodig is voor het draaien van de testen. Van belang is ook dat deze database alleen wordt gebruikt voor het build proces. Ook als dit build proces lokaal op de machines van ontwikkelaars wordt gedraaid, is het van belang dat iedere ontwikkelaar zijn eigen database omgeving heeft. Hoe testen we koppelingen met externe systemen? Er kunnen natuurlijk ook afhankelijkheden van externe systemen zijn. Om deze systemen in een geautomatiseerde (integratie)test mee te kunnen nemen, moet hiervan gebruik gemaakt worden op een voorspelbare manier. Als dit niet mogelijk is, zullen we naar andere oplossingen moeten kijken. Er wordt dan vaak gekozen voor het gebruiken van een stub. Dit is een stukje dummy software, dat dezelfde (software) interface implementeert en waarvan het gedrag wel voorspelbaar gemaakt kan worden. Door het aanpassen van de configuratie wordt tijdens de geautomatiseerde tests de stub gebruikt in plaats van het echte externe systeem. Het belang van oplossingen voor externe afhankelijkheden is erg groot. Wanneer de geautomatiseerde testen niet reproduceerbaar zijn, wordt een falende build al snel niet meer serieus genomen door de ontwikkelaars. En dan wordt er al snel ook geen actie meer ondernomen op echte fouten... Refactoring Als de build server draait met de bijbehorende unit testen, dan kan er ook serieus begonnen worden met refactor werkzaamheden. Vaak is het zo, dat naarmate er meer functionaliteit wordt gebouwd, er een andere (technische) structuur wenselijk wordt. Refactoring is het herstructureren van de code, zonder dat er nieuwe functionaliteit wordt geïmplementeerd. Met een goede suite aan unit tests kan dit veilig worden uitgevoerd. Achterstallig technisch onderhoud wordt ook wel Technical debt genoemd. Zonder refactoring krijgen we al snel een situatie waarin niemand nog structurele aanpassingen in de code durft te maken. Er worden dan steeds meer puisten aan het systeem gebouwd. Dit wordt ook wel legacy code genoemd. Het tijdig uitvoeren van refactoring zorgt ervoor, dat het ontwikkelteam ook op langere termijn met dezelfde snelheid kan doorontwikkelen. 9

10 Pair programming lijkt in eerste instantie inefficiënt, maar levert op termijn tijd op. Pair Programming Een andere techniek die de kwaliteit van de software kan verhogen is Pair Programming. Hierbij zitten twee ontwikkelaars achter een scherm en ontwikkelen samen een stuk software. Dit lijkt inefficiënt, immers nu kost dezelfde software tijd van 2 mensen in plaats van 1. Als de snelheid van ontwikkelen zou worden bepaald door de snelheid van typen, zou pair programming een slecht idee zijn. Het blijkt echter, dat pair programming verschillende voordelen heeft. Ontwikkelaars maken tijdens het bouwen van software ieder uur veel keuzes. Veel van deze keuzes zijn impliciet en intuïtief. Pair programming helpt ontwikkelaars om deze keuzes expliciet te maken, doordat de 2e persoon deze keuzes ter discussie stelt. Hierdoor wordt een bewustere en vaak kwalitatief betere ontwerp keuze gemaakt. Daarnaast zitten ontwikkelaars vaak in een bepaalde frame of mind, waardoor ze mogelijke bugs of andere implementatie mogelijkheden niet (kunnen) zien. Ook zijn ontwikkelaars bij pair programming veel meer gefocussed bezig. Houd er rekening mee dat de eerste dagen pairen vaak als zeer intensief en vermoeiend worden ervaren. Tevens is pair programming een prima manier om kennis binnen het ontwikkelteam te verspreiden. Zeker als er dagelijks van partner gewisseld wordt, verspreid de kennis omtrent de implementatie en de ontwerp beslissingen zich erg snel. Daily standup De daily scrum is een dagelijkse stand-up meeting, waarin ieder projectlid de volgende vragen beantwoordt: Wat heb je gisteren gedaan? Wat ga je vandaag doen? Welke problemen ondervind je? De dagelijkse standup meeting is ook belangrijk voor het faciliteren van een hoge kwaliteit. De uitgevoerde en de nog uit te voeren werkzaamheden worden benoemd, alsmede de punten waar men technisch niet uitkomt. In de standup komen overeenkomstige activiteiten van anderen aan het licht en kunnen afspraken over samenwerking en/of pair programming worden gemaakt. Ook komt de noodzaak tot inhoudelijke en ontwerp discussies vaak aan het licht tijdens de standup. De daily standup is een goed forum on technische kenlpunten aan de orde te stellen Door gebruik te maken van de diversiteit van de groep, kunnen technische blokkades door ideeën van anderen snel worden opgelost. Uiteraard is hiervoor van groot belang dat de groep elkaar vertrouwd, zodat er geen schroom is om technische knelpunten te benoemen... Volgende aflevering In de volgende aflevering gaan we verder in op het kwaliteitsaspect fitness for change. 10

11 Paul Meek is managing director van LinkiT projects. Hij heeft meer dan 20 jaren ervaring in de software ontwikkeling in het algemeen en agile software ontwikkeling in het bijzonder. Hij werkt in projecten graag nauw samen met klanten om voor hen software op te leveren, die echt waarde toevoegt. Henri ter Steeg is agile coach, scrum master en development teamlead bij LinkiT projects. Hij heeft meer dan 20 jaar ervaring in hands-on software ontwikkeling. Het leiden en coachen van agile development teams is zijn grote passie. LinkiT projects voert software ontwikkelingsprojecten uit van A tot Z. Hierbij maken we gebruik van agile projectmanagement methoden en ontwikkeltechnieken (Scrum, Lean, XP, Kanban). Daarmee garanderen we onze klanten, dat in onze projecten snel resultaten kunnen worden getoond en maximale business value wordt opgeleverd. We doen dit al vanaf de oprichting in 2001, en kunnen daarmee worden gezien als een van de pioniers op het gebied van agile software ontwikkeling in Nederland. Projecten voeren wij uit op basis van "time & materials", maar ook op basis van fixed date en/of fixed price. Hierbij maken wij bij voorkeur gebruik van OO-technologieën, zoals Java,.NET en Ruby/RAILS, waarin we ons de afgelopen jaren hebben gespecialiseerd. Uiteraard blijven wij continu op de hoogte van nieuwe ontwikkelingen in de markt. Naast projecten doen wij ook coaching en consultancy op het gebied van agile project management, agile methoden en technieken en software ontwikkeling in het algemeen. We helpen hierbij klanten te transformeren van de meer traditionele methoden naar een agile werkwijze. Tevens geven wij trainingen/workshops, en verzorgen wij presentaties op (internationale) conferenties op het gebied van agile projectmanagement en software ontwikkeling. LinkiT projects is onderdeel van de LinkiT enterprise. 11

Whitepaper. Kwaliteit binnen Agile

Whitepaper. Kwaliteit binnen Agile Whitepaper Kwaliteit binnen Agile Paul Meek pm@linkitprojects.nl Versie 1.0 (24-02-2010) Inleiding Agile is hot. Agile projecten beloven sneller software te leveren, die na elke iteratie onmiddellijk in

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

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

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

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

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

Scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum agileagileagileagileagileagileagileagil

Scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum agileagileagileagileagileagileagileagil Scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum agileagileagileagileagileagileagileagil eagileagileagileagileagileagileagileagi leagileagileagileagileagileagileagileag

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

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

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

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

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

AERIUS II. Mark Wilmot Product Owner AERIUS. Ministerie van EL&I Programma Directie Natura 2000 Programma Stikstof (PAS)

AERIUS II. Mark Wilmot Product Owner AERIUS. Ministerie van EL&I Programma Directie Natura 2000 Programma Stikstof (PAS) AERIUS II Mark Wilmot Product Owner AERIUS Ministerie van EL&I Programma Directie Natura 2000 Programma Stikstof (PAS) m.j.wilmot@mineleni.nl Inhoud Toelichting AERIUS II Project Demo Agile / Scrum proces

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

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

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

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

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

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

SCRUM METHODE.

SCRUM METHODE. SCRUM METHODE www.gladwell.nl bel ons 020-240 2244 WAT IS SCRUM? Scrum is een methode om effectief, kostenefficiënt, klant- en resultaatgericht te werken in teams. Met Scrum kunt u de principes van agile

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

Tool Ambitie Resultaat

Tool Ambitie Resultaat Tool Ambitie Resultaat Testautomatisering door eindgebruikers en regressietesten in de keten Praktijkvoorbeelden van Tosca Ferrie Wolff - Practice lead Tosca - Implementation Partner Tricentis ferrie.wolff@sogeti.com

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

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

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

Van testproces tot testvak... en verder

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

Nadere informatie

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

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

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

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

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

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

Kwaliteit en Testen binnen Agile Project Management volgens Scrum bij Planon. David Griffioen 11 april 2006

Kwaliteit en Testen binnen Agile Project Management volgens Scrum bij Planon. David Griffioen 11 april 2006 Kwaliteit en Testen binnen Agile Project Management volgens Scrum bij Planon David Griffioen april 2006 Agenda Planon Agile Scrum Scrum bij Planon Kwaliteit en Testen Planon Planon maakt productsoftware

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

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

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

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

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

Nadere informatie

[ SCRUM. ] Een introductie

[ SCRUM. ] Een introductie [ SCRUM. ] Een introductie [ SCRUM IN HET KORT. ] Scrum is een agile-proces, welke het mogelijk maakt om te focussen op het leveren van het beste resultaat in de kortst mogelijke tijd. Het maakt het mogelijk

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

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

Naar de cloud: drie praktische scenario s. Zet een applicatiegerichte cloudinfrastructuur op. whitepaper

Naar de cloud: drie praktische scenario s. Zet een applicatiegerichte cloudinfrastructuur op. whitepaper Naar de cloud: drie praktische scenario s Zet een applicatiegerichte cloudinfrastructuur op whitepaper Naar de cloud: drie praktische scenario s Veel bedrijven maken of overwegen een transitie naar de

Nadere informatie

Software Test Documentation

Software Test Documentation FACULTEIT INGENIEURSWETENSCHAPPEN & WE- TENSCHAPPEN DEPARTMENT OF COMPUTER SCIENCE AND APPLIED COMPUTER SCIENCE Software Test Documentation Software Engineering Nicolas Carraggi, Youri Coppens, Christophe

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

Februari juni Toelichting aanpak. Claudia Tjia GROEP F M42

Februari juni Toelichting aanpak. Claudia Tjia GROEP F M42 Februari juni 2016 Toelichting aanpak Claudia Tjia GROEP F M42 Dit document bevat informatie over het onderdeel SCRUM binnen de proftaak. SCRUM is de methode die wij als groep moesten hanteren om het project

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

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

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

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

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

De overstap naar Agile De overstap naar Agile

De overstap naar Agile De overstap naar Agile De overstap naar Agile De overstap naar Agile Wat als niet alleen de requirements veranderen, maar alles verandert? Inleiding Start project met waterval aanpak Overstap naar agile Hoe hebben we het gedaan?

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

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

fysieke beveiliging onder controle Fysieke beveiliging Lean & Agile Thimo Keizer

fysieke beveiliging onder controle Fysieke beveiliging Lean & Agile  Thimo Keizer fysieke beveiliging onder controle Fysieke beveiliging Lean & Agile www.fysiekebeveiliging.nl Thimo Keizer Fysieke beveiliging Lean & Agile 2016 www.fysiekebeveiliging.nl Thimo Keizer Niets uit deze uitgave

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

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

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

Auditen van Agile projecten

Auditen van Agile projecten Auditen van Agile projecten Platform voor Informatiebeveiliging 10 december 2013 Merijn van der Zalm & Marcel Trijssenaar Agenda Belang van assurance op agile ontwikkelen Agile versus Waterval Perspectief

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

Connect Social Business

Connect Social Business Connect Social Business Joey Kaan September 2014 Inhoudsopgave 1 Achtergronden 4 2 Probleemstelling & Doelstelling 5 2.1 Leren Professioneel Functioneren.................. 5 2.2 Facebook API leren door

Nadere informatie

Continuous testing in DevOps met Test Automation

Continuous testing in DevOps met Test Automation Continuous ing in met Continuous testing in met Marco Jansen van Doorn Tool Consultant 1 is a software development method that emphasizes communication, collaboration, integration, automation, and measurement

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

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

Factsheet KICKSTARTERS Mirabeau

Factsheet KICKSTARTERS Mirabeau Factsheet KICKSTARTERS Mirabeau KICKSTARTERS We lanceren binnen twee maanden een nieuw digitaal platform waarmee u in hoog tempo business value genereert. De digitale transformatie is in volle gang. Consumenten

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

Software Test Document

Software Test Document Software Test Document 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

Nadere informatie

Software Processen. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1. Het software proces

Software Processen. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1. Het software proces Software Processen Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1 Het software proces Een gestructureerd set van activiteiten nodig om een software systeem te ontwikkelen Specificatie;

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

React en React Native voor websites en apps

React en React Native voor websites en apps React en React Native voor websites en apps H A N S-PE T E R H ARMSEN HEEFT DI T GE SCH R E V EN IN APRI L 2017 Deze whitepaper is bedoeld voor product owners en beslissers. Hij gaat over React, een JavaScript

Nadere informatie

Quality Automation Day

Quality Automation Day Quality Automation Day Sogeti & TOSCA Praktijkvoorbeelden van TOSCA Ferrie Wolff Practice Lead TOSCA ferrie.wolff@sogeti.com 2 What s on the menu? Kennismaking TOSCA Overzicht opdrachten Verdieping in

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

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

PRODUCT OWNER.

PRODUCT OWNER. PRODUCT OWNER www.gladwell.nl bel ons 020-240 2244 PRODUCT OWNER Het wordt steeds gangbaarder: werken met de Scrum methode. Zeker in de IT maar ook bedrijven in andere sectoren omarmen deze praktische

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

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

Accelerate? Automate!

Accelerate? Automate! Accelerate? Automate! TA Flying Squad bij KPN Marco Jansen van Doorn Test Tool Consultant, Business Line Test Automation What s Cooking, Vianen, 24 mei 2016 Vraag & Antwoord Meer rendement uit testautomatisering?

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

1. Work Breakdown Structure en WBS Dictionary

1. Work Breakdown Structure en WBS Dictionary 1. Work Breakdown Structure en WBS Dictionary CUSTOMER migratie Management Technische Transitie Meetings Status Reporting Administratie Technisch Upgegrade Systemen (3-tier) Delta Analyse & Functioneel

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

Kwaliteit. 1. Introductie. Deel 1. Algemene Kennis

Kwaliteit. 1. Introductie. Deel 1. Algemene Kennis 1. Introductie Kwaliteit In deze module gaan we iets verder in op het begrip "kwaliteit". Het is de bedoeling om wat achtergrondinformatie te geven die van pas kan komen bij de andere modules. Kwaliteit

Nadere informatie

BeheerVisie ondersteunt StUF-ZKN 3.10

BeheerVisie ondersteunt StUF-ZKN 3.10 Nieuwsbrief BeheerVisie Nieuwsbrief BeheerVisie 2015, Editie 2 Nieuws BeheerVisie ondersteunt StUF-ZKN 3.10 BeheerVisie geeft advies MeldDesk App Message Router MeldDesk Gebruikers Forum Nieuwe MeldDesk

Nadere informatie

Vraag 1... Ieder risico in een risico analyse moet geschat worden voor wat betreft zijn impact... en zijn kans/propabiliteit...

Vraag 1... Ieder risico in een risico analyse moet geschat worden voor wat betreft zijn impact... en zijn kans/propabiliteit... Nota: Schrijf je antwoorden kort en bondig in de daartoe voorziene velden. Elke theorie-vraag staat op 2 en elke oefening op 8 punten. Het geheel staat op 40. Vraag 1... Ieder risico in een risico analyse

Nadere informatie

Whitepaper. Continuous Delivery [Auteur] Kenniscentrum De Smalle Zijde 39 3903 LM Veenendaal Tel. +31(0)318-50 11 19 Fax +31(0)318-51 83 59

Whitepaper. Continuous Delivery [Auteur] Kenniscentrum De Smalle Zijde 39 3903 LM Veenendaal Tel. +31(0)318-50 11 19 Fax +31(0)318-51 83 59 Whitepaper Continuous Delivery [Auteur] Hoofdkantoor Kruisboog 42 3905 TG Veenendaal Tel. +31(0)318-55 20 20 Fax +31(0)318-55 23 55 Kenniscentrum De Smalle Zijde 39 3903 LM Veenendaal Tel. +31(0)318-50

Nadere informatie

ilealignment.nl Camberwell Organisatie Advies

ilealignment.nl Camberwell Organisatie Advies ilealignment.nl Camberwell Organisatie Advies Specialisme AgileAlignment.nl is Agile specialist op het gebied van: Inrichting van de sturing Het optimaliseren van de sturing aan Agile teams en kwaliteitsborging

Nadere informatie

1. De methodiek Management Drives

1. De methodiek Management Drives 1. De methodiek Management Drives Management Drives is een unieke methodiek die u concrete handvatten biedt in het benaderen van de ontwikkeling van individu, team en organisatie. De methodiek kent een

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

EXIN Agile Scrum Foundation

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

Nadere informatie

Kickstart Architectuur. Een start maken met architectuur op basis van best practices. Agile/ TOGAF/ ArchiMate

Kickstart Architectuur. Een start maken met architectuur op basis van best practices. Agile/ TOGAF/ ArchiMate Kickstart Architectuur Een start maken met architectuur op basis van best practices. Agile/ TOGAF/ ArchiMate Context schets Net als met andere capabilities in een organisatie, is architectuur een balans

Nadere informatie

Connect Social Business. Plan van Aanpak voor mijn stage bij ConnectSB

Connect Social Business. Plan van Aanpak voor mijn stage bij ConnectSB Connect Social Business Plan van Aanpak voor mijn stage bij ConnectSB Joey Kaan September 21, 2014 Inhoudsopgave 1 Achtergronden 4 2 Probleemstelling & Doelstelling 5 2.1 Leren Professioneel Functioneren..................

Nadere informatie

13. De ideale product owner

13. De ideale product owner WHITEPAPER IN 5 MINUTEN D E C E M B E R 2 0 1 4 13. De ideale product owner In onze whitepaper over scrum (http://www.oberon.nl/whitepaper/11_scrum/) beschreven we kort de scrum methodiek zoals we die

Nadere informatie

XP Extreme Programming. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

XP Extreme Programming. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. XP Extreme Programming Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 10 Inhoudsopgave 1. INLEIDING...3 2. EXTREME PROGRAMMING...4 3. FASERING...5

Nadere informatie

Agile buiten de IT. Bent u al onbewust bekwaam met agile? Bert Leibbrand bert.leibbrand@itri.nl +31 6 27 74 60 88

Agile buiten de IT. Bent u al onbewust bekwaam met agile? Bert Leibbrand bert.leibbrand@itri.nl +31 6 27 74 60 88 Agile buiten de IT Bent u al onbewust bekwaam met agile? Bert Leibbrand bert.leibbrand@itri.nl +31 6 27 74 60 88 Agenda Overzicht Agile: een hype? Agile termen Planningpoker: zelf ervaren Samenvatten Volgende

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

De juiste requirements juist

De juiste requirements juist De juiste requirements juist Een voorwaarde voor succesvolle applicatie ontwikkeling Arno van Herk Managing partner Synergio B.V. a.van.herk@synergio.nl 2011 Een brug naar onze presentatie Uniface is Compuware's

Nadere informatie

Reports of my death are greatly exaggerated

Reports of my death are greatly exaggerated Reports of my death are greatly exaggerated Tim Koomen, Bart Broekman TestNet voorjaar 2017 Ken de context! James Whittaker 2011- diverse conferenties: GTAC STAR-west EuroSTAR 1 Something s happening Enkele

Nadere informatie

GETTING THE BEST OUT OF YOUR SOURCE CODE FIT TEST VOOR UNIFACE

GETTING THE BEST OUT OF YOUR SOURCE CODE FIT TEST VOOR UNIFACE GETTING THE BEST OUT OF YOUR SOURCE CODE FIT TEST VOOR UNIFACE 2 DIGITALISATIE VEREIST: Toegevoegde waarde Agility en snelheid Security en betrouwbaarheid 3 COMBINATIE BUSINESS & IT BUSINESS TECHNOLOGY

Nadere informatie

Connect Social Business. Plan van Aanpak voor mijn stage bij ConnectSB

Connect Social Business. Plan van Aanpak voor mijn stage bij ConnectSB Connect Social Business Plan van Aanpak voor mijn stage bij ConnectSB Joey Kaan September 28, 2014 Inhoudsopgave 1 Achtergronden 1 2 Probleemstelling & Doelstelling 2 2.1 Leren Professioneel Functioneren..................

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