TMAP EN RATIONAL UNIFIED PROCESS

Maat: px
Weergave met pagina beginnen:

Download "TMAP EN RATIONAL UNIFIED PROCESS"

Transcriptie

1 TMAP EN RATIONAL UNIFIED PROCESS Auteur T. Koomen, M. Tolsma Versie 1.1 Plaats Rotterdam Kenmerk

2 VERSIE INFORMATIE Versie Datum Bijzonderheden Auteur augustus 2003 Eerste concept T. Koomen, M. Tolsma 0.5 oktober 2003 Commentaar interne reviews verwerkt T. Koomen, M. Tolsma 1.0 november 2003 Commentaar interne en externe reviews T. Koomen, M. Tolsma verwerkt januari 2004 Definitief T. Koomen, M. Tolsma Copyright Sogeti Nederland B.V. te Diemen Niets uit deze uitgave mag verveelvoudigd en/of openbaar worden gemaakt (voor willekeurig welke doeleinden) door middel van druk, fotokopie, microfilm, geluidsband, electronisch of op welke andere wijze dan ook zonder voorafgaande schriftelijke toestemming van Sogeti Nederland B.V.. Dit rapport is enkel en alleen bedoeld voor intern gebruik voor hierboven genoemd(e) bedrijf/bedrijven. Sogeti Nederland B.V. 1.1 II

3 INHOUDSOPGAVE VERSIE INFORMATIE...II INHOUDSOPGAVE INLEIDING RUP Best practices Fases Disciplines TESTEN IN RUP Master Test Plan en Iteration Test Plan Unit Test (UT) Integratietest (IT) Systeemtest(ST) Acceptatietest (AT) Reviews Rollen TOEPASSING TMAP BIJ RUP Mastertestplan Fasering Planning & Beheer Voorbereiding Specificatie Uitvoering Afronding Organisatie Technieken Teststrategie Testspecificatietechnieken Infrastructuur Acceptatietest LITERATUUR BIJLAGE A, MASTERTESTPLAN VOLGENS RUP EN TMAP BIJLAGE B, DETAILVERGELIJKING RUP EN TMAP TESTACTIVITEITEN BIJLAGE C, VERGELIJKING TMAP PRODUCTEN MET RUP ARTIFACTS Sogeti Nederland B.V. 1.1 pagina 1

4 1 INLEIDING Rational Unified Process (afgekort: RUP) 1 is een belangrijke en populaire systeemontwikkelingmethodiek, die wereldwijd op een groot aantal plaatsen gebruikt wordt. RUP besteedt specifiek aandacht aan testen, maar dat wil niet zeggen dat dit de tester alle handvatten biedt om het testproces in te richten. In de praktijk hanteren testers daarom vaak de eigen testmethodiek die ze inpassen in RUP als vervanging van het testproces volgens RUP. In deze toepassingsvariant wordt de inpassing van één van de bekendste testmethodieken, namelijk TMap 2, op de RUP 2002-versie besproken. Hiermee komen we tegemoet aan een veelgehoorde vraag uit de praktijk. Een belangrijke vraag is natuurlijk of het echt nodig is om het testen zoals in RUP beschreven is, aan te vullen met TMap. Testen in een systeemontwikkelingmethodiek als RUP is zeker niet onderbelicht. RUP erkent het grote belang van goed testen, hanteert als één van de best practices kwaliteitsverificatie gedurende de hele levenscyclus, besteedt een aparte workflow aan testen en heeft nog in 2002 de test workflow geactualiseerd. Hoe gek het ook mag klinken, deze duidelijke aandacht voor testen is juist de reden voor dit document. Andere systeemontwikkelingmethodieken volstaan nogal eens met het benoemen van de testsoorten, schrijven voor dat er een plan gemaakt moet worden, daarna de testgevallen gespecificeerd die vervolgens worden uitgevoerd. Wanneer testen zo globaal is beschreven kan als testaanpak simpelweg TMap toegepast worden, zonder dat veel nagedacht hoeft te worden over hoe het past binnen de systeemontwikkelingmethodiek. Bij RUP met haar vrij gedetailleerde aanwijzingen voor testen ligt dit anders. Toch heeft de toepassing van TMap in veel situaties toegevoegde waarde in een RUPproject. De redenen hiervoor zijn dat: TMap als testaanpak diepgaand en compleet is terwijl testen binnen RUP één van diverse aspecten is. De diepgang van een volledige methodiek, met uitwerkingen voor alle aandachtsgebieden van testen, zoals bijvoorbeeld techniekbeschrijvingen, kan hier niet gehaald worden; TMap is de standaard in veel organisaties, de mensen zijn er al mee bekend en in getraind en standaard materialen zijn beschikbaar. Wanneer in deze organisaties een RUP-project start, wil men uit oogpunt van efficiëntie zoveel mogelijk de bekende testmanier hierop toepassen; In de 2002-versie is het testen binnen RUP moeilijker toepasbaar, met name indien men niet kiest voor Exploratory Testing. Workflow details, activiteiten en rollen zijn flink uitgebreid, maar de samenhang hiertussen is moeilijk te doorgronden voor mensen die hun testervaring hebben opgedaan met een meer conventionele testaanpak. Wat we in deze toepassingsvariant niet bespreken, is het ingaan op de testuitdagingen van iteratieve systeemontwikkeling in het algemeen. Wil de lezer hier meer informatie over, dan wordt verwezen naar de icbd-variant voor TMap [Koomen 2002]. De inpassing van TMap in RUP beperkt zich tot de RUP Test Discipline. Het betreft dus alleen de systeemtest en niet de unit, integratie- of acceptatietests. Deze tests hebben binnen RUP te weinig detailbeschrijving om een zinvolle mapping te maken. Wil men meer "vlees om het been" van deze tests, dan kan TMap gebruikt worden. Voor de Sogeti Nederland B.V. 1.1 pagina 2 1 Rational Unified Process is a trademark or registered trademark of IBM Rational Software Corporation 2 TMap is een gedeponeerd handelsmerk van Sogeti Nederland B.V.

5 unit en integratietest kan de white-box fasering van TMap toegepast worden, de acceptatietest komt verderop nog aan de orde. De feitelijke inpassing van TMap in de RUP Test Discipline betreft de volgende zaken: - Mastertestplan Het mastertestplan van TMap is vergelijkbaar met dat van RUP. - Fasering De TMap fasering met bijbehorende activiteiten wordt voor elke RUP iteratie doorlopen. Per TMap-fase is aangegeven wat de activiteiten zijn en met welke RUP workflow / activiteit deze overeenkomen. Ook is beschreven wat aanvullende TMap- of juist RUP-testactiviteiten zijn. De overeenkomstige activiteiten van TMap en RUP zijn gewoonlijk in meer detail beschreven in TMap. Daarnaast is een vergelijking opgenomen van de TMap-producten en de RUP-artifacts. - Organisatie De RUP rollen test manager, test analist en tester komen in grote lijnen overeen met de twee TMap-beschrijvingen voor testmanager en tester. Hierbij heeft de RUP-rol van test analyst een deel van de taken van de TMap-testmanager en de tester, namelijk het bepalen welke tests uitgevoerd moeten worden, deze (logisch) te ontwerpen en de resultaten van de testuitvoering te evalueren. De RUP rol van test designer definieert en implementeert de testaanpak, inclusief technieken, tools en procedures. In deze rol ligt de nadruk op testautomatisering. Min of meer vergelijkbare TMap-rollen zijn methodische ondersteuning en de TAKT-architect. - Technieken Binnen TMap zijn diverse technieken uitgewerkt, zoals strategiebepaling, testpuntanalyse, detailintake testbasis en vele testspecificatietechnieken en checklists. Deze technieken zijn niet in RUP beschreven maar zijn zonder meer toepasbaar in RUP-testprojecten. In de toepassingsvariant zijn een aantal RUPspecifieke aanvullingen gegeven op de teststrategiebepaling en de testspecificatietechnieken. - Infrastructuur De TMap-pijler infrastructuur betreft de testomgeving, tools en de werkplek. In RUP is enkel de ondersteuning door tools specifiek gemaakt. IBM Rational biedt diverse tools die het testproces ondersteunen; het automatiseren mag echter geen doel op zich of vanzelfsprekendheid zijn. Met name het automatiseren van functionaliteitstesten met het record&playback tool Robot dient zorgvuldig overwogen te worden. De belangrijkste overwegingen zijn benoemd. - Acceptatietest Hoewel geen onderdeel van de RUP Test Discipline, is het gebrek aan voorschriften voor de AT binnen RUP aanleiding hier nader op in te gaan. Er worden twee alternatieven voor de AT aanbevolen: - het volledig organiseren en structureren van de AT conform TMap, resulterend in een min of meer éénmalige, zelfstandige AT aan het eind van het ontwikkeltraject tijdens de Transition fase. - het organiseren en structureren van de AT conform de ST en TMap, resulterend in een iteratieve AT die volgend op de ST binnen elke iteratie wordt uitgevoerd. Deze RUP-toepassingsvariant is tot stand gekomen met hulp van de Sogeti-werkgroep "TMap en RUP", met speciale dank aan Fedor Janssen, Richard Hakvoort, Loek Wilhelmus, Wim Bos, André van Pelt en Rob Baarda. Daarnaast is belangrijke input geleverd door Chris Dugardyn, testconsultant van IBM Rational, Cees Dulfer van Rabobank en Harry Kobes van PANalytical. Sogeti Nederland B.V. 1.1 pagina 3

6 Omdat het een toepassingsvariant betreft, wordt bij de lezer kennis van zowel TMap als (in mindere mate) RUP bekend verondersteld. Rotterdam, januari 2004 Tim Koomen en Mark Tolsma Sogeti Nederland B.V. 1.1 pagina 4

7 2 RUP Dit hoofdstuk beschrijft de filosofie en structuur van IBM s Rational Unified Process, of RUP, op hoofdlijnen. Het is een generieke en flexibele methodiek voor iteratieve softwareontwikkeling. RUP is generiek genoeg om toegepast te kunnen worden in een grote diversiteit van software producten en projecten, zowel in omvang als applicatie domein. RUP is wereldwijd een zeer bekende methodiek voor iteratieve softwareontwikkeling. 2.1 Best practices De methodiek is gebaseerd op een aantal best practices die vaak voorkomende problemen in softwareontwikkeling moeten voorkomen: 1. Iteratief ontwikkelen Gezien de toenemende complexiteit van huidige software systemen is het niet meer mogelijk opeenvolgend eerst het gehele probleem te definiëren, de gehele oplossing te ontwerpen, de software te bouwen en tenslotte het eindproduct te testen. Een iteratieve aanpak is nodig die een toenemend begrip van het probleem mogelijk maakt door opeenvolgende verbeteringen en verfijningen én om een effectieve oplossing incrementeel te laten groeien gedurende meerdere iteraties. Elke iteratie is begrensd in de tijd, adresseert de voor die iteratie grootste technische risico s en wordt afgesloten met een werkbare release. Hiermee blijft de focus van het ontwikkelteam op het opleveren van resultaten en wordt de projectvoortgang beter aantoonbaar. 2. Managen van requirements Dit is het proces van het loskrijgen, organiseren en documenteren van de aan het systeem gestelde eisen, inclusief het traceren en documenteren van afwegingen en beslissingen. Het gebruik van use cases heeft bewezen een goede manier te zijn om functionele requirements vast te leggen en om te garanderen dat deze het design, bouw en test sturen. 3. Gebruik van componenten architectuur RUP ziet een component als een module, groep programma's of subsysteem met een duidelijke functie. Een op componenten gebaseerde architectuur verkleint de omvang en complexiteit van het systeem. Met een dergelijke architectuur is het systeem stabieler, goedkoper en worden de aan grote omvang en complexiteit gerelateerde risico's verkleind. 4. Visueel modelleren Een model is een versimpeling van de werkelijkheid vanuit een bepaald perspectief. Met visueel modelleren, bijvoorbeeld met Unified Modeling Language (UML), kan een beter begrip worden verkregen van en kan beter gecommuniceerd worden over structuur en gedrag van architecturen en componenten. Feitelijk is UML een verzameling modelleringstechnieken, waarvan use case en class diagrams de bekendste zijn. Het gebruik van tools versterkt de voordelen van het gebruik van een model en biedt bijvoorbeeld de mogelijkheid om details indien gewenst te verbergen. 5. Kwaliteitsverificatie gedurende gehele levenscyclus De kwaliteit van het systeem is niet iets dat aan het einde van het ontwikkelingstraject vastgesteld wordt, maar moet gedurende het gehele traject continu plaatsvinden door middel van testen en toetsen. Het vaststellen van de kwaliteit is een integraal onderdeel van RUP, in alle activiteiten, waarbij alle deelnemers zijn betrokken. 6. Beheersing van veranderingen in de software Het vermogen om veranderingen te beheersen, om vast te stellen dat Sogeti Nederland B.V. 1.1 pagina 5

8 veranderingen acceptabel zijn, en om veranderingen te kunnen traceren is essentieel in een omgeving waar veranderingen onvermijdelijk zijn. 2.2 Fases De iteratieve manier van ontwikkelen is binnen RUP georganiseerd in een viertal fases, waarbij elke fase uit één of meerdere iteraties kan bestaan: 1. Inception In deze fase wordt de visie op een potentieel product uitgewerkt en vertaald in eisen voor een werkelijk project. Het doel is de business case voor een nieuw product of een grootschalige update en de scope van het project vast te stellen. Belangrijkste resultaat van deze fase is de go-no go beslissing om de volgende fase in te gaan. 2. Elaboration Het doel van deze fase is het diepgaander analyseren van het probleemdomein en het definiëren en stabiliseren van de architectuur. In deze fase wordt een uitvoerbaar prototype van de architectuur (baseline) gebouwd in één of meerdere iteraties afhankelijk van scope, omvang, risico en noviteit van het project. Dit evolutionaire prototype met code van productiekwaliteit adresseert ten minste de belangrijkste use cases zoals geïdentificeerd in de Inception fase en adresseert de technische risico-elementen van het project die het hoogst geclassificeerd zijn. Aan het eind van deze fase is wederom een go-no go beslissing om de volgende fase in te gaan. De hieraan ten grondslag liggende plannen moeten gedetailleerd genoeg zijn, en de risico s voldoende onder controle om met nauwkeurigheid de kosten en tijdplanning voor de afronding van de systeemontwikkeling vast te stellen. 3. Construction In deze fase, die uit meerdere iteraties bestaat, wordt de architectuur baseline verder uitgewerkt waarbij het eindproduct in een aantal stappen of incrementen geleidelijk ontstaat. Tijdens elke iteratie worden de artifacts van de Elaboration fase (o.a. use cases en software) uitgebreid en herzien/verbeterd, waarbij deze uiteindelijk stabiliseren als het systeem evolueert qua volledigheid en correctheid. 4. Transition In deze fase wordt het product overgedragen aan de eindgebruikers. Het betreft hier o.a. issues zoals marketing, packaging, installatie, configuratie, training en acceptatietesten, inclusief het oplossen van bevindingen uit deze test. De fase is afgerond wanneer de eindgebruikers het product accepteren. Binnen elke fase wordt het werk in de vorm van door tijd begrensde (time boxes) iteraties uitgevoerd. Binnen elke iteratie worden diverse activiteiten parallel uitgevoerd, waarbij een uitgevoerde activiteit altijd resulteert in bepaalde producten (artifacts genaamd in RUP). 2.3 Disciplines Systeemontwikkeling binnen RUP is ook georganiseerd volgens bepaalde disciplines. Een discipline bestaat uit een workflow, activiteiten, rollen en artifacts. De activiteiten vinden binnen elke fase plaats, waarbij het zwaartepunt verschuift. Zo ligt bijvoorbeeld het zwaartepunt van de workflow business modeling in de inception fase en het zwaartepunt van deployment in de transition fase. De volgende disciplines worden in RUP onderscheiden. Discipline Beschrijving Sogeti Nederland B.V. 1.1 pagina 6

9 Discipline Core engineering Business modeling Requirements Analysis & design Implementation Test Deployment Core supporting Project management Configuration and change management Environment Beschrijving Het ontwikkelen van een visie voor de nieuwe of aangepaste organisatie, inclusief processen, rollen en verantwoordelijkheden. Vaststellen en beheersen van de gedetailleerde eisen aan het systeem, o.a. in de vorm van een use-case model. Het op basis van architectuur en eisen ontwerpen van het te bouwen systeem. Het bouwen van het systeem, inclusief het testen van losse programma's en componenten. Het integratietesten en systeemtesten van het systeem. Het implementeren van het systeem. Hieronder vallen zaken als het acceptatietesten van het systeem, bètatesten, distributie en installatie van de software, conversie van de data en training van de gebruikers. Planning, risicobeheersing en voortgangsbewaking. Het bewaken en beheren van (de integriteit van) de opgeleverde producten. Het ondersteunen van het ontwikkelteam met tools, infrastructuur en procedures. De verhouding tussen fasen, disciplines en relatieve inspanning wordt in onderstaande figuur weergegeven. Figuur 1, Fasen en Disciplines (copyright IBM Rational) De maker van RUP, IBM Rational, biedt een grote verzameling tools die naadloos integreren met RUP. Ook voor het testen zijn specifieke tools beschikbaar. Meer informatie hierover kan gevonden worden op de website van IBM Rational, Sogeti Nederland B.V. 1.1 pagina 7

10 3 TESTEN IN RUP RUP ziet testen als een belangrijk onderdeel van de systeemontwikkeling. Het vijfde basisprincipe, kwaliteitsverificatie gedurende gehele levenscyclus, stelt dat in principe alle ontwikkelactiviteiten en artifacts op kwaliteit gecontroleerd moeten worden door middel van testen of toetsen. Hiermee is testen niet slechts een fase na de bouw. Ook is een aparte discipline aan testen gewijd. Deze is van toepassing op het systeemtesten, hier legt RUP het zwaartepunt van testen. Tot 2002 lag de nadruk van testen in RUP op het tamelijk conventioneel plannen, specificeren en uitvoeren van de testen, met veel nadruk op testautomatisering. In de 2002-versie heeft IBM Rational echter een grote aanpassing gedaan op de discipline Testing. De 2002-versie laat een verschuiving zien naar een aanpak op basis van exploratory testing. Het leren van het systeem en het bedenken en uitvoeren van de tests verloopt hierbij simultaan. De (globale) gedachte hierachter is dat testen minder nadruk moet leggen op het tijdrovende bedenken en uitschrijven van testgevallen op basis van systeemdocumentatie, die vaak toch weer wijzigt. Het bedenken en uitvoeren van tests kan volgens deze redenering het beste plaatsvinden wanneer de software is opgeleverd. Ook moet niet enkel tegen de systeemdocumentatie worden getest. Testguru's als James Bach, Cem Kaner en Brian Marick hangen deze school van denken aan. Meer informatie over exploratory testing is te vinden op Voor de relatie tussen TMap en exploratory testing wordt verwezen naar [Koomen 2003]. RUP hanteert voor de testaanpak de volgende principes [Szymkowiak, Kruchten 2003]: Iteratief ontwikkelen Testen vindt gedurende de gehele iteratieve ontwikkelingscyclus plaats, maar telkens met een ander doel, in RUP de mission genoemd. Zo kan testen in de elaboration fase bijvoorbeeld gericht zijn op validatie van de architectuur en in de construction fase op het vinden van de belangrijkste fouten in de software. Minimale documentatie vooraf Er moet vooral niet meer testdocumentatie geproduceerd worden dan nodig is. Het mastertestplan en een gedetailleerde testplanning per iteratie is feitelijk het enige dat vóóraf wordt opgeleverd. Holistische aanpak Holistisch is het zoeken naar relaties tussen alle aspecten van een probleem of zorg. Bij RUP wordt bedoeld dat de testbasis niet enkel uit de specificaties wordt gehaald, maar uit een verzameling van bronnen, ook niet-gedocumenteerde. Automatisering Tools kunnen helpen bij de diverse testactiviteiten. RUP kent vier testsoorten, de unit test, de integratietest, de systeemtest en de acceptatietest. De testsoorten kunnen via een Master Test Plan (op projectniveau) en een Iteratie Test Plan (voor de iteratie) worden gecoördineerd. 3.1 Master Test Plan en Iteration Test Plan RUP hanteert een Master Test Plan voor het totale project en een Iteration Test Plan per iteratie. De Test Manager stelt een Master Test Plan op tijdens de Inception phase. Hoewel geïnitieerd vanuit de systeemtest heeft het plan in beide gevallen de mogelijkheid om ook andere testsoorten dan de systeemtest te betrekken en zodoende op elkaar af te stemmen. Zo kan bijvoorbeeld worden afgestemd dat Sogeti Nederland B.V. 1.1 pagina 8

11 performance aspecten alleen in de systeemtest worden belegd. Beide plannen vertonen grote overeenkomsten wat betreft de inhoud, enkel de scope en de mate van detaillering verschilt. Een project kan ervoor kiezen om het Iteratie Test Plan te integreren met het Iteratie Plan. In dat laatste geval bestaat de testbijdrage dan primair uit het aangeven welke requirements in de betreffende iteratie qua test worden ontworpen en uitgevoerd. Daarnaast worden andere testactiviteiten die relevant zijn voor deze iteratie toegelicht, waarbij kan worden gedacht aan het selecteren van specifieke test tools of het uitwerken van bepaalde richtlijnen. 3.2 Unit Test (UT) Unit Testing vindt plaats op de kleinst testbare eenheden (units) van de software. Unit Testing betreft het testen van de interne structuur zoals logica en dataflow én het testen van de functies en het extern zichtbare gedrag van de unit. Unit Testing is in RUP expliciet belegd bij de rol Implementer, die daartoe in elke iteratie voor elke nieuwe of gewijzigde unit de activiteiten Implement Test Components and Subsystems en Perform Unit Tests uitvoert. Testen is daarmee een integraal onderdeel van de activiteiten van deze rol. Hoewel RUP zelf een aantal richtlijnen bevat voor de Unit Tests, is er geen artifact benoemd waar de projectspecifieke richtlijnen moeten worden vastgelegd. Dit is in tegenstelling tot bijvoorbeeld de richtlijnen voor Design en het modelleren van Use Cases. Het beste kunnen deze richtlijnen opgenomen worden in de Programming Guidelines, omdat daar de overige richtlijnen voor de rol Implementer al zijn opgenomen. Het opstellen en handhaven van de richtlijnen is de gezamenlijke verantwoordelijkheid van de Process Engineers en dient consistent te zijn met het Master Testplan. Voor de Unit Test worden één of meerdere test tools ingezet. IBM Rational levert specifiek voor de Unit Test de tools: Robot (record&playback functionaliteit), Purify (detecteren van oorzaken van run-time errors), Quantify (detecteren van performance bottlenecks) en PureCoverage (vaststellen van code coverage). Er zijn echter ook andere mogelijkheden zoals het freeware JUnit dat in de Java wereld veel wordt toegepast om de functionele werking van units te testen. De uiteindelijke selectie is afhankelijk van de te testen requirements. Als performance daar bijvoorbeeld niet bij hoort, dan is daar ook geen tool voor nodig. 3.3 Integratietest (IT) Integratietesten vindt plaats om vast te stellen dat de software componenten correct functioneren als deze worden gecombineerd om een use case uit te voeren. De Implementer levert zijn unit geteste component op aan de Integrator, die deze vervolgens combineert tot intermediate builds. De stapsgewijze integratie van componenten vindt bottom-up plaats overeenkomstig de volgorde zoals vastgelegd in het integration build plan. Na elke stap maakt de integrator een intermediate build die wordt opgeleverd voor het uitvoeren van een integratietest. Doel is om vast te stellen dat de componenten die worden toegevoegd compatibel zijn met de reeds geïntegreerde componenten. Hiertoe wordt vaak een subset van de testen zoals geconcretiseerd in het integration build plan uitgevoerd. Deze stapsgewijze aanpak maakt het mogelijk problemen te isoleren en te analyseren Sogeti Nederland B.V. 1.1 pagina 9

12 RUP geeft aan dat de Integratietests worden uitgevoerd door de rol Tester, die afhankelijk van de omvang van de integratieactiviteiten kan worden gecombineerd met de rol Integrator. In de praktijk worden uit efficiëntieoogpunt beide rollen vaak door dezelfde persoon vervuld. Dit houdt in dat de Integrator tevens de integratietests uitvoert als integraal onderdeel van zijn activiteiten. Ten aanzien van richtlijnen en tools geldt voor de integratietest hetzelfde als voor de unit test. Enig verschil is dat de richtlijnen voor de integratietest niet logischerwijs in de programming guidelines worden opgenomen, maar dat de test guidelines of de opeenvolgende integration build plannen ook kandidaat zijn. De testmanager moet dit afstemmen met de andere process engineers. 3.4 Systeemtest(ST) De systeemtest wordt uitgevoerd als de sofware als één geheel functioneert, dus na de integratie(test) van de diverse componenten. Binnen een iteratie kunnen meerdere builds worden opgeleverd. Elke build ondergaat in principe de systeemtest, tenzij anders afgesproken in het iteratietestplan. Het mastertestplan en meer concreet het iteratietestplan geven aan op welke aspecten de build moet worden getest. Voor de systeemtest is in RUP de Test Discipline onderkend. Default workflow, activiteiten, artifacts, rollen en dergelijke zijn daar in detail beschreven. Sogeti Nederland B.V. 1.1 pagina 10

13 Figuur 2, Default workflow Test (copyright IBM Rational) Bovenstaande figuur toont de default workflow Test voor een iteratie in RUP. Afhankelijk van de situatie kunnen hier variaties op gemaakt worden. Deze workflow bestaat uit een aantal stappen, de zogenaamde workflow details. Voor de Test workflow zijn dit Evaluate, Verify test approach, Validate Build Stability, Test and Evaluate, Achieve Acceptable en Improve Test Assets. Elk workflow detail bestaat uit een aantal activiteiten, de output van deze activiteiten zijn artifacts (producten). Hierbij kan dezelfde activiteit in meerdere workflow details terugkomen. Zo komt de activiteit "Identify test ideas" voor in Define Evaluation, Test and Evaluate, Achieve Acceptable en Improve Test Assets. Wel heeft de context van het workflow detail invloed op hoe de uitvoering van een activiteit geïnterpreteerd moet worden. In de Development Case en het Software Development Plan wordt voor elk project aangegeven op welke wijze invulling wordt gegeven aan de verschillende Disciplines, dat wil zeggen welke subset van activiteiten en artifacts worden geselecteerd, welke rollen worden onderkend en met wie die worden ingevuld. Dit geldt ook voor de Test Sogeti Nederland B.V. 1.1 pagina 11

14 Discipline. De persoon met de rol van Test Designer bepaalt deze richtlijnen voor testen. De rol Test Manager is verantwoordelijk voor het uitvoeren van de systeemtest binnen het project conform de opgestelde richtlijnen en stuurt als zodanig de testrollen aan (wie, wat, wanneer). Andere rollen zijn Test Analyst en Tester. Van elke rol zijn de verantwoordelijkheden, benodigde vaardigheden en mogelijke bemensing (waaronder het combineren van testrollen) beschreven. Voor ieder project dienen alle testrollen in voldoende mate (kwalitatief en kwantitatief met significante overlap) ingevuld te zijn, waarbij het mogelijk is dat personen delen van of juist meerdere testrollen vervullen en/of in meerdere projecten acteren. Voor de systeemtest kunnen meerdere test tools worden ingezet. Van IBM Rational betreft het hier de tools Testmanager (plannen, managen en rapporteren over tests), Robot (record&playback functionaliteit) en ClearQuest (beheer van defects en changes). Indien de requirements ten aanzien van performance aanleiding geven tot een afzonderlijke performancetest, dan kan het nodig zijn daar nog een specifiek tool voor te selecteren. Als integraal onderdeel van het systeemontwikkelteam wordt bij de systeemtest ook intensief gebruik gemaakt van de tools RequisitePro (track&trace van requirements waaronder test cases) en ClearCase (configuratiebeheer). 3.5 Acceptatietest (AT) De acceptatietest is de laatste test voorafgaande aan het in productie nemen van de software. Het doel is te verifiëren dat de software daar klaar voor is én door de eindgebruikers kan worden gebruikt om de taken en functies uit te voeren waarvoor de software was bedoeld. De AT is gepositioneerd tijdens de Transition Phase en onderdeel van de Deployment discipline. RUP definieert de AT onvoldoende, feitelijk slechts als een herhaling van een subset van de ST-testgevallen. De tester moet deze uitvoeren in een productielike omgeving. Van belang is om in de AT rekening te houden met het artifact Product Acceptance Plan. De projectmanager stelt dit op tijdens de Inception phase van het project. Relevante onderwerpen voor de AT zijn onder andere acceptatiecriteria, te accepteren artifacts en evaluatiemethoden. RUP geeft weinig aanwijzingen voor in te zetten tools. Afhankelijk van hoe de AT wordt ingericht, kunnen dezelfde tools als bij de ST worden gebruikt. 3.6 Reviews Zoals uit het vijfde basisprincipe blijkt, ziet RUP kwaliteitsverificatie als iets dat gedurende de hele systeemontwikkeling plaatsvindt. Naast testen betekent dit ook quality assurance. Er wordt een Quality Assurance Plan gemaakt als onderdeel van het System Development Plan, met name voor de bewaking van de processen. Daarnaast is het reviewen goed uitgewerkt, met drie rollen: review coordinator, management reviewer en technical reviewer. De review coordinator regelt en stuurt het reviewproces, de management reviewer inspecteert met name de projectplannen en - verslagen, de technical reviewer de eigenlijke systeemontwikkelingsproducten als business use-case model, business analysis model, requirements, architecture, design en code. In dit document blijft het reviewen verder buiten beschouwing. 3.7 Rollen Van elke rol zijn de verantwoordelijkheden, benodigde vaardigheden en mogelijke bemensing (waaronder het combineren van testrollen) beschreven. Voor ieder project dienen alle testrollen in voldoende mate (kwalitatief en kwantitatief met significante Sogeti Nederland B.V. 1.1 pagina 12

15 overlap) ingevuld te zijn, waarbij het mogelijk is dat personen delen van of juist meerdere testrollen vervullen en/of in meerdere projecten acteren. Sogeti Nederland B.V. 1.1 pagina 13

16 4 TOEPASSING TMAP BIJ RUP In dit hoofdstuk wordt beschreven hoe de fasen en activiteiten van TMap ingepast kunnen worden in RUP. Hierbij wordt aangesloten op het testen volgens RUP zoals beschreven in de Test Discipline. Dit betreft dus alleen de systeemtest en niet de unit, integratie- of acceptatietests. Zoals in het voorgaande hoofdstuk is beschreven, hebben deze tests binnen RUP te weinig detailbeschrijving om een zinvolle mapping te maken. Wil men meer "vlees om het been" van deze tests, dan kan TMap gebruikt worden. Voor de unit en integratietest kan de white-box fasering van TMap toegepast worden, voor de acceptatietest wordt verwezen naar paragraaf Mastertestplan Het mastertestplan van TMap is vergelijkbaar met het Master Test Plan van RUP. Wel omvat de scope van een TMap mastertestplan in principe meerdere testsoorten, terwijl dat bij RUP ook enkel de systeemtest kan zijn. Extra in TMap's mastertestplan is de expliciete teststrategie met een bewuste keuze welke kwaliteitsattributen getest worden en met welke testtechnieken. Het RUP-testplan onderscheidt entry- en exitcriteria voor de verschillende tests. Entry-criteria zijn vergelijkbaar met TMap's randvoorwaarden, de exitcriteria zijn extra ten opzichte van standaard TMap, maar zijn bij een van tevoren afgesproken teststrategie minder nodig. In bijlage A worden de inhoudsopgaves van een RUP MTP en een TMap MTP vergeleken. 4.2 Fasering In deze paragraaf wordt de TMap-fasering doorlopen en wordt deze gerelateerd aan de default workflow voor de Test Discipline (zie ook in paragraaf 3.4 voor het schema hiervan). Voorbereiding intake specificaties toewijzen technieken Planning en Beheer initiatie en studie bepaling teststrategie risicotaxatie testbegroting inrichten organisatie opstellen testplan voortgang & beheer rapportage Specificatie specificeren testgevallen realiseren infrastructuur V S U A P&B pretest (her-)testen controleren beoordelen conserveren testware evalueren Uitvoering Afronding Figuur 3, TMap fasering met een beknopt overzicht van de activiteiten Deze workflow wordt per iteratie doorlopen. Per TMap-fase wordt aangegeven wat de activiteiten zijn en in welke RUP workflow deze het beste uitgevoerd kunnen worden. Ook is beschreven wat aanvullende TMap- of juist RUP-testactiviteiten zijn. De overeenkomstige activiteiten van TMap en RUP zijn gewoonlijk in meer detail beschreven in TMap. Een totaaloverzicht is opgenomen in bijlage B, met zowel de mapping van TMap-activiteiten op RUP-activiteiten als andersom. Daarnaast is bijlage C een vergelijking opgenomen van de TMap-producten en de RUP-artifacts. Sogeti Nederland B.V. 1.1 pagina 14

17 Onderstaande figuur toont de globale relatie tussen de TMap-fasering en de RUP Test workflow. Define evaluation mission Planning V S U A P&B Verify test approach V S U A Voorbereiding Validate build V S U A stability Uitvoering: pretest P&B P&B Specificatie+ V S U A Uitvoering P&B Test and Achieve evaluate acceptable mission V S U A Beheer P&B Improve test assets V S U A Afronding P&B another test cycle Figuur 4, globale relatie TMap fasering en RUP workflow Planning & Beheer De fase Planning en beheer valt uiteen in activiteiten voor planning en voor beheer. De RUP-stap Define Evaluation heeft grote overeenkomsten met de planningsactiviteiten uit de fase Planning en Beheer. Nr TMap RUP Nr 1 Planning Opdrachtformulering Evaluate Agree on 2 2 Planning Globale intake en Evaluate Identify test 1 studie motivators 3 Planning Vaststellen testbasis Evaluate Identify targets of 4 test 4 Planning Bepalen teststrategie Evaluate Define test 3 appproach 4 Planning Bepalen teststrategie Evaluate Define assessment 5 & traceability needs 5 Planning Inrichten organisatie? 6 Planning Inrichten Evaluate Agree on 2 testproducten 7 Planning Definiëren Verify test approach Define test 1 infrastructuur environment configs. 8 Planning Inrichten beheer Evaluate Define test 3 approach 9 Planning Bepalen planning Evaluate Agree on 2 10 Planning Fixeren testplan Evaluate Agree on 2 Sogeti Nederland B.V. 1.1 pagina 15

18 Figuur 5, Define Evaluation (copyright IBM Rational) Uitgaande van het mastertestplan wordt in deze workflow bepaald wat het testdoel of de testopdracht voor de iteratie is en wat de scope van het testen is. Betreft het een eerste prototype met beperkte functionaliteit dat globaal getest moet worden of is de iteratie de laatste voor productie en moet het systeem als geheel van goede kwaliteit zijn? De test wordt gepland, de aanpak bepaald, resources geclaimd en de voortgangsbewaking ingericht. Dit levert het plan van aanpak voor het testen van de iteratie, het Iteration Test Plan. De teststrategie in TMap is enigszins te vergelijken met de activiteiten Define Test Approach en Define Assessment and Traceability Needs, maar wordt in TMap in veel meer detail uitgewerkt. RUP's Define Test Approach bestaat uit een aantal stappen met o.a. een stap om te bepalen welke technieken te gebruiken, Define Assessment and Traceability Needs geeft aanwijzingen hoe zwaar getest moet worden. Dit laatste wordt besproken in termen van coverage. Coverage is echter zeer nauw verbonden aan het gebruik van testspecificatietechnieken. Omdat RUP verder niet op deze koppeling ingaat, blijft onduidelijk hoe dit in zijn werk moet gaan. De strategie wordt afgestemd met de diverse stakeholders totdat goedkeuring is verkregen. Daarnaast geeft de workflow zeer globale aanwijzingen hoe testresultaten beoordeeld moeten worden. Bij het hanteren van de TMap-strategie moet er goed op gelet worden dat het testen binnen de scope van de testopdracht/iteratie blijft, ofwel definieer geen teststrategie voor het eindproduct terwijl de eerste iteratie nog een prototype betreft. Een verschil is ook dat de TMap strategie redeneert vanuit risico's, kwaliteitsattributen, deelsystemen en de te gebruiken testtechnieken. RUP begint ook vanuit risico's, maar hanteert testvormen waar TMap kwaliteitsattributen en deelsystemen hanteert. De testvormen die RUP onderkent zijn: functioneel data en database integriteit businesscyclus user interface beveiliging volume Sogeti Nederland B.V. 1.1 pagina 16

19 stress load performance profiling installatie configuratie recovery Belangrijk onderdeel van de strategiebepaling volgens TMap is het opstellen van een begroting. Bij RUP zijn de benodigde uren weliswaar onderdeel van de template van de testplannen, maar het is onduidelijk in welke activiteit het begroten van de uren plaatsvindt. Ook worden in TMap de benodigde organisatie en infrastructuur meer in detail gedefinieerd. Bij RUP gebeurt dit voor de infrastructuur later, in Verify Test Approach. Voor organisatie is dit opnieuw wel opgenomen in de templates voor mastertestplan en iteratietestplan, maar is de bijbehorende activiteit onduidelijk. De beheer-activiteiten uit TMap vallen in RUP hoofdzakelijk onder de stap Achieve acceptable mission. Nr TMap RUP Nr 11 Beheer Onderhouden Achieve Acceptable Assess and improve 1 testplan test effort 11 Beheer Onderhouden Achieve Acceptable Assess and 2 testplan advocate quality 11 Beheer Onderhouden Improve Test Define assessment 6 testplan Assets & traceability needs 12 Beheer Uitvoeren beheer Achieve Acceptable Determine test 4 results 12 Beheer Uitvoeren beheer Improve Test Define test 1 Assets approach 13 Beheer Rapporteren Achieve Acceptable Assess and 2 advocate quality 14 Beheer Bepalen detailplanningen. Achieve Acceptable Assess and improve 1 test effort Gedurende de iteratie worden meerdere testcyclussen doorlopen. Het zwaartepunt van deze stap ligt aan het begin en eind van iedere testcyclus. De stap heeft tot doel om continu de prioriteiten van de verschillende tests te bewaken en te zorgen dat díe tests uitgevoerd worden die het meeste bijdragen aan het halen van de testopdracht. Dit houdt ook in het bewaken van de (oplossing van) kritische bevindingen, het bewaken van mogelijke regressie in opeenvolgende builds en het rapporteren van de kwaliteit van de applicatie aan de betrokken partijen. Zo nodig wordt de testopdracht bijgestuurd. Sogeti Nederland B.V. 1.1 pagina 17

20 Figuur 6, Achieve Acceptable (copyright IBM Rational) Een verschil is dat RUP het prioriteren van de tests met name als een beheerproces ziet terwijl TMap de prioriteiten in een eerder stadium expliciet bepaalt door middel van de strategiebepaling maar daarna de prioritering impliciet maakt (maar wél doet) als onderdeel van "Onderhouden testplan". De overgebleven activiteit 12, Uitvoeren beheer, valt in RUP onder Improve test assets, voor zover dit het onderhouden van de testware en -omgevingen betreft Voorbereiding De TMap-fase Voorbereiding is binnen RUP niet expliciet gemaakt maar het beste in te passen in Evaluate en Verify Test Approach, omdat het in beide gevallen voorbereidende activiteiten vóór het eigenlijke testwerk zijn. Nr TMap RUP Nr 1 Voorbereiding Uitvoeren? detailintake testbasis 2 Voorbereiding Definiëren testeenheden Evaluate Identify test ideas 6 3 Voorbereiding 3 Voorbereiding 4 Voorbereiding Toewijzen testspecificatietechnieken Toewijzen testspecificatietechnieken Specificeren infrastructuur. Evaluate Define test approach Verify test approach Define test details 4 Verify test approach Define test environment configs. 3 1 Sogeti Nederland B.V. 1.1 pagina 18

TESTEN VOLGENS TMAP, EEN KORTE INTRODUCTIE. 1. Inleiding. 2. TMap methode. Kwaliteit zonder gestructureerd testen is toeval.

TESTEN VOLGENS TMAP, EEN KORTE INTRODUCTIE. 1. Inleiding. 2. TMap methode. Kwaliteit zonder gestructureerd testen is toeval. TESTEN VOLGENS TMAP, EEN KORTE INTRODUCTIE Kwaliteit zonder gestructureerd testen is toeval Inhoudsopgave 1. Inleiding 2. De TMap methode 3. De fase Planning & Beheer 4. De fase testspecificatie 5. De

Nadere informatie

Examen TMPA Test Management Approach (TMap) Professional Advanced

Examen TMPA Test Management Approach (TMap) Professional Advanced Examen TMPA Test Management Approach (TMap) Professional Advanced Publicatiedatum Startdatum 6 juni 2003 1 mei 2003 Doelgroep De module is bestemd voor (beginnende) professionele testers met een ½ tot

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

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

De brug tussen PRINCE2 en TMap

De brug tussen PRINCE2 en TMap De brug tussen PRINCE2 en TMap Rob Baarda Testnet, Nieuwegein 9 juni 2004 Sogeti Nederland B.V. Pagina 1 Agenda PRINCE2 kort TMap in PRINCE2 Tips Globale typering PRINCE2 Onder besturing van Board Op basis

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

Testen bij DWH-projecten

Testen bij DWH-projecten Testen bij DWH-projecten Snelheid, Kwaliteit, Flexibiliteit onder úw regie Armando Dörsek, Software Control 18-09-2007 Wat gaat u horen? Testen van DW/BI > Structureren & Plannen Project- en teamstructuur

Nadere informatie

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

Voorbeeldexamen. Testen Foundation. Editie maart 2012

Voorbeeldexamen. Testen Foundation. Editie maart 2012 Voorbeeldexamen Testen Foundation Editie maart 2012 Copyright 2012 EXIN All rights reserved. No part of this publication may be published, reproduced, copied or stored in a data processing system or circulated

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

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

Woordenlijst bij TMap

Woordenlijst bij TMap Woordenlijst bij TMap Acceptatietest De door de toekomstige gebruiker(s) en beheerder(s) in een zoveel mogelijk als-ware-het-productie omgeving uitgevoerde test, die moet aantonen dat het ontwikkelde systeem

Nadere informatie

ISACA round-table 7 december 2009 Rik Marselis

ISACA round-table 7 december 2009 Rik Marselis ISACA round-table 7 december 2009 Rik Marselis Senior Testconsultant bij Sogeti Penningmeester van BNTQB, de member board voor België en Nederland van de International Software Testing Qualifications Board

Nadere informatie

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

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

Sjabloon testplan o.b.v. situationeel testen. <<Organisatie>> Sjabloon testplan o.b.v. situationeel testen SYSQA B.V. Almere Datum : Status : Opgesteld door : Organisatie SYSQA B.V. Pagina 2 van 11 Over dit sjabloon Dit

Nadere informatie

bedrijfsprocessen en vormt daarmee de kapstok voor de producten van andere disciplines. Het PAM is geen RUP concept.

bedrijfsprocessen en vormt daarmee de kapstok voor de producten van andere disciplines. Het PAM is geen RUP concept. 1. 1.1. Inleiding Doel De Requirementdiscipline richt zich op het vaststellen en vastleggen van de eisen en wensen die aan een oplossing worden gesteld: de requirements. Rollen De keyrol binnen deze discipline

Nadere informatie

Mastertestplan <> <>

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

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

Unified Process. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

Unified Process. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. Unified Process Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 10 Inhoudsopgave 1. Inleiding... 3 2. Unified Process... 4 3. Fasering... 5 3.1.

Nadere informatie

Testgedreven ontwikkeling dat is pas veilig!

Testgedreven ontwikkeling dat is pas veilig! Testgedreven ontwikkeling dat is pas veilig! INTRODUCTIE ANKO TIJMAN 2 Software tester sinds 1997 (TMap, ISEB Practitioner) Eerste agile ervaring in 2001 Presentaties op (inter)nationale congressen Nov

Nadere informatie

Sjabloon detailtestplan. <>

Sjabloon detailtestplan. <<Organisatie>> Sjabloon detailtestplan SYSQA B.V. Almere Datum : Status : Opgesteld door : Organisatie SYSQA B.V. Pagina 2 van 18 Inhoudsopgave 1 Managementsamenvatting...

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

RUP Rational Unified Process. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

RUP Rational Unified Process. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. RUP Rational Unified Process Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 14 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 1.2 VERSIEBEHEER...

Nadere informatie

TMap NEXT Test Engineer

TMap NEXT Test Engineer Voorbeeldexamen TMap NEXT Test Engineer Editie juni 2013 Copyright 2013 EXIN All rights reserved. No part of this publication may be published, reproduced, copied or stored in a data processing system

Nadere informatie

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

TMAP NEXT DOCUMENT OVERZICHT TOEGEPASTE TESTVORMEN

TMAP NEXT DOCUMENT OVERZICHT TOEGEPASTE TESTVORMEN TMAP NEXT DOCUMENT OVERZICHT TOEGEPASTE TESTVORMEN Copyright Sogeti Nederland B.V. te Vianen Niets uit deze uitgave mag verveelvoudigd en/of openbaar worden gemaakt (voor willekeurig welke doeleinden)

Nadere informatie

TMap NEXT Test Engineer

TMap NEXT Test Engineer Voorbeeldexamen TMap NEXT Test Engineer Editie juli 2011 Copyright 2011 EXIN All rights reserved. No part of this publication may be published, reproduced, copied or stored in a data processing system

Nadere informatie

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

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

Van Risicoanalyse tot Teststrategie

Van Risicoanalyse tot Teststrategie Van Risicoanalyse tot Teststrategie Cees Dulfer, Sr. Testconsultant Rabobank Nederland TestNet, 2 november 2005 1/28 TestNet, 2 november 2005 2/28 Agenda Historie Testproces en positionering Product Risico

Nadere informatie

ISTQB Foundation level. Een introductie. Algemene informatie voor medewerkers van: SYSQA B.V.

ISTQB Foundation level. Een introductie. Algemene informatie voor medewerkers van: SYSQA B.V. ISTQB Foundation level Een introductie Algemene informatie voor medewerkers van: SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 10 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 1.2 VERSIEBEHEER... 3

Nadere informatie

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

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

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

Test Automatisering? Mislukken Slagen gegarandeerd! Ruud Teunissen - Polteq Test Services BV

Test Automatisering? Mislukken Slagen gegarandeerd! Ruud Teunissen - Polteq Test Services BV Test Automatisering? Mislukken Slagen gegarandeerd! Ruud Teunissen - Polteq Test Services BV Mislukken Slagen gegarandeerd 2 Mislukken Slagen gegarandeerd Management verwacht onmiddellijk R.O.I. Doel:

Nadere informatie

TMap in essenties Michiel Vroon Leo van der Aalst Rob Baarda

TMap in essenties Michiel Vroon Leo van der Aalst Rob Baarda TMap in essenties Michiel Vroon Leo van der Aalst Rob Baarda 1 Waarom? Actualisering van de methode Praktijkgericht Testen integraal onderdeel van grotere geheel Diverse lijnorganisatievormen mogelijk

Nadere informatie

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

TestFrame. Een introductie. Algemene informatie voor medewerkers van: SYSQA B.V.

TestFrame. Een introductie. Algemene informatie voor medewerkers van: SYSQA B.V. TestFrame Een introductie Algemene informatie voor medewerkers van: SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 13 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 2 TESTFRAME... 4 2.1 TESTFRAME ALS

Nadere informatie

Satisfy the real (and changing) customer expectation

Satisfy the real (and changing) customer expectation Han Duisterwinkel Test & Quality competence RUP competence LogicaCMG Nederland B.V. Eemsgolaan 1 P.O. Box 70237 9704 AE Groningen The Netherlands www.logicacmg.com @logicacmg.com

Nadere informatie

Succes = Noodzaak x Visie x Draagvlak 2. Case: Implementatie Requirements Lifecycle management bij Rabobank International

Succes = Noodzaak x Visie x Draagvlak 2. Case: Implementatie Requirements Lifecycle management bij Rabobank International Succes = x Visie x Draagvlak 2 Case: Implementatie Requirements Lifecycle management bij Rabobank International dinsdag 3 oktober 2006 Spider Congres Agenda Inventarisatie SPI-knelpunten Implementatie

Nadere informatie

Vrijgaveadvies. Project

Vrijgaveadvies. Project <naam project> Vrijgaveadvies Project SYSQA B.V. Almere Datum : 08-02-2013 Status : Versie : Opgesteld door : Organisatie Project Pagina 2 van 16 Inhoudsopgave 1 Management samenvatting...

Nadere informatie

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

TestNet voorjaarsevenement 2014 Managen van een KetenTest bij NS met hun TOPAAS toolsuite. Managen van een Ketentest bij NS met hun TOPAAS tool-suite

TestNet voorjaarsevenement 2014 Managen van een KetenTest bij NS met hun TOPAAS toolsuite. Managen van een Ketentest bij NS met hun TOPAAS tool-suite Managen van een Ketentest bij NS met hun TOPAAS tool-suite Bart Broekman mei 2014 Onderwerpen De (prachtige) TOPAAS tooling De (niet zo prachtige) project-situatie De (oh zo mooie) dingen die we ermee

Nadere informatie

NGI-Noord. Mei 2007. Tim Koomen Leo van der Aalst Michiel Vroon

NGI-Noord. Mei 2007. Tim Koomen Leo van der Aalst Michiel Vroon NGI-Noord Mei 2007 Tim Koomen Leo van der Aalst Michiel Vroon TMap of TMap Next? TMap = methode TMap Next = boektitel TMap Next = externe communicatie. Waarom? Actualisering van de methode Testen integraal

Nadere informatie

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

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

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

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

TMap NEXT Test Engineer

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

Nadere informatie

Subwerkgroep Methoden. Toelichting inhoud en voortgang tot nu toe

Subwerkgroep Methoden. Toelichting inhoud en voortgang tot nu toe SPIDER werkgroep Requirements Management Subwerkgroep Methoden Toelichting inhoud en voortgang tot nu toe donderdag 17 januari 2008 Frans van Veen Bert Dubbelman Robert van Lieshout Erwin Bolwidt Jan-Willem

Nadere informatie

De beheerrisico s van architectuur

De beheerrisico s van architectuur De beheerrisico s van architectuur Een overzicht van de ArChimate Risico Extensie versie 0.2 Bert Dingemans Inleiding Het implementeren van een (enterprise) architectuur brengt altijd risico s met zich

Nadere informatie

Expert Panel. Awareness Information. 25 June 2013. Challenge the future

Expert Panel. Awareness Information. 25 June 2013. Challenge the future Expert Panel Awareness Information 25 June 2013 1 Structure Doel Proces Classificatie van de practices waarvan je al dan niet direct op de hoogte gehouden wilt worden Classificatie van de practices waarbij

Nadere informatie

Sjabloon testplan op basis van SYSQA -teststrategieaanpak. <>

Sjabloon testplan op basis van SYSQA -teststrategieaanpak. <<Organisatie>> Sjabloon testplan op basis van SYSQA -teststrategieaanpak SYSQA B.V. Almere Datum : Status : Opgesteld door : Organisatie Sjabloon detailtestplan op basis

Nadere informatie

het doel, de keuzen zijn gebaseerd op kennis en ervaring van de deelnemers van de bijeenkomsten.

het doel, de keuzen zijn gebaseerd op kennis en ervaring van de deelnemers van de bijeenkomsten. Rational Unified Process: aandachtspunten voor de auditor Systeemontwikkelingsorganisaties introduceren met regelmaat nieuwe of andere softwareontwikkelmethoden. Vaak ligt hier een ontevredenheid over

Nadere informatie

voorbeeldexamen TMap TMap NEXT Foundation editie juli 2009 inhoud 2 inleiding 3 voorbeeldexamen 15 antwoordindicatie 33 evaluatie TMPF_2.

voorbeeldexamen TMap TMap NEXT Foundation editie juli 2009 inhoud 2 inleiding 3 voorbeeldexamen 15 antwoordindicatie 33 evaluatie TMPF_2. voorbeeldexamen TMPF_2.0 TMap TMap NEXT Foundation editie juli 2009 inhoud 2 inleiding 3 voorbeeldexamen 15 antwoordindicatie 33 evaluatie EXIN Hét exameninstituut voor ICT ers Janssoenborch, Hoog Catharijne

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

Presentatie 06-03-2008 Gestructureerd en geautomatiseerd testen Ad Driessens en Gerben Mondeel

Presentatie 06-03-2008 Gestructureerd en geautomatiseerd testen Ad Driessens en Gerben Mondeel Presentatie 06-03-2008 Gestructureerd en geautomatiseerd testen Ad Driessens en Gerben Mondeel Doelstelling Introductie Practis en Producten Project bij Achmea Testaanpak Concrete toepassing van Rational

Nadere informatie

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

EISEN AAN TESTPLANNEN

EISEN AAN TESTPLANNEN EISEN AAN TESTPLANNEN Auteur : Datum : Versie :.. Status :.. Datum overdracht : Overgedragen aan : Inhoudsopgave 1 Inleiding...

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

Welkom. Great SAP Test Experience. 23 maart 2015

Welkom. Great SAP Test Experience. 23 maart 2015 Welkom Great SAP Test Experience 23 maart 2015 Sogeti PowerPoint Referentie 2014 2 5 5 Sogeti PowerPoint Referentie 2014 3 Sogeti PowerPoint Referentie 2014 4 Sogeti PowerPoint Referentie 2014 5 En toch

Nadere informatie

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

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

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

Interactieve Discussieavond. Testen en PRINCE2. www.testnet.org. 14-09-2004 TestNet interactieve discussieavond Testen en Prince2 1

Interactieve Discussieavond. Testen en PRINCE2. www.testnet.org. 14-09-2004 TestNet interactieve discussieavond Testen en Prince2 1 Interactieve Discussieavond Testen en PRINCE2 14-09-2004 TestNet interactieve discussieavond Testen en Prince2 1 Agenda Korte introductie PRINCE2 (Rik Marselis, LogicaCMG) Intro Hot Issues PRINCE2 (Rob

Nadere informatie

Testaanpak: leidraad voor het kiezen van een testtechniek

Testaanpak: leidraad voor het kiezen van een testtechniek Testaanpak: leidraad voor het kiezen van een testtechniek SYSQA B.V. Almere Datum : 18 november 2012 Status : Definitief Opgesteld door : Organisatie: SYSQA B.V. Pagina 2 van 9 Inhoudsopgave 1 Inleiding...

Nadere informatie

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

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

Wij testen..maar....wat test jij?

Wij testen..maar....wat test jij? Wij testen..maar....wat test jij? Wij testen maar wat test jij? Harm Pul, Busineslinemanager Functioneel Beheer TMAP dag 2015, 29 september 2015 Bussum 2 Herkent u dit? De gebruikers testen dit straks

Nadere informatie

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

Acceptatietesten en testmanagement Examennummer: 93453 Datum: 29 maart 2014 Tijd: 10:00 uur - 11:30 uur

Acceptatietesten en testmanagement Examennummer: 93453 Datum: 29 maart 2014 Tijd: 10:00 uur - 11:30 uur Acceptatietesten en testmanagement Examennummer: 93453 Datum: 29 maart 2014 Tijd: 10:00 uur - 11:30 uur Dit examen bestaat uit 7 pagina s. De opbouw van het examen is als volgt: - 20 meerkeuzevragen (maximaal

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

TMapNext. Een introductie. Algemene informatie voor medewerkers van: SYSQA B.V.

TMapNext. Een introductie. Algemene informatie voor medewerkers van: SYSQA B.V. TMapNext Een introductie Algemene informatie voor medewerkers van: SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 15 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 1.2 VERSIEBEHEER...FOUT! BLADWIJZER

Nadere informatie

Data Warehouse. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

Data Warehouse. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. Data Warehouse Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 9 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 1.2 VERSIEBEHEER... 3 2 DOEL VAN

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

Scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum agileagileagileagileagileagileagileagil

Scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum agileagileagileagileagileagileagileagil Scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum agileagileagileagileagileagileagileagil eagileagileagileagileagileagileagileagi leagileagileagileagileagileagileagileag

Nadere informatie

Test Management Assessment

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

Nadere informatie

Van Samenhang naar Verbinding

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

Nadere informatie

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

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

ARE methodiek Het ontwikkelen van Informatie Elementen

ARE methodiek Het ontwikkelen van Informatie Elementen ARE methodiek Het ontwikkelen van Informatie Elementen WI1: Het opstarten van het project Milestone 1 WI2: Ontwikkel een Vison WI3: Modelleer het Business Domain WI4: Creëer een Glossary WI7: Beheer wijzigingen

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

De SYSQA dienst auditing. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

De SYSQA dienst auditing. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. De SYSQA dienst auditing Een introductie 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

van TESTmanagement naar testmanagement

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

Nadere informatie

CHECKLIST GESTRUCTUREERD TESTEN. Doel. Toepassingsgebied

CHECKLIST GESTRUCTUREERD TESTEN. Doel. Toepassingsgebied Gepubliceerd in: Checklist Informatiemangement, Aflevering 29, 1999 CHECKLIST GESTRUCTUREERD TESTEN Doel Het doel van deze checklist is het bepalen van de sterke en zwakke punten van de huidige werkwijze

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

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

PROQA Project Quality Assurance. Checklist. Behorend bij het PROQA-assessment SYSQA B.V.

PROQA Project Quality Assurance. Checklist. Behorend bij het PROQA-assessment SYSQA B.V. PROQA Project Quality Assurance Checklist Behorend bij het PROQA-assessment SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 9 Inhoudsopgave 1 INLEIDING CHECKLIST WERKEN VOLGENS PROQA... 3 1.1 DE 5 FASEN

Nadere informatie

Bijlage 9. UNI 120621.9 REB GD. Releasebeleid

Bijlage 9. UNI 120621.9 REB GD. Releasebeleid Releasebeleid Ondanks alle aan de samenstelling van de tekst bestede zorg, kan Newway Retail Solutions bv (Newway) géén enkele aansprakelijkheid aanvaarden voor eventuele directe en/of indirecte schade,

Nadere informatie

Testverbetering met TMM bij Philips

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

Nadere informatie

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

Test Process Improvement Benchmark. SPIder Conferentie 23 september Wim van Uden

Test Process Improvement Benchmark. SPIder Conferentie 23 september Wim van Uden Test Process Improvement Benchmark SPIder Conferentie 23 september Wim van Uden Agenda Korte inleiding TPI -model TPI benchmark overall Vergelijking branches DO s& DON Ts Test Process Improvement Optimaliseren

Nadere informatie

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

Testen Foundation (TestF.NL)

Testen Foundation (TestF.NL) (TestF.NL) EXIN Hét exameninstituut voor ICT ers Janssoenborch - Hoog Catharijne Godebaldkwartier 365 3511 DT Utrecht Postbus 19147 3501 DC Utrecht Nederland T +31 30 234 48 11 F +31 30 231 59 86 E info@exin.nl

Nadere informatie

Requirements Traceability. Marcel de Baas, Jan Bank, Edwin Buisman, Frits Jacobs, Kitty Spaas, Erik Venema, Arno Zandman

Requirements Traceability. Marcel de Baas, Jan Bank, Edwin Buisman, Frits Jacobs, Kitty Spaas, Erik Venema, Arno Zandman Requirements Traceability Marcel de Baas, Jan Bank, Edwin Buisman, Frits Jacobs, Kitty Spaas, Erik Venema, Arno Zandman 22 Mei 2008 Werkgroep Traceability Doel van de werkgroep: Aanbieden van hulpmiddelen

Nadere informatie

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

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

Nadere informatie

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

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

Nadere informatie

Business Rules: het scheiden van kennis en processen 17 september 2014

Business Rules: het scheiden van kennis en processen 17 september 2014 Business Rules: het scheiden van kennis en processen 17 september 2014 Business rules scheiden kennis van processen 1 Agenda 18:30-18:40 Opening 18:40-19:15 Het scheiden van kennis en processen Peter Nobels,

Nadere informatie

PAT PT IT ST. ontwikkelaarstests. acceptatietests GT FAT

PAT PT IT ST. ontwikkelaarstests. acceptatietests GT FAT 42 Testen volgens TMap - Deel I Algemeen laat staan vergezeld van de voor de acceptatietest onmisbare documentatie, zoals de gebruikershandleiding. Geleidelijk aan is daarom de behoefte ontstaan om bij

Nadere informatie