TMAP EN RATIONAL UNIFIED PROCESS

TMAP® EN RATIONAL UNIFIED PROCESS®

Auteur

T. Koomen, M. Tolsma

Versie

1.1

Plaats

Rotterdam

Kenmerk

TMap en RUP tpv v11

VERSIE INFORMATIE Versie 0.1 0.5 1.0

Datum 21 augustus 2003 oktober 2003 november 2003

1.1

6 januari 2004

Bijzonderheden Eerste concept Commentaar interne reviews verwerkt Commentaar interne en externe reviews verwerkt Definitief

Auteur T. Koomen, M. Tolsma T. Koomen, M. Tolsma T. Koomen, M. Tolsma 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. Januari 2003

1.1

II

TMap en RUP tpv v11

INHOUDSOPGAVE VERSIE INFORMATIE ..........................................................................II INHOUDSOPGAVE .............................................................................1 1

INLEIDING ...............................................................................2

2

RUP.......................................................................................5

3

4

5

2.1

Best practices..................................................................................... 5

2.2

Fases ............................................................................................... 6

2.3

Disciplines ......................................................................................... 6

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

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

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


1.1

pagina 1

TMap en RUP tpv v11

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

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.


1.1

pagina 2

TMap en RUP tpv v11

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.


1.1

pagina 3

TMap en RUP tpv v11

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


1.1

pagina 4

TMap en RUP tpv v11

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. Januari 2003

1.1

pagina 5

TMap en RUP tpv v11

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 Sogeti Nederland B.V. Januari 2003

Beschrijving 1.1

pagina 6

TMap en RUP tpv v11

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.


1.1

pagina 7

TMap en RUP tpv v11

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. Januari 2003

1.1

pagina 8

TMap en RUP tpv v11

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


1.1

pagina 9

TMap en RUP tpv v11

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.


1.1

pagina 10

TMap en RUP tpv v11

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 Mission, Verify test approach, Validate Build Stability, Test and Evaluate, Achieve Acceptable Mission 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 Mission, Test and Evaluate, Achieve Acceptable Mission 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. Januari 2003

1.1

pagina 11

TMap en RUP tpv v11

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


1.1

pagina 12

TMap en RUP tpv v11

overlap) ingevuld te zijn, waarbij het mogelijk is dat personen delen van of juist meerdere testrollen vervullen en/of in meerdere projecten acteren.


1.1

pagina 13

TMap en RUP tpv v11

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). Specificatie Voorbereiding

intake specificaties toewijzen technieken

specificeren testgevallen realiseren infrastructuur

Uitvoering

pretest (her-)testen controleren beoordelen

Planning en Beheer

initiatie en studie bepaling teststrategie risicotaxatie testbegroting inrichten organisatie opstellen testplan voortgang & beheer rapportage

V

S

U

A Afronding

P&B

conserveren testware evalueren

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. Januari 2003

1.1

pagina 14

TMap en RUP tpv v11

Onderstaande figuur toont de globale relatie tussen de TMap-fasering en de RUP Test workflow. Define evaluation mission Verify test approach

Planning V

S

U

A

P&B

Validate build V S U A stability Uitvoering:

Voorbereiding V

S

U

pretest

A

P&B

P&B

Specificatie+ Uitvoering V

S

U

Achieve acceptable mission V S

Test and evaluate

A

U

Beheer

P&B

P&B

Improve test assets

Afronding V

S

P&B

U

A

A

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 Mission heeft grote overeenkomsten met de planningsactiviteiten uit de fase Planning en Beheer. Nr 1 2

TMap Planning Planning

3

Planning

Opdrachtformulering Globale intake en studie Vaststellen testbasis

4

Planning

Bepalen teststrategie

Evaluate Mission

4

Planning


Evaluate Mission

5 6

Planning Planning

? Evaluate Mission

7

Planning

Inrichten organisatie Inrichten testproducten Definiëren infrastructuur

8

Planning

Inrichten beheer

9 10

Planning Planning

Bepalen planning Fixeren testplan


RUP Evaluate Mission Evaluate Mission Evaluate Mission

Agree on Mission Identify test motivators Identify targets of test Define test appproach Define assessment & traceability needs

Nr 2 1 4 3 5

Agree on Mission

2

Verify test approach Define test environment configs. Evaluate Mission Define test approach Evaluate Mission Agree on Mission Evaluate Mission Agree on Mission

1

1.1

3 2 2

pagina 15

TMap en RUP tpv v11

Figuur 5, Define Evaluation Mission (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. Januari 2003

1.1

pagina 16

TMap en RUP tpv v11

• • • • • •

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 11

TMap Beheer

11

Beheer

11

Beheer

12

Beheer

Onderhouden testplan Onderhouden testplan Onderhouden testplan Uitvoeren beheer

12

Beheer

Uitvoeren beheer

13

Beheer

Rapporteren

14

Beheer

Bepalen detailplanningen.

RUP Achieve Acceptable Mission Achieve Acceptable Mission Improve Test Assets Achieve Acceptable Mission Improve Test Assets Achieve Acceptable Mission Achieve Acceptable Mission

Assess and improve test effort Assess and advocate quality Define assessment & traceability needs Determine test results Define test approach Assess and advocate quality Assess and improve test effort

Nr 1 2 6 4 1 2 1

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.


1.1

pagina 17

TMap en RUP tpv v11

Figuur 6, Achieve Acceptable Mission (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 Mission en Verify Test Approach, omdat het in beide gevallen voorbereidende activiteiten vóór het eigenlijke testwerk zijn. Nr 1 2 3

TMap Voorbereiding Voorbereiding Voorbereiding

3

Voorbereiding

4

Voorbereiding

Uitvoeren detailintake testbasis Definiëren testeenheden Toewijzen testspecificatietechnieken Toewijzen testspecificatietechnieken Specificeren infrastructuur.


RUP ?

Nr

Evaluate Mission

Identify test ideas

6

Evaluate Mission

Define test approach

3

Verify test approach Define test details

4

Verify test approach Define test environment configs.

1

1.1

pagina 18

TMap en RUP tpv v11

Figuur 7, Verify Test Approach (copyright IBM Rational)

De eerste activiteit uit de fase Voorbereiding, de detailintake, heeft geen vergelijkbare activiteit in de RUP workflow, tenzij deze wordt gezien als onderdeel van de reguliere review-activiteiten. De aanbeveling is om de detailintake te handhaven, waarbij het minder uitmaakt of deze een aparte activiteit is of onderdeel van een review: het expliciet reviewen op testbaarheid levert in de praktijk heel nuttige informatie op over de kwaliteit van de testbasis. Bij onvoldoende kwaliteit kan dan nog vroegtijdig bijgestuurd worden. Voor UML dienen de detailintake-checklists van standaard TMap aangepast te worden. Voor use cases kan gebruik gemaakt worden van [Copeland 2002]. De activiteiten 2, 3 en 4 betreffen onder andere het verfijnen en aanpassen van de technieken en het specificeren van de infrastructuur, wat terug te vinden is in zowel Evaluate Mission als in Verify Test Approach. Deze laatste stap binnen de RUP workflow verloopt parallel aan andere stappen en is gericht op het aantonen of de gekozen testaanpak en -technieken werken voor het betreffende project. Dit vindt plaats door het uitvoeren van subsets van tests. Zo nodig kan dan tuning van de aanpak en technieken plaatsvinden. Naast deze algemene "test van de test" wordt ook aandacht besteed aan de eisen aan testomgeving en aan de testbaarheid van de applicatie. Dit laatste gebeurt in samenspraak met het ontwikkelteam. Indien de tests geautomatiseerd gaan worden of indien het (voor de organisatie) een nieuwe aanpak en technieken betreft, vraagt deze stap meer inspanning. Ook neemt de inspanning snel af bij latere iteraties. Sogeti Nederland B.V. Januari 2003

1.1

pagina 19

TMap en RUP tpv v11

Het bespreekbaar maken van testbaarheid met het ontwikkelteam is iets wat niet expliciet in TMap is gemaakt maar wat zeker een nuttige activiteit is. Onderwerp van bespreking zijn bijvoorbeeld door de ontwikkelaars te maken stubs en drivers. Deze activiteit moet dan toegevoegd worden aan de genoemde TMap activiteiten. 1. Testbaarheid borgen. Van belang is dat in de TMap-fase geen expliciete testactiviteiten plaatsvinden, terwijl dat in de RUP workflow wél het geval is. Afhankelijk of men de noodzaak ervan ziet, kan gekozen worden om dit wel of niet te handhaven.

4.2.3

Specificatie

De TMap-fase Specificatie wordt in RUP met name ondergebracht bij Test and Evaluate. In deze RUP-stap zijn de belangrijke TMap-fasen Specificatie en Uitvoering gecombineerd. RUP wil hiermee benadrukken dat specificatie en uitvoering van testgevallen parallel kunnen lopen. Voor hoe hier mee om te gaan wordt verwezen naar de volgende paragraaf 4.2.4. Nr 1

TMap Specificatie

1

Specificatie

1

Specificatie

2

Specificatie

3

Specificatie

Opstellen testspecificaties Opstellen testspecificaties Opstellen testspecificaties Definiëren uitgangsbestanden Opstellen testscripts

3

Specificatie

Opstellen testscripts

Test and Evaluate

4

Specificatie

?

5

Specificatie

5

Specificatie

6

Specificatie

Opstellen testdraaiboek Specificeren intake testobject/ infrastructuur Specificeren intake testobject/ infrastructuur Realiseren infrastructuur.


RUP Test and Evaluate

Implement test

Nr 1

Test and Evaluate

Identify test ideas

6

Test and Evaluate

Define test details

7

Test and Evaluate

Implement test

1

Test and Evaluate

Implement test suite Structure test implementation

2

Validate Build Stability

Implement test

1


Define test details

4

Workflow Environment

Support Development

1.1

5

pagina 20

TMap en RUP tpv v11

Figuur 8, Test and Evaluate (copyright IBM Rational)

In Test and Evaluate bepaalt een Test Analyst de testgevallen tot op logisch niveau in activiteiten als "identify test ideas" en "define test details" die vervolgens door de tester worden uitgewerkt in fysieke testgevallen en in een testscript, in respectievelijk "implement test" en "implement testsuite". Overigens hanteert RUP een andere definitie van testscript dan TMap. Een testscript volgens RUP is de implementatie van een testgeval, terwijl TMap een testscript ziet als een opvolging van acties en controles om een verzameling testgevallen op efficiënte manier uit te voeren. Dit laatste heet in RUP dan de test suite en is meer gericht op testautomatisering. In dit document worden de TMap-begrippen gehanteerd, tenzij expliciet over het RUP-begrip wordt gesproken. De tests binnen RUP kunnen zowel handmatig als geautomatiseerd zijn. Ook moet opgemerkt worden dat RUP bij het specificeren van testgevallen geen uitspraak doet over het gebruik van testspecificatietechnieken of over de benodigde testbasis. Dit is jammer, want hiermee wordt feitelijk het belang van de eigen systeemdocumentatie afgezwakt. RUP schrijft namelijk wel degelijk allerlei systeemdocumenten voor, die heel goed als testbasis bruikbaar zijn. Voorbeelden zijn use cases, use case models, business rules, classes, class diagrams, sequence diagrams, data model en supplementary specifications. Diverse TMaptestspecificatietechnieken zijn prima geschikt om op basis van RUPsysteemdocumentatie testgevallen af te leiden, zie ook paragraaf 4.4. De in deze en andere RUP-stappen voorkomende activiteit "identify test ideas" heeft minder duidelijke overlap met TMap. Afhankelijk van de mate van detaillering van de testideeën kan overlap gevonden worden bij de keuze voor de testtechnieken in de Sogeti Nederland B.V. Januari 2003

1.1

pagina 21

TMap en RUP tpv v11

fase Voorbereiding of bij het specificeren van testgevallen in Specificatie. Indien gewenst kan een dergelijke lijst testideeën opgesteld en onderhouden worden. De vijfde activiteit in de fase, het specificeren van de intake, is in RUP ondergebracht in Validate Build Stability. Voor meer uitleg hierover wordt verwezen naar de volgende paragraaf, de fase Uitvoering. TMap heeft "realiseren infrastructuur" als onderdeel van de fase specificatie. In RUP is dit ondergebracht in de ondersteunende activiteit Support Development.

4.2.4

Uitvoering

De volgende TMap-activiteiten maken deel uit van de fase Uitvoering, met hierachter de corresponderende RUP-activiteiten: Nr 1

TMap Uitvoering

1

Uitvoering

1

Uitvoering

1

Uitvoering

2

Uitvoering

3 4

Uitvoering Uitvoering

4

Uitvoering

5

Uitvoering

Intake testobject/infrastruct uur Intake testobject/infrastruct uur Intake testobject/infrastruct uur Intake testobject/infrastruct uur Vullen uitgangsbestanden Uitvoeren (her)tests Controleren en beoordelen testresultaten Controleren en beoordelen testresultaten Onderhouden testdraaiboek.


RUP Validate Build Stability

Execute test suite

Nr 2


Analyze test failure

3


Determine tes results

5


Assess and advocate quality

6

Test and Evaluate

Implement test suite Execute test suite Analyze test failure

2

Determine test results

8

Test and Evaluate Test and Evaluate

Test and Evaluate

3 4

?

1.1

pagina 22

TMap en RUP tpv v11

Figuur 9, Validate Build Stability (copyright IBM Rational)

De intake als eerste activiteit van Uitvoering is onderdeel van de RUP-stap Validate Build Stability. Opvallend is dat deze stap in RUP gelijk begint na de stap Define Evaluation Mission die min of meer gelijk staat aan de TMap-fase Planning. In Validate Build Stability wordt getest of de opgeleverde softwareversie (build) stabiel genoeg, met andere woorden testbaar genoeg, is om te testen. De RUP-stap is daarmee niets anders dan het specificeren en uitvoeren van een pretest volgens TMap. Per iteratie kunnen meerdere builds worden opgeleverd, hoewel gewoonlijk niet elke build aan deze stap wordt onderworpen. De test kan (deels) worden geautomatiseerd. Wanneer we hier RUP dus letterlijk volgen, vervalt het specificeren van testgevallen vóórdat de software er is, dit doen we nádat de software opgeleverd is. Het nadeel hiervan is dat dit niet stimuleert om het testen zoveel mogelijk voor te bereiden vóórdat de programmatuur wordt opgeleverd, met als risico dat allerlei testactiviteiten onnodig op het kritieke pad van het project komen te liggen. Mogelijke voordelen zijn dat er grotere kans is dat software en documentatie synchroon lopen, dat de testgevallen niet op basis van een verouderde documentatieversie zijn gemaakt en dat tegelijk ontwerpen en uitvoeren van tests qua urenbesteding efficiënter kan zijn (exploratory testing, zie ook [Koomen 2003]). De kleine stap van de pretest in TMap is erg uitvergroot in RUP. In veel gevallen zullen de voordelen van het wachten met specificeren van tests tot de eerste build wordt opgeleverd niet opwegen tegen de nadelen. Met een soepeler interpretatie van deze stap en de volgende stap, Test & Evaluate, kan dit bezwaar gemakkelijk omzeild worden. Als er nog geen build is, kan de Validate Build Stability stap niet uitgevoerd worden, maar kan al wel met de volgende stap worden gestart, echter alleen met het Sogeti Nederland B.V. Januari 2003

1.1

pagina 23

TMap en RUP tpv v11

specificeren van tests en niet met het uitvoeren ervan. De volgende figuur maakt duidelijk hoe dit plaats moet vinden:

Start iteration

Build 1

Validate build stability

Build 2

Validate build stability

Execute tests Specify tests

Specify tests

End iteration

Execute tests Specify tests

Figuur 10, alternatieve volgorde workflow

De overige activiteiten van TMap-fase Uitvoering vallen evenals de meeste Specificatie-activiteiten onder Test and Evaluate. Zo voert de tester de testgevallen uit in "execute testsuite" en analyseert de afwijkingen ten opzichte van het verwachte testresultaat.

4.2.5

Afronding

De activiteiten van de fase Afronding, met de RUP-tegenhangers, zijn: Nr 1

TMap Afronding

2

Afronding

2

Afronding

3

Afronding

4

Afronding

5

Afronding

RUP Achieve Acceptable Mission Evalueren testproces Achieve Acceptable Mission Evalueren testproces Improve Test Assets Opstellen Achieve Acceptable evaluatierapport Mission Conserveren testware Improve Test Assets Decharge testteam ? Evalueren testobject

Assess and improve test effort Assess and improve test effort Prepare Guidelines for Project Assess and advocate quality Structure test implementation

Nr 1 1 9 2 2

De eerste drie Afrondings-activiteiten kunnen het beste worden ondergebracht in RUP's Achieve Acceptable Mission, maar er is ook overlap met Improve Test Assets.


1.1

pagina 24

TMap en RUP tpv v11

Figuur 11, Improve Test Assets (copyright IBM Rational)

Achieve Acceptable Mission produceert als artifact het Test Evaluation Summary, met daarin een evaluatie van het testobject maar ook het testproces. Improve Test Assets betreft het onderhouden en verbeteren van de testware in algemene zin. Hieronder vallen het onderhoud van de tests, het beheer van de testomgevingen en het onderhoud van de geautomatiseerde tests. Ook kunnen vanuit deze stap aanbevelingen worden gedaan om de werkwijze voor testen aan te passen, op basis van het Test Evaluation Summary. Naast de vierde TMap-activiteit, het conserveren van de testware, omvat deze RUP-stap dus ook het evalueren van het testproces. Extra in TMap is de decharge van het testteam. Binnen de informele werkwijze van RUP is dit vaak overbodig.

4.3

Organisatie

Iteratieve systeemontwikkeling heeft gevolgen voor de organisatie van het project (vaak kleine, multi-disciplinaire teams) en daarmee ook voor de organisatie van het testen. In dit document wordt hier verder niet op ingegaan omdat het niet specifiek voor RUP is. Wél specifiek voor RUP zijn de testrollen. RUP onderkent een aantal testrollen die deze activiteiten moeten uitvoeren: • test manager, • test analyst, • tester en • test designer. Tezamen dekken zij alle activiteiten van de Test Discipline af. Sogeti Nederland B.V. Januari 2003

1.1

pagina 25

TMap en RUP tpv v11

De eerste 3 rollen 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, daarom heet de rol ook wel test architect of zelfs testautomatiseringsarchitect. Min of meer vergelijkbare TMap-rollen zijn methodische ondersteuning en de TAKT-architect.

4.4

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 onderstaande paragrafen worden nog een aantal RUP-specifieke aanvullingen gegeven op de teststrategiebepaling en de testspecificatietechnieken.

4.4.1

Teststrategie

De teststrategie moet erop gericht zijn de belangrijkste fouten zo vroeg mogelijk tegen de minste kosten te vinden. Voor het opstellen van een teststrategie voldoet de techniek zoals in TMap is beschreven. Onderstaand worden een aantal aanvullende aanwijzingen gegeven, waarmee rekening gehouden moet worden bij het opstellen. Het iteratieve karakter van de systeemontwikkeling betekent dat het product niet in één keer klaar is maar steeds verder evolueert. Elke evolutie vindt in korte tijd plaats en is wat betreft doorlooptijd scherp begrensd door het timebox principe. De korte doorlooptijd wordt wel als nadeel voor het testen gezien: zoveel te testen in zo korte tijd. Het tegenargument is dat de bouwer ook niet in staat is om heel veel te bouwen binnen die tijd. Het probleem zit dan ook eerder in het feit dat de bouwer uitloopt ten koste van de beschikbare testtijd, omdat de deadline van de timebox "in beton gebeiteld" is. Dit probleem is overigens ook bij traditionele testtrajecten herkenbaar. Goed pro-actief managen van het testproces en het hanteren van een op risico's gebaseerde teststrategie, zoals TMap voorschrijft, zijn essentieel. Een goede afspraak is dat in de laatste builds geen nieuwe functionaliteit meer gebouwd mag worden. Komt desondanks het testen in de knel, dan blijft er weinig anders over dan zo duidelijk mogelijk over de risico's te rapporteren. Een ander probleem is de hoeveelheid opeenvolgende evaluaties. Als het product immers door verschillende evaluatiesessies is gegaan, voldoet het dan nog aan de eerder overeengekomen afspraken? Een gedeelte van het product zal klaar zijn en er moeten afspraken worden gemaakt voor de noodzakelijke veranderingen voor de volgende cyclus. Het risico hier is dat onderdelen die in een eerdere cyclus zijn geaccepteerd en afgesproken, ongemerkt en als neveneffect van latere afspraken, kunnen veranderen. De projectmanager geeft de tester normaal gesproken als taak deze regressie te bewaken. Dat betekent dat met grote regelmaat regressietests moeten worden uitgevoerd om telkens weer te controleren dat het systeem nog steeds werkt zoals afgesproken. Een andere taak van de tester is om de gebruiker te helpen de juiste beslissing te nemen en geen onderdelen te vergeten als deze de nieuwe productversie beoordeelt. De tester kan hier een checklist gebruiken met de te testen aspecten die beoordeeld moeten worden. Ook kan zij haar ervaringen en expertise gebruiken om zwakke plekken en risicogebieden aan te duiden die nadere aandacht vragen. Het is de taak Sogeti Nederland B.V. Januari 2003

1.1

pagina 26

TMap en RUP tpv v11

van de gebruiker om te beslissen of het product akkoord is of niet. Het is de rol van de tester om zwakheden te identificeren die blijkbaar over het hoofd worden gezien.

4.4.2

Testspecificatietechnieken

De beschikbare testbasis is van grote invloed op de keuze voor testspecificatietechnieken. Bij RUP is het vrij vanzelfsprekend om UML te gebruiken. De populariteit van UML als vervanger van traditionele modelleringstechnieken wekt bij veel mensen de verwachting dat de bestaande testspecificatietechnieken ook vervangen moeten worden. Het argument hiervoor is dat de testtechnieken alleen geschikt zijn voor bedoelde traditionele technieken. Dit is een misvatting. Voor traditionele modelleringstechnieken als Entity-Relationship-Diagram of Data Flow Diagram bestaan namelijk ook geen specifieke testtechnieken. Zo zijn er ook geen aparte testtechnieken voor Use Case Diagrams of Class Diagrams. In de regel maken de testtechnieken gebruik van functionele beschrijvingen, van gegevenscontroles en van schermlayouts, waarbij het minder van belang is op welke plaats deze beschrijvingen te vinden zijn. Voor het maken van een testscript op basis van UML moeten ook de bekende stappen worden uitgevoerd zoals beschreven in TMap: nadat de te testen situaties zijn bepaald worden eerst logische testgevallen gedefinieerd, die vervolgens worden omgezet in fysieke testgevallen. Nadat de benodigde initiële gegevens zijn verzameld, wordt de volgorde waarin de testgevallen worden uitgevoerd, vastgelegd in een testscript. Onderstaande tabel bevat een overzicht van te gebruiken testspecificatietechnieken: Techniek Benodigde informatie Gedocumenteerde testbasis kan bestaan uit: Dataflowtest Invoer aan (één of meer functies Use cases van) het systeem + verwachte Use case diagrams uitvoer Class diagrams, Class descriptions State transition diagrams Business scenario's Supplementary specifications Procescyclustest Koppeling tussen bedrijfsprocessen Use cases en systeem Use case diagrams State transition diagrams AO-beschrijvingen Real-life test De verwachte productiesituatie Use case diagrams (frequentie van gebruik, database- Beschrijving van verwachte vulling) productiesituatie Syntactische Schermen en primaire Schermlayouts test invoercontroles Use cases Data constraints (in classes) Semantische Controles op relatie tussen Relaties tussen data (in classes) test gegevens/objecten Use cases State transition diagrams Error guessing Alle Programma Interfaces tussen programma's of Component interface interfacetest componenten beschrijvingen Classes


1.1

pagina 27

TMap en RUP tpv v11

Zoals ook uit de tabel blijkt is een belangrijk onderdeel van UML de use cases. Hiermee wordt de functionaliteit van het systeem op hoofdlijnen beschreven. Op basis van use cases kan echter maar met een beperkte diepgang worden getest. In use cases worden immers alleen de interacties tussen actoren en het systeem beschreven. De exacte inhoud van deze interacties en de frequentie waarmee ze voorkomen blijven echter buiten beschouwing. Use cases en use case diagrams kunnen worden gebruikt voor het testen van de volgende aspecten van het systeem. • De verwachte opeenvolging van gebeurtenissen. De opeenvolging van acties en handelingen die met het systeem (moeten) worden uitgevoerd. • Uitzonderingsgevallen of specifieke gebeurtenissen. Bijvoorbeeld de reactie van het systeem op onverwachte handelingen of incorrect gebruik van het systeem. • Alle relaties en afhankelijkheden tussen use cases en actoren en tussen use cases onderling Bij het testen op basis van use cases is de meest voor de hand liggende techniek de procescyclustest (of algoritmetest). De testpaden worden dan gemaakt op basis van het use case diagram, waarbij alle relevante relaties en mogelijke keuzes minimaal éénmaal worden geraakt. De hoeveelheid te bepalen testpaden hangt af van de testmaat waarmee de test wordt uitgevoerd (zie voor meer informatie TMap) Om met behulp van use cases te kunnen testen is naast een use case beschrijving en een use case diagram aanvullende informatie noodzakelijk over bepaalde aspecten. Met name ontbreekt informatie om de logische testgevallen in fysieke testgevallen om te kunnen zetten: • Wat is het domein van alle variabelen die in een use case participeren? • Welke input en output relaties bestaan tussen de verschillende use case variabelen? Waardoor wordt een use case getriggerd, wat zijn de pre- en post condities? • Is er sprake van volgordelijke afhankelijkheden tussen de verschillende use cases? De benodigde aanvullende informatie moet worden gezocht in de beschrijvingen van de classes en de constraints, class diagrams en sequence diagrams. Als voorbeeld is het belangrijk om inzicht te krijgen in de variabelen die van toepassing zijn. Met deze variabelen worden bedoeld de verschillende mogelijkheden die in de praktijk van het gebruik van de use case van toepassing zijn en een andere verwerking tot gevolg hebben. Het aantal (mogelijke) instanties van een use case hangt af van deze mogelijkheden. Wanneer de use case bijvoorbeeld het aflossen van een hypotheekrekening betreft dan zijn de variabelen bijvoorbeeld de verschillende manieren van aflossing die er zijn of het aantal hypotheekrekeningen dat een klant mag hebben. Bij het inventariseren van de relevante variabelen is het van belang de vraag te stellen of onderscheid tussen deze variabelen een werkelijk ander interactie verloop tot gevolg heeft. Bij het bepalen van het aantal relevante variabelen spelen tevens de grenzen van het systeem een rol. Hoeveel rekeningen kan een klant maximaal hebben en hoeveel rekeningnummers kunnen er dus op een scherm worden ingevuld? Naast bovengenoemde aspecten die noodzakelijk zijn om überhaupt te kunnen testen is aanvullende informatie nodig om kwalitatief beter te kunnen testen. 1. Om een teststrategie en planning te kunnen maken is het bijvoorbeeld van belang om te weten welke use cases cruciaal zijn voor de werking van het systeem en welke minder belangrijk zijn. Daarnaast is het interessant om te weten wat de relatieve frequentie van iedere use case is. Met andere woorden: hoe frequent wordt de use case binnen het systeem gebruikt? Indien geen informatie Sogeti Nederland B.V. Januari 2003

1.1

pagina 28

TMap en RUP tpv v11

beschikbaar is waarin deze informatie kan worden teruggevonden, moet het antwoord op deze vragen moet worden gezocht bij de ervaringsdeskundigen en/of de gebruikers bij de klant organisatie. 2. Door testgevallen te maken op basis van class beschrijvingen kan men het systeem met meer diepgang testen. In de praktijk zijn de objecten meestal niet direct aan te sturen, waardoor het niet mogelijk is ze geïsoleerd te testen. De testgevallen die gedefinieerd zijn kunnen dan alleen worden getest door ze te combineren met de testgevallen die op basis van bijvoorbeeld use case beschrijvingen zijn gedefinieerd. Naast bovengenoemde testspecificatietechnieken worden verder checklists gebruikt, die vanuit de opgedane ervaringen een opsomming leveren van te toetsen en testen aspecten aan het systeem. Aandachtspunt is dat mogelijk op andere aspecten dan normaal moeten worden getoetst. Dit betekent dat hiervoor specifieke checklists moeten worden opgesteld. Tenslotte wordt naast de beschreven testbasis ook gebruik gemaakt van allerlei niet-gedocumenteerde testbasis, zoals de kennis en ervaring van gebruikers. Een vroege betrokkenheid van de tester bij het ontwikkelingsproces, met name het afstemmingsproces tussen ontwikkelaar en gebruiker, is bij iteratieve systeemontwikkeling van groot belang. Dit stelt de tester in staat om ook de nietgedocumenteerde afspraken te kunnen bewaken.

4.5

Infrastructuur

De TMap-pijler infrastructuur betreft de testomgeving, tools en de werkplek. Bij een testproces in een RUP-project is enkel de ondersteuning door tools specifiek. IBM Rational biedt diverse tools die het testproces ondersteunen, zie ook paragraaf 3.4. 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 volgende overwegingen spelen een rol: • Het automatiseren van regressietesten is met name wenselijk als er sprake is van frequente aanpassingen in de software en vaak releases worden uitgebracht. • Automatiseren van tests vraagt een redelijk stabiele basis en software tijdens de ontwikkeling. Als dit niet zo is moeten de testscripts keer op keer worden herbouwd. De stabiliteit wordt o.a. beïnvloed door de mate waarin de user interface wijzigt en de kwaliteit van de decompositie van het systeem in projecten of iteraties. • De tijdlijnen van het testen binnen een iteratie bepalen of er voldoende doorlooptijd is om de testen überhaupt te automatiseren. • Ondersteunt het beoogde tool de grafische schermen? • Zijn er voldoende (senior) testautomatiseerders te werven? Als dit niet zo is, is er ruimte in de planning om mensen daartoe op te leiden? • Is de beheerorganisatie (straks) in staat de geautomatiseerde testset in beheer te nemen?

4.6

Acceptatietest

Bij het gebrek aan voorschriften voor de AT binnen RUP kunnen er twee mogelijkheden worden aanbevolen: • Organiseer en structureer de AT conform TMap • Organiseer en structureer de AT conform de ST mét TMap, zoals beschreven in deze toepassingsvariant. In de eerste mogelijkheid wordt de AT als een zelfstandig proces ingericht, dat betrekkelijk onafhankelijk van het overige RUP-traject verloopt. Met een gedegen test kan dan voldoende zekerheid worden gekregen dat het systeem kwalitatief voldoende Sogeti Nederland B.V. Januari 2003

1.1

pagina 29

TMap en RUP tpv v11

is voor productie. Wél heeft een dergelijke opzet de neiging om afbreuk te doen aan het snelle, iteratieve karakter van het systeemontwikkelingsproces. De reden om hier toch voor te kiezen is dat de organisatie de risico's te groot vindt om rechtstreeks het iteratief ontwikkelde systeem in productie te nemen. In de tweede mogelijkheid wordt de AT op een zelfde wijze als de ST uitgevoerd binnen de RUP-iteraties. Hierbij blijft het iteratieve karakter van het systeemontwikkelingsproces gehandhaafd en wordt binnen dit kader een zo goed mogelijke test georganiseerd. Een derde mogelijkheid is om AT en ST tot één geïntegreerde testsoort (GT) te combineren. In de praktijk is dit meestal een te grote stap die teveel risico geeft dat het testen van onvoldoende kwaliteit en dekking is. Deze mogelijkheid wordt daarom niet aanbevolen.


1.1

pagina 30

TMap en RUP tpv v11

In onderstaande figuur worden de drie mogelijkheden getoond.

AT

ST

AT

ST

AT ST

GT

AT

AT ST

GT

ST

ST

ST

ST

GT

GT

Figuur 12, mogelijke AT-vormen

Welk van beide aanbevolen mogelijkheden de voorkeur heeft, is situationeel. In ieder geval dient vanuit het mastertestplan gecoördineerd te worden dat de ST en de AT goed op elkaar aansluiten wat betreft de testdekking, dus geen onnodige overlap of juist gaten vertonen.


1.1

pagina 31

TMap en RUP tpv v11

5

LITERATUUR • • • • • • • •

Copeland, L., Testing UML Models - Use Cases, STQE Letter June 2002 IBM Rational Software Corporation (1997), UML Summary version 1.0 IBM Rational Software Corporation, diverse RUP white papers, www.rational.com Koomen, T., (2002) Testen van iCBD, www.tmap.net Koomen, T., (2003) Exploratory testing & TMap, www.tmap.net Kruchten, P. (2000), The Rational Unified Process, An Introduction, Second Edition, Addison-Wesley, ISBN 0-201-70710-1 Pol, M., R. Teunissen, E. van Veenendaal (1999), Testen volgens TMap, Tutein Nolthenius, ’s-Hertogenbosch, ISBN 90-72194-58-6 Szymkowiak, P., Kruchten, P. (february 2003), Testing: the RUP philosophy, the Rational Edge, www.therationaledge.com


1.1

pagina 32

TMap en RUP tpv v11

BIJLAGE A, MASTERTESTPLAN VOLGENS RUP EN TMAP In onderstaande tabel zijn de onderwerpen van een RUP MTP globaal uitgezet tegen de onderwerpen van een TMap MTP.

1. 1. 1. 2. 2. 3. 4. 5. 6. 6.

TMap MTP Opdrachtformulering Opdrachtformulering Opdrachtformulering Teststrategie, incl. globale begroting Teststrategie, incl. globale begroting Bedreigingen, risico’s en maatregelen Organisatie Infrastructuur Globale planning Globale planning [Onderdeel van detailtestplannen] [Onderdeel van detailtestplannen] [niet standaard]


1. 2. 3. 4.

RUP MTP Introduction Governing Evaluation Mission Target Test Items Overview of Planned Tests

5.

Test Approach

12.

Master Plan Risks, Dependencies, Assumptions, and Constraints Responsibilities, Staffing, and Training Needs Environmental Needs Testing Workflow Key Project/ Phase Milestones Deliverables Management Process and Procedures Entry and Exit Criteria

10. 9. 8. 11. 7. 13. 6.

1.1

pagina 33

TMap en RUP tpv v11

BIJLAGE B, DETAILVERGELIJKING RUP EN TMAP TESTACTIVITEITEN Onderstaand is een zo volledig mogelijke detailvergelijking opgenomen tussen de testactiviteiten van TMap en RUP. In de eerste tabel staan de TMap-activiteiten per fase, met daarachter de RUP activiteiten. Plaatsen met een "?" hebben geen duidelijke overeenkomstige activiteit. Hierbij moet aangetekend worden dat in RUP een activiteit in meerdere workflows kan voorkomen. In een aantal gevallen is heel duidelijk dat de activiteit binnen een workflow te mappen is op een TMap-activiteit, maar is dezelfde activiteit binnen een andere workflow niet te mappen. Een voorbeeld hiervan is "Define test details" dat binnen Test and Evaluate te mappen is op "Opstellen testspecificaties " binnen TMap-fase Specificatie. Dezelfde activiteit "Define test details" komt ook voor bij "Improve test assets" en "Verify test approach". In deze gevallen is de overeenkomstige TMap-activiteit leeggelaten.

Nr 1 2

TMap Planning Planning

3

Planning

Opdrachtformulering Globale intake en studie Vaststellen testbasis

4

Planning


Evaluate Mission

4

Planning


Evaluate Mission

5 6

Planning Planning

? Evaluate Mission

7

Planning

Inrichten organisatie Inrichten testproducten Definiëren infrastructuur

8

Planning

Inrichten beheer

9 10 11

Planning Planning Beheer

11

Beheer

11

Beheer

12

Beheer

Bepalen planning Fixeren testplan Onderhouden testplan Onderhouden testplan Onderhouden testplan Uitvoeren beheer

12

Beheer

Uitvoeren beheer

13

Beheer

Rapporteren

14

Beheer

1

Voorbereiding Voorbereiding

Bepalen detailplanningen. Uitvoeren detailintake testbasis Definiëren testeenheden

2


RUP Evaluate Mission Evaluate Mission Evaluate Mission

Agree on Mission Identify test motivators Identify targets of test Define test appproach Define assessment & traceability needs Agree on Mission

Verify test approach Define test environment configs. Evaluate Mission Define test approach Evaluate Mission Agree on Mission Evaluate Mission Agree on Mission Achieve Acceptable Assess and improve Mission test effort Achieve Acceptable Assess and Mission advocate quality Improve Test Define assessment Assets & traceability needs Achieve Acceptable Determine test Mission results Improve Test Define test Assets approach Achieve Acceptable Assess and Mission advocate quality Achieve Acceptable Assess and improve Mission test effort ? Evaluate Mission

1.1

Identify test ideas

Nr 2 1 4 3 5

2 1

3 2 2 1 2 6 4 1 2 1

6

pagina 34

TMap en RUP tpv v11

Nr 3

TMap Voorbereiding

3

Voorbereiding

4

Voorbereiding

1

Specificatie

1

Specificatie

1

Specificatie

2

Specificatie

3

Specificatie

Opstellen testspecificaties Opstellen testspecificaties Opstellen testspecificaties Definiëren uitgangsbestanden Opstellen testscripts

3

Specificatie

Opstellen testscripts

Test and Evaluate

4

Specificatie

?

5

Specificatie

5

Specificatie

6

Specificatie

1

Uitvoering

1

Uitvoering

1

Uitvoering

1

Uitvoering

2

Uitvoering

3 4

Uitvoering Uitvoering

4

Uitvoering

5

Uitvoering

Opstellen testdraaiboek Specificeren intake testobject/ infrastructuur Specificeren intake testobject/ infrastructuur Realiseren infrastructuur. Intake testobject/infrastruct uur Intake testobject/infrastruct uur Intake testobject/infrastruct uur Intake testobject/infrastruct uur Vullen uitgangsbestanden Uitvoeren (her)tests Controleren en beoordelen testresultaten Controleren en beoordelen testresultaten Onderhouden

Toewijzen testspecificatietechni eken Toewijzen testspecificatietechnieken Specificeren infrastructuur.


RUP Evaluate Mission

Define test approach

Nr 3

Verify test approach Define test details

4

Verify test approach Define test environment configs. Test and Evaluate Implement test

1

Test and Evaluate

Identify test ideas

6

Test and Evaluate

Define test details

7

Test and Evaluate

Implement test

1

Test and Evaluate

Implement test suite Structure test implementation

2


Implement test

1


Define test details

4

Workflow Environment Validate Build Stability

Support Development Execute test suite

2


Analyze test failure

3


Determine tes results

5



6

Test and Evaluate

Implement test suite Execute test suite Analyze test failure

2


8

Test and Evaluate Test and Evaluate

Test and Evaluate

1

5

3 4

? 1.1

pagina 35

TMap en RUP tpv v11

Nr

TMap

1

Afronding

2

Afronding

2

Afronding

3

Afronding

4

Afronding

5

Afronding ?

RUP

Nr

testdraaiboek. Evalueren testobject

?

Achieve Acceptable Mission Evalueren testproces Achieve Acceptable Mission Evalueren testproces Improve Test Assets Opstellen Achieve Acceptable evaluatierapport Mission Conserveren testware Improve Test Assets Decharge testteam ? Achieve Acceptable Mission Improve Test Assets Improve Test Assets Improve Test Assets Improve Test Assets Improve Test Assets Verify test approach

?

Verify test approach

? ?

Verify test approach Verify test approach

? ?

Verify test approach Verify test approach

? ? ? ? ?

Assess and improve test effort Assess and improve test effort Prepare Guidelines for Project Assess and advocate quality Structure test implementation

1 1 9 2 2

Identify test ideas

3

Define testability elements Identify test ideas

3

Define test details

5

Implement test

7

Implement test suite Identify testability mechanisms Define testability elements Define test details Implement test suite Implement test Obtain testabilty commitment

8

4

2 3 4 5 6 7

De tabel kan ook anders gesorteerd worden, van RUP naar TMap:

1


2 3

Evaluate Mission Evaluate Mission

2 3

Evaluate Mission Evaluate Mission

2 2 3

Evaluate Mission Evaluate Mission Evaluate Mission

4

Evaluate Mission


Identify test motivators Agree on Mission Define test appproach Agree on Mission Define test approach Agree on Mission Agree on Mission Define test approach Identify targets of test

TMap Planning

Globale intake en studie

2

Planning Planning

Opdrachtformulering Bepalen teststrategie

1 4

Planning Planning

Inrichten testproducten Inrichten beheer

6 8

Planning Bepalen planning Planning Fixeren testplan Voorbereiding Toewijzen testspecificatietechnieken Planning Vaststellen testbasis

1.1

9 10 3 3

pagina 36

TMap en RUP tpv v11

5


6 1

Evaluate Mission Verify test approach

1

Verify test approach

2

Verify test approach Verify test approach Verify test approach Verify test approach Verify test approach Verify test approach Validate Build Stability Validate Build Stability Validate Build Stability Validate Build Stability Validate Build Stability Validate Build Stability Test and Evaluate Test and Evaluate Test and Evaluate Test and Evaluate Test and Evaluate Test and Evaluate Test and Evaluate Test and Evaluate Test and Evaluate Test and

3 4 5 6 7 1 2 3 4 5 6 1 1 2 2 3 4 5 6 7 8


Define assessment & traceability needs Identify test ideas Define test environment configs. Define test environment configs. Identify testability mechanisms Define testability elements Define test details Implement test suite Implement test

TMap Planning


4

Voorbereiding Definiëren testeenheden Planning Definiëren infrastructuur

2 7

Voorbereiding Specificeren infrastructuur

4

? ? Voorbereiding Toewijzen 3 testspecificatietechnieken ? ?

Obtain testabilty commitment Implement test

?

Execute test suite

Uitvoering

Analyze test failure Define test details

Uitvoering

Determine tes results Assess and advocate quality Implement test

Uitvoering

Implement test

Specificatie

Implement test suite Implement test suite Execute test suite

Specificatie

Definiëren uitgangsbestanden Opstellen testscripts

Uitvoering

Vullen uitgangsbestanden 2

Uitvoering

Uitvoeren (her)tests

Analyze test failure Structure test implementation Identify test ideas

Uitvoering Specificatie

Controleren en 4 beoordelen testresultaten Opstellen testscripts 3

Specificatie

Opstellen testspecificaties 1

Define test details

Specificatie

Opstellen testspecificaties 1

Determine test

Uitvoering

Controleren en

Specificatie

Specificatie

Uitvoering Specificatie

1.1

Specificeren intake testobject/ infrastructuur Intake testobject/infrastructuur Intake testobject/infrastructuur Specificeren intake testobject/ infrastructuur Intake testobject/infrastructuur Intake testobject/infrastructuur Opstellen testspecificaties

5 1 1 5 1 1 1 2 3

3

4 pagina 37

TMap en RUP tpv v11

1

1

1

1

2

2

2

3

4

1 2 3 4 5 6

7 8 9

RUP Evaluate Achieve Acceptable Mission Achieve Acceptable Mission Achieve Acceptable Mission Achieve Acceptable Mission Achieve Acceptable Mission Achieve Acceptable Mission Achieve Acceptable Mission Achieve Acceptable Mission Achieve Acceptable Mission Improve Test Assets Improve Test Assets Improve Test Assets Improve Test Assets Improve Test Assets Improve Test Assets Improve Test Assets Improve Test Assets Improve Test Assets Workflow Environment ? ? ?


TMap results Assess and Beheer improve test effort

beoordelen testresultaten Onderhouden testplan 11

Assess and Beheer improve test effort

Bepalen detailplanningen

14

Assess and Afronding improve test effort

Evalueren testobject

1

Assess and Afronding improve test effort

Evalueren testproces

2


Beheer

Onderhouden testplan

11


Beheer

Rapporteren

13


Afronding

Opstellen evaluatierapport

3

Identify test ideas

?


Beheer

Uitvoeren beheer

12

Define test approach Structure test implementation Define testability elements Identify test ideas

Beheer

Uitvoeren beheer

12

Afronding

Conserveren testware

4

Define test details

? Onderhouden testplan

11

Evalueren testproces

2

Realiseren infrastructuur

6

Inrichten organisatie Uitvoeren detailintake testbasis Opstellen testdraaiboek

5 1

? ?

Define assessment Beheer & traceability needs Implement test ? Implement test ? suite Prepare Guidelines Afronding for Project Support Specificatie Development Planning Voorbereiding Specificatie 1.1

4 pagina 38

TMap en RUP tpv v11

RUP ?

TMap Uitvoering

?

Afronding


1.1

Onderhouden testdraaiboek Decharge testteam

5 5

pagina 39

TMap en RUP tpv v11

BIJLAGE C, VERGELIJKING TMAP PRODUCTEN MET RUP ARTIFACTS TMap

Opmerkingen

RUP

• • •

Mastertestplan Testplan Detailintake-rapport

Zie ook bijlage A.

• • -

•

Testeenhedenmatrix (incl. testspecificatietechnieken) Vereiste infrastructuur (uit test plan) Gedetailleerde specificatie van de infrastructuur Operationele infrastructuur Testspecificaties Testspecificaties

• •

• • • •

• • •

•

• • -

Kwaliteitsattributen voor dynamisch impliciet en statisch testen Testspecificaties

Testdraaiboek Testproducten (gedefinieerd in test plan) Beschrijving beheerprocessen (in testplan) Testscript Testresultaten

•

Bevindingen

• • •

Testvoortgangsrapport Eindrapport Eindrapport


Niet gedefinieerd in RUP, wel worden tussenproducten gereviewed Niet gedefinieerd in RUP

Master Test Plan Iteration Test Plan

-

TMap maakt geen onderscheid in de producten tussen wel of geen testautomatisering

• •

Test Environment Configuration Test Automation Architecture

“Testsituaties” deel “Logische testgevallen” deel Bijvoorbeeld performance, in TMap niet gedefinieerd als een apart product maar als testvorm. “Fysieke testgevallen” deel

• •

Test-Ideas List Test Case

•

Workload Analysis Model

• • • •

Test Data Test Script Test Interface Specification Test Guidelines

• • •

Test Suite Test Log Issues List

•

Change Request

•

Test Results

•

Test Evaluation Summary

Niet gedefinieerd in TMap Niet gedefinieerd in RUP

Niet separaat gedefinieerd in TMap, het betreft een soort "knelpuntenlijst" Een change request in RUP kan zowel een bevinding zijn als een wijzigingsvoorstel

1.1

pagina 40

TMAP EN RATIONAL UNIFIED PROCESS

Recommend Documents