Inmiddels onderkennen de meeste organisaties de ernst en het onvermijdelijke van ‘het jaar 2000’. Vrijwel alle bestaande systemen zullen de komende twee jaar toe zijn aan ‘groot onderhoud’ en moeten dus worden getest. Met geautomatiseerd testen kan snel resultaat worden geboekt vooral als dit concept pragmatisch wordt aangepakt, propageert een medewerker van Compuware.
Testen en onderhouden van bestaande systemen is altijd moeilijker geweest dan het ontwikkelen van nieuwe functies. Daarom heeft de industrie weinig aandacht besteed aan het verbeteren van het testen. Het probleem is hierdoor alleen maar groter geworden. Zelfs kleine aanpassingen kunnen al tot grote chaos leiden door de complexiteit van systemen.
De testkosten zijn ongemerkt gegroeid, terwijl het testen zelf de helft van alle inspanningen in de IT vergt. Om zich een beeld te kunnen vormen van de mogelijke gevolgen van de ‘millennium madness’, denken velen aan de eigen ervaringen met het handmatig testen en implementeren van instabiele applicaties.
De benodigdheden voor ‘economy of scale’, herbruikbaarheid en gecontroleerde simulaties van de toekomst, illustreren de behoefte aan het fabrieksmatig automatiseren van het testproces. Voor iedere toepassing is er wel een groep van gebruikers die kan vaststellen of een nieuwe versie niet correct functioneert. Deze kennis moet zo snel mogelijk worden omgezet in een set gestructureerde en herhaalbare testware. Deze programmatuur moet de toepassing blijvend ondersteunen tijdens de gehele levenscyclus, inclusief de euro-implementatie en het reguliere onderhoud. Een fabrieksmatige aanpak legt de nadruk op het automatiseren van totale processen. Hier kan het testen geen uitzondering blijven.
Van handwerk tot testfabriek
Een testfabriek ondersteunt de realisatie en het beheer van alle vormen van ’testware’. Zo’n fabriek bevat de complete reeks test- en implementatietools, toegespitst op het eigen proces. Elke applicatie kent haar eigen testtraditie, soms afhankelijk van ervaren mensen die testgegevens creëren en tests dynamisch herhalen. In andere gevallen zijn testtradities handmatig gedocumenteerd en gestructureerd. Een groeiend aantal applicaties heeft permanente gegevens en geautomatiseerde scripts voor het testen, vaak op de PC. De testfabriek moet in staat zijn om alle applicaties te behandelen, onafhankelijk van de tot nu toe gevoerde testtraditie.
De medewerkers, die traditioneel al bij het testen waren betrokken, moeten ook bemoeienis krijgen bij het realiseren van herhaalbaar testen. Ervaring wijst uit dat het verkeerd is om de verantwoordelijkheid voor het automatiseren hiervan bij de tester zelf neer te leggen. Deze spant zich het best in bij het testen, en een ander – de testtool-specialist – automatiseert het proces op de beste manier. Het inschakelen en eventueel zelf opleiden van dergelijke specialisten is in elk geval een zinnige en zelfs verstandige investering. De millennium-bug vereist een veel grotere test-inspanning dan de IT-industrie tot op heden gewend is. Gelukkig wordt er in de hogere regionen van onze economie gewerkt met testtool-specialisten die de testers ondersteunen en begeleiden.
Door de oorspronkelijke applicatietester niet verantwoordelijk te maken, is het automatiseren van een test te realiseren met slechts 20 à 25 procent meer inspanning. Gebruikmaken van specialisten voor het automatiseren van tests bevordert de onderhoudbaarheid van de geautomatiseerde tests en helpt belangrijke besparingen te realiseren bij toekomstige tests.
Tot nog toe sluitpost
Dat neemt niet weg dat zeer praktische en daardoor niet minder valide argumenten een gestructureerde aanpak van het testen vaak in de weg staan. Het grootste probleem daarbij is tijd, veelal het sluitstuk bij productontwikkeling. Vaak zelfs wordt in de planning, voordat deze in productie gaan, onvoldoende rekening gehouden met het testen van systemen.
Veel applicatiebouwers doen zogenoemde regressie-tests zonder baseline-test. Dit gebeurt omdat de normale methoden niet gepland, gedocumenteerd of herhaalbaar zijn. In een dergelijk langzaam proces is er geen tijd om meer dan één testcyclus te doorlopen. Dus worden de resultaten eenmalig gegenereerd en handmatig gecontroleerd. De traditionele tester controleert de resultaten niet tegen al geregistreerde en gecontroleerde gegevens, maar hanteert zijn eigen, ongedocumenteerde verwachtingen – op het moment dat de resultaten verschijnen – als maatstaf.
De armoedige erfenis van deze traditie – grotendeels de schuld van het budgetteren van het testen ‘per project’ en niet per applicatie-levenscyclus – is een gebrek aan herbruikbaar testmateriaal, terwijl de meeste toepassingen al vele dure, maar onbetrouwbare, regressietests hebben ondergaan.
Redenen genoeg om een aanpak te ontwikkelen die aan de praktische bezwaren tegemoet komt. De Pragmatic Test Approach (PTA) vat de ervaring van specialisten met tientallen geslaagde projecten samen in een model.
Traditievriendelijke benadering
De eerste fase van PTA betreft het stellen van doelen en maatstaven. Daarna volgt een analyse- en planningslag. Het doel hiervan is het leggen van een drie-dimensionale relatie tussen de zakelijke functies in de toepassing, de technische componenten waaruit de toepassing bestaat en de namen van de te bouwen tests. De testers worden bij deze fasen betrokken; dit helpt hen om hun gebruikelijke testactiviteiten in het plan te plaatsen. Technici werken samen met de testers om begin- en eindstanden van data te extraheren, ingetoetste testdata op te nemen en data en scripts te bewerken tot herhaald uitvoerbare bouwstenen.
Al deze kleine onderdelen worden in een centraal testbed gezet en genereren aan de hand van het testplan verschillende soorten eindtests (unit-, integratie-, regressie-, stresstest enzovoort).
In de loop van een ‘jaar 2000’-conversie moeten alle applicaties, voorafgaande aan de conversie, een baseline-test ondergaan. Deze fungeert als basis voor het geautomatiseerd evalueren van de resultaten van de regressietests van de geconverteerde applicaties. Alle geconverteerde systemen moeten vervolgens een regressietest ondergaan om te waarborgen dat zij in de toekomst blijven werken, ook na het jaar 2000.
In werkelijkheid zullen er meer dan drie van deze volledige cycli voor elke applicatie nodig zijn, omdat het noodzakelijk is de constant veranderende mengeling van wel en niet geconverteerde systemen in productie regelmatig aan integratietesten te onderwerpen.
Voorspellende tijdreis
Om ‘jaar 2000-bestendigheid’ te kunnen bepalen, zijn vier regressietests nodig die zijn bedoeld om programma-executie in de toekomst te simuleren.
1 Onderscheppen en wijzigen van de huidige datum zoals deze door het besturingssysteem aan de te testen programma’s wordt doorgegeven.
2 Identificeren en manipuleren van data in de testgegevens.
3 Onderscheppen en wijzigen van data die de applicatie genereert of die hierin zijn opgeslagen.
4 Identificeren van verschillen, daar waar dat nodig is.
Voor al deze activiteiten zijn tools voorhanden. Het toepassen van deze tools en technieken stelt het programma in staat om op tijdreis te gaan. Toepassing op de geautomatiseerde basistest levert de mogelijkheid tot voorspellend testen. Op deze wijze kan men de capaciteit optimaliseren die nodig is voor analyse en conversie.
Tools en traditie
De totale inventaris van processen en hulpmiddelen van elke individuele testfabriek is uniek, omdat deze afhangt van de bestaande infrastructuur en testtradities. Deze hulpmiddelen zijn echter altijd gebaseerd op de, in dat model gepresenteerde, generieke processen en groepen van tools. De in deze fabriek gedefinieerde en gebruikte tools behoren tot drie te onderscheiden categorieën.
De eerste categorie, standaardproducten, omvat standaard hulpmiddelen die tot de ontwikkelomgeving behoren en aangekochte producten voor veranderingsmanagement en test-automatisering. De tweede categorie, maatwerkproducten, omvat een unieke reeks tools die worden gecreëerd door het modificeren van interfaces van standaardproducten. Belangrijk is hier dat de tools ontwikkeld zijn voor algemeen gebruik binnen de fabriek voor de meeste of alle applicaties.
De derde categorie, producten die voor de applicatie zijn aangepast, betreft modificatie of het geheel bouwen om een specifieke eigenschap van een enkele applicatie af te dekken. Vanzelfsprekend zal het fabrieksteam, met de toolspecialist voorop, er alles aan doen om die laatste categorie zo beperkt mogelijk te houden.
Men kan zowel de standaardproducten als de maatwerkproducten onderverdelen in vier typen die nodig zijn om de vier dimensies van een ‘system under test’ te beheren en te automatiseren: de interactie van gebruikers en testers met het systeem; de interactie van de geteste programmatuur met externe gegevens; de interne logica van programma’s en de gegevens in hun eigen opslag; de interactie van de geteste programmatuur met het besturingssysteem en zijn subsystemen.
Planning van de ‘fabriek’
Een projectbureau, dat een ‘jaar 2000’-testfabriek moet opzetten, dient de fysieke capaciteit voor de totale millennium-testinspanning te plannen en te verwerven, naast het opzetten en bemannen van de fabriek. Per applicatie moet er een plan komen onder verantwoordelijkheid van de betreffende testmanager.
Tot het ‘jaar 2000’-testproces behoort een plan, gebaseerd op fysieke testcases. Elke case beschrijft de uitvoering van ofwel een batch job, een online-testscript of een nauwkeurige reeks handelingen, met een exacte beschrijving van de te gebruiken dataconfiguratie. Alvorens een lijst van uit te voeren tests tot stand te brengen, moet elk project twee gedetailleerde inventarisaties maken: één van de bedrijfsprocessen die door de applicaties worden ondersteund en één van de fysieke componenten die nodig zijn om de applicatie te assembleren en te laten werken.
Deze voorbereiding vergt een effectief en geslaagd fysiek testplan dat een parallel logisch testplan ondersteunt. Dit proces helpt zowel de projecten die weinig of geen geformaliseerde testplannen hebben als de projecten die reeds gebruikmaken van gestructureerde planningstechnieken. De eerste groep kan elke hulp gebruiken en de tweede heeft in het algemeen gebrek aan effectieve fysieke planning met een goed configuratiemanagement. De reden hiervoor is dat de meeste pogingen van de laatste jaren om gestructureerde testtechnieken in te voeren, niet direct waren gerelateerd aan het automatiseren hiervan.
Opnieuw bruikbaar
De extra inspanning voor het automatiseren van tests tijdens de allereerste cyclus, levert in de meeste gevallen een reductie van 60 procent van de totale inspanning van een tweede regressietest. Wanneer de ’testware’ systematisch kan worden onderhouden, zodat het functionele wijzigingen in de applicaties ondersteunt, is hij herbruikbaar voor het structurele onderhoud en voor toekomstige conversies. Door herbruikbaarheid in de testware in te bouwen, kan de effectiviteit sterk toenemen, terwijl de kosten zo’n 70 tot 80 procent lager komen te liggen.
Het toepassen van het concept van de softwarefabriek op geautomatiseerd testen is de enige manier om de grote hoeveelheid tests economisch acceptabel te maken. Waar code-analyse en projectmanagement van 2000-projecten eenmalige investeringen zijn, zonder toegevoegde waarde, zorgen implementatie van veranderingsmanagement en geautomatiseerd testen voor significante infrastructurele verbeteringen.
Wanneer kleine logische eenheden direct herhaalbaar worden gemaakt, zijn veel spontane herhalingen te vermijden, die gebruikelijk zijn bij niet gedocumenteerd handmatig testen. Het gevolg is dat de totale inzet niet per se groter hoeft te zijn dan bij een enkele handmatige testcyclus.
Michael Feord, account manager Testing & Implementation, Compuware B.V.
