In het eerste deel van dit artikel (Computable 8) is aangegeven op welke manieren het gestructureerd testen van meerwaarde kan zijn. In dit tweede deel diepen we een aantal punten verder uit en geven aan hoe het gestructureerd testen in de praktijk kan worden vormgegeven.
Een testanalyse vindt meestal plaats voordat het ict-systeem opgeleverd is en start meestal op het moment dat de requirements opgesteld zijn. De requirements zijn de testbasis voor de op te stellen testclusters (verzameling testcondities, logische en fysieke testgevallen) en testscenario’s (een aaneenschakeling van gebeurtenissen die samen een business proces afdekken).
De requirements specifiers hebben in principe hun werk voor een desbetreffende set van requirements, bijvoorbeeld voor een iteratie, gedaan. Door de requirements specifiers te betrekken bij het opstellen van de testscenario’s wordt de kennis van de business optimaal benut. Als de requirements specifiers immers niet weten welke business scenario’s het ict-systeem moeten ondersteunen, wie weet het dan wel? Meerwaarde kan dan ook gerealiseerd worden, doordat de requirements specifiers een initiële versie van de testscenario’s opstellen die dan later door de testanalist verder uitgewerkt kan worden. Zie figuur …
Dezelfde testscenario’s kunnen ook weer gebruikt worden als input voor de testscenario’s die bij de acceptatietest gebruikt worden. Het is natuurlijk zo dat de acceptant (een representant van de opdrachtgever met veel business kennis) acceptatiecriteria en bijbehorende testscenario’s opstelt waarmee bepaald wordt of het te leveren ict-systeem geaccepteerd kan worden. De praktijk wijst uit dat het voor de acceptant niet altijd even gemakkelijk is dergelijke zaken op te stellen.
Het aanbieden van de testscenario’s aan de acceptant heeft een aantal voordelen:
er is extra controle of de testscenario’s de juiste scenario’s zijn en of deze ook dekkend zijn. Vindt de acceptant dit niet de juiste scenario’s, dan is er waarschijnlijk iets misgegaan bij het opstellen van requirements. Een zeer zinvolle extra controle, ook helemaal in overeenstemming met het continu sturen op kwaliteit, zoals RUP dat aangeeft.
Verder wordt een acceptant vroegtijdig gedwongen om na te denken met behulp van welke criteria hij het ict-systeem wil accepteren. Het belangrijke acceptatieproces wordt op deze manier meer bij het project betrokken en de betrokkenheid van de acceptant wordt vroegtijdig geïnitieerd.
De acceptant vindt het meestal lastig om acceptatiecriteria op te stellen. Op deze manier wordt de acceptant ondersteund en vindt er verwachtingsmanagement plaats.
Geautomatiseerd testen
Tijdens de testanalyse worden er testclusters opgesteld. Binnen een testcluster worden op een gestructureerde manier (fysieke) testgevallen gedefinieerd. Doordat RUP een iteratief en incrementeel softwareontwikkelproces is, wordt er elke iteratie dus een deel van het ict-systeem bijgebouwd.
Zoals het figuur ‘UML Model & Implementatie’ duidelijk aangeeft is regressietesten, in dit geval het herhalen van dezelfde test in een volgende iteratie, een belangrijk onderdeel. Doordat de testanalyse gestructureerd opgezet wordt, is de herhaalbaarheid groot. De testanalyse wordt in principe voor elk nieuw deel van het ict-systeem éénmalig uitgevoerd waarna in elke iteratie vanaf dat moment de testuitvoering op basis van die analyse gedaan kan worden. Het opzetten van geautomatiseerd testen op basis van zo’n gestructureerde testanalyse is relatief eenvoudig en doordat de testuitvoering meerdere malen plaatsvindt wordt het punt van return on investment (ROI) relatief snel bereikt.
De kracht van geautomatiseerde testen in een dergelijk RUP-project is dat de testanalyse door de gestructureerde opzet een sterke basis voor de testautomatisering is.
Figuur 3 geeft aan dat de testanalist de basis legt waarbij de testautomatiseerder zich meer op de automatisering zelf kan richten in plaats van het opstellen van testclusters en testgevallen. Het automatiseren kan al starten voordat het ict-systeem opgeleverd is.
Vaak wordt bij testautomatisering gebruik gemaakt van de zogenaamde ‘record-and-play-back’-aanpak, waarbij het noodzakelijk is dat het ict-systeem al opgeleverd is voordat met de testautomatisering gestart wordt. Een bijkomend nadeel is dat bij de ‘record-and-play-back’-aanpak getest wordt vanuit het ict-systeem in plaats van vanuit de testbasis (de afgesproken requirements). Met de eerder aangegeven aanpak worden deze nadelen ontweken.
Gestructureerd testen en RUP
Zoals al in het eerste deel van ‘De meerwaarde van gestructureerd testen binnen RUP’ naar voor kwam, is het gestructureerd testen van meerwaarde binnen RUP. De vraag is echter: past het dan wel goed in RUP? Hoe pak je het aan? RUP zelf geeft goede mogelijkheden om RUP aan te passen; sterker nog: als eerste van de ‘key principles’ van RUP wordt ‘adapt the process’ aangegeven. Via de rational tooling (rational methode composer) is het ook mogelijk om delen van RUP te vervangen of aan te passen. Als er een afgebakend deel vervangen, aangepast of compleet aangevuld wordt dan kan dit met een zogenaamde plug-in worden gedaan.
Voor het gestructureerde testen zoals dat beschreven is in dit artikel, is ook een plug-in gemaakt. Deze plug-in bevat grote wijzigingen in het (test)proces, grote wijzigingen in de (werk)producten zoals templates, voorbeelden, handleidingen en dergelijke en kleine wijzigingen in de standaard RUP-rollen. Een aantal wijzigingen in het proces is in de figuren bij dit artikel weergegeven. Ook de (werk) producten die hier benoemd zijn, vormen een onderdeel van de plug-in.
De wijzigingen die voor het gestructureerd testen in RUP doorgevoerd zijn, zijn gebaseerd op de TestFrame-methodiek. De plug-in heet daarom ook ‘RUP & TestFrame plug-in’. Naast de goede integratie van RUP met het gestructureerd testen (de TestFrame-methodiek in combinatie met Risk and Requirement Based Testing) wordt bij de plug-in ook gebruik gemaakt van de goede integratie van de TestFrame engine met de testtool Rational Robot. Dit betekent, zonder te veel in details te treden, dat Rational Robot vanuit de testanalyse via de ConTest engine wordt aangestuurd. Dit is in overeenstemming met de strategie dat er ook bij het geautomatiseerd testen vanuit de testbasis getest wordt in plaats van uit een gerealiseerd ict-systeem.
Outsourcen en offshore testen
Het inrichten en in de praktijk toepassen van gestructureerd testen levert een aantal voordelen op. Maar hoe zit het dan met het outsourcen van testen? Of het offshore testen?
Door de gestructureerde aanpak is het makkelijker om het outsourcen van testen of het offshore testen mogelijk te maken. Het is natuurlijk ook weer niet zo dat beide direct kunnen, maar de basis ligt er al wel. Bij het offshore testen moet de testbasis natuurlijk (ook) in het Engels opgesteld worden.
Een aandachtspunt is en blijft dat het samenwerken van teams een belangrijk aspect is. Is het dan in tegenspraak? Dat hoeft niet het geval te zijn, zolang het maar geen spreekwoordelijke muur is waar zaken (applicaties, documenten enzovoorts) overheen gegooid worden naar de andere teams toe. Goede communicatie is en blijft erg belangrijk, zeker in een RUP-project. Zeker bij het offshore testen moet er veel aandacht geschonken worden aan de (dagelijkse) communicatie, ook moet rekening gehouden worden met cultuurverschillen.
Als er niet gestructureerd getest wordt, dan is het outsourcen of offshore testen bij voorbaat al gedoemd tot mislukken. Onduidelijkheden die bij gestructureerd testen wel vastgelegd en geregeld zijn, kunnen dan gemakkelijk ontstaan. Hierbij valt te denken aan: onduidelijkheden in het testproces, onduidelijkheden wat de andere partij oplevert en aan welke eisen dat moet voldoen en onduidelijkheden of en hoe een testanalyse wordt gedaan. Bij het ongestructureerd testen is de kans ook groot dat het testen pas start als het ict-systeem al opgeleverd is. Er vindt dan dus geen testanalyse plaats. Een nadeel is dan weer dat je alleen de testuitvoering kunt outsourcen of offshore kunt laten testen. Hierbij moet je dan nog steeds een bepaalde basis (vastgestelde requirements) hebben waartegen getest kan worden, of er moet genoegen genomen worden met een testuitvoering die alleen controleert of er ook fouten optreden zonder dat er verder functioneel naar het ict-systeem gekeken wordt.
Conclusie
Kort samengevat kan inderdaad geconcludeerd worden dat gestructureerd testen binnen RUP zijn meerwaarde heeft. Deze meerwaarde wordt gegeven door de volgende punten: het testproces is gestructureerd en daardoor beter onder controle, het testen start al voordat de software is opgeleverd (minder op het kritieke pad), het acceptatietesten wordt beter geïntegreerd in het testproces, er is een goede basis voor geautomatiseerd testen, de return on investment is relatief snel bereikt, het maakt outsourcen en offshore testen eenvoudiger en er is een plug-in die het gestructureerde testen ondersteund.
Dit is niet alleen in theorie, maar ook in de praktijk bewezen. Het principe wordt onder andere binnen LogicaCMG succesvol toegepast. Hierbij wordt bij een deel van de projecten de testanalyse en de testuitvoering voor het grootste deel in de vestiging in Bangalore uitgevoerd, alleen een deel van de testcoördinatie vindt dan nog in Nederland plaats. Hiervoor wordt gebruik gemaakt van de ‘RUP & TestFrame plug-in’.
Han Duisterwinkel en Nico van der Elst, testconsultants
