Steeds meer organisaties zijn op zoek naar een methode die hen in staat stelt ict-projecten beheersbaar en voorspelbaar uit te voeren. IBM’s rational unified process (RUP) is een veel gemaakte keus. In dit artikel wordt ingegaan op gestructureerd testen binnen RUP. Hoe kan je dit vorm geven? Het artikel is opgedeeld in twee delen. Het eerste deel gaat over de theorie. Het tweede deel gaat in op de toepassing van de theorie in de praktijk.
Systeemontwikkeling binnen RUP is georganiseerd volgens bepaalde disciplines. Een discipline bestaat uit een workflow, activiteiten, rollen en artifacts. De activiteiten vinden binnen elke fase plaats, waarbij het zwaartepunt (inspanning) verschuift. Zie figuur 1.
Daarnaast is RUP opgebouwd uit een zestal best practices (key principles) en sluit zodoende goed aan bij de praktijk. Problemen die in veel systeemontwikkelingtrajecten voorkomen, kunnen met behulp van deze best practices ondervangen worden.
Het opleveren van een kwalitatief goed eindproduct wordt binnen RUP gemeten door middel van testen. Op het gebied van testen onderkend RUP de Testdiscipline. Verder zijn de best practices (iteratief ontwikkelen, managen van requirements, continue kwaliteitsverificatie en beheersing van veranderingen in de software) het meest relevant voor het testproces.
Testen heeft dus een vooraanstaande rol binnen het RUP-ontwikkelproces. Het maximale rendement van het testen wordt behaald door dit op een gestructureerde en herhaalbare manier te doen voor de verschillende testsoorten. De RUP Testdiscipline heeft ten opzichte van gangbare testmethodieken een aantal nadelen. De belangrijkste zijn: het testproces bevat geen gestructureerde testanalyse (voorbereiding van de testuitvoering), het testen komt daardoor direct op het kritieke pad te liggen, het testen begint feitelijk pas op het moment dat de software wordt opgeleverd en niet alle testsoorten zijn in het testproces geïntegreerd. Het testproces is eigenlijk alleen voor de systeemtest in detail beschreven. Naast de systeemtest worden de ‘unit test', ‘unit integratietest' en de ‘acceptatietest' genoemd. Deze zijn echter niet in een proces uitgewerkt. Er zijn erg veel niveaus in het testproces, waardoor het testen onnodig complex gemaakt wordt.
Met de nadelen in het achterhoofd kan het testproces worden aangepast, zodat het mogelijk wordt gestructureerd te testen binnen een RUP-project en zo kort mogelijk op het kritieke pad te komen. In het nieuwe testproces is een aantal activiteiten gedefinieerd die elk een specifiek gebied beslaan. Het proces blijft zodoende overzichtelijk en bevat niet onnodig veel details.
Testanalyse
Het belangrijkste verschil op het hoogste niveau van het testproces is de toevoeging van de testanalyse. De testanalyse is een wezenlijk onderdeel van het gehele testproces. De testanalyse start al als de requirements worden opgesteld.
Het testen begint dus direct aan het begin van het ontwikkelproces en niet pas als de software wordt opgeleverd. Het kritieke pad wordt vermeden.
De opgestelde (en goedgekeurde) requirements zijn de basis voor de verdere testopzet, maar ook voor de implementatie en acceptatie. Aan de hand van deze testbasis worden logische en fysieke testgevallen opgesteld die als basis dienen voor de testuitvoering. De testuitvoering wordt geheel voorbereid waardoor het testen slechts kort, enkel tijdens de testuitvoering, op het kritieke pad terechtkomt.
Het testanalyseproces voorziet tevens in het opzetten van testscenario's voor de acceptatietest. Een testscenario is een aaneenschakeling van gebeurtenissen welke samen een business proces afdekken. Zie figuur 2.
Gestructureerd testen binnen RUP
Vrijwel iedere gestructureerde testmethode kent tegenwoordig een risicogebaseerde aanpak. Door een risicogebaseerde aanpak wordt immers gewaarborgd dat de belangrijkste aspecten als eerste worden getest. Het nieuwe testproces moet deze aanpak dus zeker ondersteunen.
Binnen iteratief ontwikkelen volgens RUP worden in korte tijdscycli de grootste risico´s en de daaraan gerelateerde requirements als eerste opgepakt. Risk and requirement based testing (RRBT) volgt dezelfde gedachtegang: denken vanuit risico's en deze koppelen aan requirements. Binnen RRBT wordt het onderscheid gemaakt tussen projectrisico's en productrisico's. Op basis van de productrisico's zullen de tests worden ingericht. De projectrisico's helpen bij het bepalen van de prioriteit. Het bepalen van de productrisico's gebeurt binnen RRBT op basis van een checklist die is afgeleid van de ISO9126 normering (een erkend Software Engineering Quality Model). Op deze manier wordt op een gestructureerde manier naar de productrisico's gekeken. De productrisico's worden hierbinnen verder onderverdeeld in ‘business' productrisico's en ‘ict' productrisico's.
RRBT heeft als basis dat op ieder moment van de testuitvoering de belangrijkste zaken zijn getest. Als door welke oorzaak dan ook de testduur beperkt is, bestaat zo een goed oordeel over de kwaliteit van de geteste software op dat moment. Deze zienswijze sluit goed aan op de RUP best practice ‘iteratief ontwikkelen'.
Ook de RUP best practice ‘managen van requirements' en deze koppelen aan risico´s is de basis voor zowel RUP als RRBT. De software requirements zijn afgeleid van de wensen van de stakeholders en worden binnen RRBT gekoppeld aan risico's. Zo wordt verzekerd dat er geen risico's zijn zonder bijbehorende requirements. Het testen richt zich dan ook op het testen van die software requirements. De teststrategie bepaalt hierbij de prioriteit en de dekkingsgraad.
Een testmanager die RRBT toepast binnen een RUP-project kan een vliegende start maken, omdat de risico's en requirements al benoemd zijn. De testmanager kan ook betrokken worden bij het opstellen van de risico's. Vanuit de testgedachte kan hij van meerwaarde zijn voor het opstellen van deze risico's.
Past risicogebaseerd testen bij RUP?
Binnen iteratief ontwikkelen volgens RUP worden in korte tijdscycli de grootste risico´s en de daaraan gerelateerde requirements als eerste opgepakt. Risicogebaseerd testen volgt dezelfde gedachtegang: denken vanuit risico's en deze koppelen aan requirements.
De basis van risicogebaseerd testen is dat op ieder moment van de testuitvoering de belangrijkste zaken zijn getest. Als door welke oorzaak dan ook de testduur beperkt is, bestaat zo toch een goed oordeel over de kwaliteit van de belangrijkste onderdelen van de geteste software op dat moment. Deze zienswijze sluit goed aan op de best practice ‘iteratief ontwikkelen'.
Ook de RUP best practice ‘managen van requirements' en dit koppelen aan risico's is de basis van zowel RUP als risicogebaseerd testen. De software requirements zijn afgeleid van de wensen van de stakeholders en worden binnen risicogebaseerd testen gekoppeld aan risico's. Zo is men ervan verzekerd dat er geen risico's zijn zonder bijbehorende requirements. Het testen richt zich dan ook op het testen van de software requirements. De teststrategie bepaalt hierbij de prioriteit en de dekkingsgraad.
Testanalyse en testuitvoering
De software requirements zijn de basis voor het testen. De software requirements worden gevormd door: use cases en de supplementary specifications (use case overstijgende en niet functionele requirements). Een use case is een typische interactie tussen een actor (meestal gebruiker) en het systeem en bestaat uit een beschrijving van het afgebakend deel functionaliteit met bijbehorende data.
Voor een testcluster (verzameling testcondities, logische en fysieke testgevallen) kan een use case vrijwel één op één worden gebruikt. Dit bevordert de overzichtelijkheid en biedt de tester een handvat om testgevallen te herleiden.
Een use case bestaat uit een hoofdstroom en een aantal alternatieve stromen. Elke stroom in een use case wordt in een testcluster gepresenteerd door middel van een testconditie. Zie figuur 3.
Een testscenario wordt opgesteld met behulp van een business scenario. Hierbij ligt de focus op de samenhang tussen verschillende use cases. De testclusters en testscenario's kunnen al opgesteld worden als de betreffende use cases opgeleverd zijn. Het systeem hoeft dus nog niet opgeleverd te zijn.
Door voor een gestructureerde aanpak te kiezen wordt een eenduidige en gestructureerde manier van werken en vastleggen afgedwongen. Verder, wordt de herhaalbaarheid en overdraagbaarheid van de testsets gewaarborgd. Aan het eind van iedere iteratie worden de testclusters voor de bijbehorende use cases, of combinatie van use cases, opgeleverd. In alle volgende iteraties worden deze clusters opnieuw gebruikt om regressietesten uit te voeren. Deze manier van werken wordt ook nagestreefd volgens de RUP best practices iteratief ontwikkelen, continue kwaliteitsverificatie en beheersing van veranderingen in de software.
Om de kwaliteitsontwikkeling goed te kunnen monitoren, worden per cluster de testresultaten bijgehouden en in een vooraf gedefinieerde sheet verzameld voor rapportagedoeleinden. Hierdoor krijgt men op eenvoudige wijze inzicht in de testresultaten en in de kwaliteitsontwikkeling (ook grafisch) van het systeem. Het is op deze manier mogelijk om de rapportage per cluster (use case) maar ook over het gehele testtraject te bekijken.
Het toepassen van een gestructureerde aanpak maakt het mogelijk om over te stappen naar automatisch testen. De handmatige testset kan, afhankelijk van de gekozen gestructureerde methodiek, direct gebruikt worden als input voor de automatische test. Per project moet gekeken worden naar de haalbaarheid van automatisch testen. Als het aantal iteraties groot is en er binnen een iteratie ook herhaaldelijk wordt getest, is het interessant om (delen van) de test te automatiseren. De regressietesten kunnen dan bijvoorbeeld automatisch worden uitgevoerd. Integratie met de Rational Tooling is hierbij goed mogelijk.
Fasering RUP t.o.v. testproces
Tijdens de eerste twee fases van het project, in RUP-termen: de ‘inception' en ‘elaboration fase', is het belangrijk dat de testverantwoordelijke het testplan en de teststrategie voor het volledige testtraject in kaart brengt. De inspanning rond het risicogebaseerd testen ligt dan ook voornamelijk in deze twee fases.
Tijdens elke fase en elke iteratie van het project zal er een deel testanalyse en testuitvoering worden gedaan. In de inception en elaboration fases zal de nadruk liggen op het ondersteunen en opzetten van de teststrategie en inrichting. In de construction fase ligt de nadruk op zowel de testanalyse als de testuitvoering. In de transition fase ligt de nadruk op de testuitvoering. Zie figuur 4.
Conclusie
De onderkende minpunten van de standaard RUP Testdiscipline zijn ondervangen door het introduceren van een nieuw testproces. Het nieuwe testproces is overzichtelijker en voorziet in een testanalyse. De testanalyse start, middels statische testen, direct aan het begin van het ontwikkelproces bij het opstellen van de requirements. Het testen, dat oorspronkelijk pas bij de oplevering van de software zal starten, ligt zo veel korter op het kritieke pad en kan beter (gestructureerd) voorbereid worden.
Vanuit de best practices van RUP is verder gekeken naar een risicogebaseerde testaanpak. Deze aanpak sluit aan bij het iteratief ontwikkelen en managen van ‘requirements'. Een gestructureerde testaanpak voor de testuitvoering werkt ondersteunend bij de best practices iteratief ontwikkelen, continue kwaliteitsverificatie en beheersing van veranderingen in de software.
Han Duisterwinkel, RUP & testconsultant en Nico van der Elst, testconsultant
