TMAP EN RATIONAL UNIFIED PROCESS

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

VERSIE INFORMATIE Versie Datum Bijzonderheden Auteur 0.1 21 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 1.1 6 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

INHOUDSOPGAVE VERSIE INFORMATIE...II INHOUDSOPGAVE...1 1 INLEIDING...2 2 RUP...5 2.1 Best practices... 5 2.2 Fases... 6 2.3 Disciplines... 6 3 TESTEN IN RUP...8 3.1 Master Test Plan en Iteration Test Plan... 8 3.2 Unit Test (UT)... 9 3.3 Integratietest (IT)... 9 3.4 Systeemtest(ST)...10 3.5 Acceptatietest (AT)...12 3.6 Reviews...12 3.7 Rollen...12 4 TOEPASSING TMAP BIJ RUP... 14 4.1 Mastertestplan...14 4.2 Fasering...14 4.2.1 Planning & Beheer...15 4.2.2 Voorbereiding...18 4.2.3 Specificatie...20 4.2.4 Uitvoering...22 4.2.5 Afronding...24 4.3 Organisatie...25 4.4 Technieken...26 4.4.1 Teststrategie...26 4.4.2 Testspecificatietechnieken...27 4.5 Infrastructuur...28 4.6 Acceptatietest...28 5 LITERATUUR... 28 BIJLAGE A, MASTERTESTPLAN VOLGENS RUP EN TMAP... 28 BIJLAGE B, DETAILVERGELIJKING RUP EN TMAP TESTACTIVITEITEN... 28 BIJLAGE C, VERGELIJKING TMAP PRODUCTEN MET RUP ARTIFACTS... 28 Sogeti Nederland B.V. 1.1 pagina 1

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.

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

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

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

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

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, www.rational.com. Sogeti Nederland B.V. 1.1 pagina 7

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 www.satisfice.com. 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

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

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

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

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

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

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 4.6. 4.1 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

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

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

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

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