Inzet van gereedschappen vaak oorzaak testexplosie
De software wordt overgedragen aan de applicatiebeheerder. Die ondersteunt de software in het proces van gebruik en beheer. En de testware? Wat moet men doen met testware die in het ontwikkelingsproject is mee-ontwikkeld? Testwarebeheer wordt een van de hot items in de komende tijd. Een organisatie die het negeert zal in de toekomst onnodig veel tijd en geld aan het uitvoeren van (her)tests kwijt zijn. Het streven naar een kwalitatief beter softwareontwikkelingsproces en een beter lopend beheerproces is algemeen aanwezig in de IT-wereld. Talloze initiatieven op het vlak van CMM en ITIL zorgen voor beter beheersbare processen. Voor het testen van systemen geldt een dergelijk verhaal, het gebruik van TMap, TPI, TestFrame en mogelijk van TMM, levert een beter gestructureerd testproces op. Dit impliceert dat duidelijker omschreven staat wat er wel en niet getest moet worden. Het gevolg is dat ook de hoeveelheid testware toeneemt. In een effectief testwarebeheer – verdergaand dan het alleen opslaan van gegevens in ordners – is echter veelal nog niet voorzien. Een zeer groot deel van al de uit te voeren tests zijn de regressietests, die meermalen na elkaar uitgevoerd worden met als doel het controleren op of aantonen van wijzigingen in verschillende softwareversies. Hergebruik van eerder opgezette software is voor regressietests een noodzakelijke voorwaarde. De oplossingen die tot nu toe worden aangedragen om hergebruik mogelijk te maken, liggen veelal op het vlak van testautomatisering. Wanneer tests zo worden opgezet dat men ze met een tool kan uitvoeren, dan zijn die tests met minimale inzet meermalen opnieuw uit te voeren. Testautomatisering levert mogelijkheden van hergebruik van testware. Maar aan alle voors kleven tegens. De praktijk leert dat het inzetten van testtools regelmatig niet leidt tot een verkorting van de totale testtijd, maar tot een ‘testexplosie’, tot het explosief toenemen van het aantal tests dat uitgevoerd moet worden binnen een zelfde tijdsbestek als voorheen. En dit gaat gepaard met zo’n grote hoeveelheid testware, dat het bewaren hiervan bedrijfseconomisch niet meer te verantwoorden is. Met als gevolg dat om die reden van hergebruik wordt afgezien, of erger nog, dat het testen op een laag pitje wordt gezet. Het toenemend aantal tests en het toenemend hergebruik ervan, zorgen ervoor dat het invullen van een adequaat testwarebeheer in de komende tijd een acuut vraagstuk wordt. Voordat begonnen wordt met het opzetten van de tests moet gekeken worden naar het testwarebeheer. Hoe moet men op termijn met de testware omgaan? Voordat men kan beoordelen wat er opgepakt moet worden, is er een aantal vragen dat beantwoord moeten worden: • Waarom zou men testware eigenlijk beheren? • Wat moet er beheerd worden? • Hoe moet men de testware bewaren? • Wie moet het beheer uitvoeren? Eerst nadat men deze vragen op een voor de organisatie bevredigende wijze heeft beantwoord, kan men doorgaan met het invullen van het testwarebeheer. Opruimen Om te beginnen de eerste vraag: Waarom zou men testware beheren? Wat schiet men ermee op? Kan men niet beter alles weggooien? Inderdaad, wanneer er niets te verdienen valt met het bewaren van testware moet men het gelijk opruimen. Testware bewaren en beheren is geen doel op zich. Het doel van testwarebeheer is in eerste instantie het besparen van tijd en geld door het mogelijk maken van hergebruik van testware. Testwarebeheer zet men op wanneer hergebruik van tests is gepland. Dat is het geval wanneer nieuwe versies van de programmatuur zijn voorzien, versies waarop die tests ook nog toe te passen zijn. Het aanpassen van de tests zal vaak nodig zijn. Dergelijke aanpassingen moeten alleen dan worden uitgevoerd wanneer ze minder resources kosten dan het opnieuw opzetten van tests. Een voorbeeld. In een project wordt een drietal subsystemen opgezet, voor ieder systeem zijn achthonderd, geautomatiseerd uit te voeren, tests gedefinieerd. Op het moment van ingebruikneming is al een tiental softwareversies geproduceerd. Was voor elke versie nieuwe testware opgezet, dan zou dit geleid hebben tot een investering van 10 (versies) maal 2400 (tests) maal 17 (minuten ontwikkelingstijd per testgeval) is 6800 uur, ofwel ruim vier manjaren. Na de introductie van testwarebeheer zijn de kosten gewijzigd in testontwikkeling (1 x 2400 x 17 = 680 uur), testcorrectie (1 x 2400 x 11 = 440 uur), testonderhoud (9 x 2400 x 2 = 720 uur) en testbeheer (10 x 2400 x 1 = 400 uur), totaal 2240 uur. Dat is dus een besparing van 4560 uur, ofwel bijna drie manjaren. Hierbij is overigens de tijd voor testuitvoering buiten beschouwing gelaten. Steeds weer opnieuw ontwikkelen en uitvoeren van dezelfde tests is een vorm van kapitaalvernietiging die in een sterk competitieve markt niet vol te houden is. Zonder testwarebeheer zou het testproces van het voorbeeld anders zijn uitgevoerd. Het gebruiken van weggooitests leidt in de praktijk tot een keuze tussen verlaging van de kwaliteitsgaranties of verlenging van de doorlooptijd van het project met de daarmee samenhangende hogere budgetten. Er zijn ook heel andere redenen aan te geven om het beheer van testware te rechtvaardigen. Juridische argumenten bijvoorbeeld (aansprakelijkheid bij disfunctioneren, aan kunnen tonen van optimale inzet van kennis en middelen voor kwaliteitsbewaking) kunnen wel leiden tot het opzetten van een beheerstrategie. Dit geeft overigens nog geen garantie voor het hergebruik, voor een efficiënt beheer van testware. Zinvol en helder Ten tweede: Wat moet er beheerd worden? Testware moet men beheren. Maar alle testware? Wat valt er eigenlijk onder testware? De definitie volgens TMap is: ‘Alle testdocumentatie, zoals testspecificaties, testscripts en een beschrijving van de testinfrastructuur, die tijdens het testproces wordt geproduceerd’. Testware omvat een wijd spectrum van objecten, variërend van een mastertestplan voor een totaal project via het script dat een (eventueel geautomatiseerde) test aanstuurt tot de resultaten van een testrun. Niet voor elk van deze objecten geldt een zelfde bewaarstrategie. De projectdocumenten (planningen et cetera) zijn in dit kader niet meer van belang. Beheer van de (master)testplannen is nodig om te kunnen bepalen wat de teststrategie is waarop de verzamelde tests zijn gebaseerd. Het bewaren van de logische testspecificaties is vrijwel altijd aan te raden, het bewaren van de fysieke testspecificaties heeft alleen dan zin, wanneer de voor het testen gebruikte interface niet aan te grote veranderingen onderhevig is. Bij een hoge wijzigingsgraad kost het opnieuw opbouwen minder dan het bewaren en beheren. Het bewaren van testresultaten is zinvol wanneer deze resultaten vergeleken worden met de resultaten van nieuw uit te voeren tests, of wanneer dit juridisch noodzakelijk is. Maar alleen bewaren is niet voldoende. Op de een of andere wijze moeten de gegevens ook toegankelijk zijn. Het bewaren moet dus ook gestructureerd zijn. De derde vraag is: Hoe moet men de testware bewaren? Zo lang de testware beheerd wordt door de testontwikkelaars zelf is er niets aan de hand. Zij weten hoe de tests in elkaar steken en kunnen fouten in de tests snel opsporen en wijzigingen snel aanbrengen. Zij hebben ook inzicht in de relatie met de software, in de gevolgen van een software-change voor de testware. Is echter de testware overgedragen, dan moet ook voor de nieuwe beheerder de structuur van de tests en de relatie tussen testware en software helder zijn (ook op het niveau van systeemdocumentatie, de relatie functioneel ontwerp/testplan bijvoorbeeld). Dit fenomeen heeft binnen de softwareontwikkeling al lang de aandacht. Allerlei initiatieven zijn genomen om relaties binnen de software helder te maken en te houden. Initiatieven die variëren van documentatiestandaards tot case tools. Op de een of andere wijze moet binnen de testware ook helder gemaakt worden wat de relaties zijn. Beoordeelt men het gestructureerd testen op z’n merites, dan is het een parallel ontwikkelingstraject. Het testsysteem wordt gebouwd naast de software, op basis van dezelfde uitgangspunten (eisen, ontwerp), maar door andere mensen. De relatie tussen testware en software ligt in elk geval op het vlak van de uitgangspunten vast. Alle elementen van de testware moeten dan ook naar die uitgangspunten te herleiden zijn. Een mogelijkheid is om binnen de logische testspecificaties aan te geven op basis van welke requirements, op basis van welk deel van de functionele systeemspecificaties, de test gedefinieerd is. Wijzigt er iets in die specificaties, dan kunnen relatief eenvoudig de betrokken tests geselecteerd worden. Bedrijfspolitiek Tot slot: Wie moet het beheer uitvoeren? Deze vraag is van een geheel andere orde dan de andere vragen. Op dit punt komt bedrijfspolitiek om de hoek kijken. Wie wordt er met de testware opgezadeld, wie moet zijn aandacht ook nog daaraan besteden? Het onderbrengen van testwarebeheer in de organisatie kan op uiteenlopende wijze. Per organisatie zal bekeken moeten worden welke vorm op dat moment voor de organisatie optimaal is. Om dit te kunnen beoordelen moet antwoord gegeven worden op onder meer de volgende vragen: • Hoe steekt de organisatie rond het testen in elkaar? Is er sprake van een testcentrum, een gecentraliseerd onderdeel waar het testen is ondergebracht, dan ligt het voor de hand het beheer binnen of direct naast het testcentrum onder te brengen. Is er niet zo’n testcentrum aanwezig, dan moet elders in de organisatie gekeken worden naar de onderdelen die bij het testen betrokken zijn. Is er een onderdeel dat het merendeel van de tests uitvoert, dan is dat onderdeel wellicht het meest gebaat bij het opzetten van testwarebeheer. • Wie moet de tests uitvoeren? Voor het bewaren van testware is het van belang te weten wie de tests uit moet voeren. De systeemontwikkelaar zal de meer technisch gerichte tests uitvoeren, de gebruiker voert meer functioneel gerichte tests uit, de beheerder zal kijken naar tests gericht op het bepalen van performance, van betrouwbaarheid. De geschetste testuitvoerders zijn ook degenen die in het geval van wijzigingen in de software de tests zullen moeten onderhouden. Het ligt voor de hand dat die groepen ook ieder hun eigen tests beheren, in het geval van projecten zal wel naar een vaste beheerder gezocht moeten worden. • Wie heeft er welk belang bij het beheer? Heeft de afdeling die de tests uit moet voeren ook direct belang bij die actie? Wanneer het een belang indirect of op termijn is (betere kwaliteit systeem met als gevolg minder probleemoplossing in gebruik), is het maar de vraag of er voor gekozen wordt er veel tijd en energie in te steken. Het onderbrengen van softwarebeheer en testwarebeheer in één hand, is funest voor het beheer van de testware. De directe baten van het softwarebeheer zijn duidelijk: de gebruiker kan verder. Het oplossen van acute problemen gaat voor en het testwarebeheer dreigt te verworden tot een opvulactiviteit. • Wie is de eigenaar van de testware? Is er wel iemand identificeerbaar als eigenaar van de testware? Is dit niet het geval, dan is er niemand eindverantwoordelijk en blijft de testware een hete bal die niemand op zijn bord wil hebben. Hoe dan ook, vanuit de projectorganisatie die de software en testware ontwikkelt, zal energie gestoken moeten worden in het overdraagbaar en acceptabel maken van de testware. En net als bij de overdracht van software is de overdracht van testware een potentiële bron van problemen. Zonder garanties rond de kennis van de toekomstige gebruikers van de testware is elke vorm van beheren onvoldoende. Voor de testware zullen in grote lijnen de voorwaarden gelden die eveneens gelden voor de over te dragen software. Kortom, de eisen vanuit de markt met betrekking tot kortere doorlooptijden, kostenbesparing en tegelijkertijd kwaliteitsverhoging maken het denken over het testproces onvermijdelijk. De teststrategie maakt duidelijk welke keuzes op het vlak van kwaliteitsbeheersing gemaakt zijn. Testautomatisering kan daarin een rol spelen, zij vergroot het aantal tests dat binnen een bepaald tijdsbestek uitgevoerd kan worden, maar heeft in de praktijk als gevolg dat een toenemend aantal tests beheerd moet worden. Testwarebeheer is een integraal onderdeel van het testproces. Een organisatie die aan het beheren ervan onvoldoende aandacht schenkt, zal onnodig veel tijd en geld kwijt zijn aan het uitvoeren van tests. Sybren Brouwer is testadviseur en lid van de werkgroep ‘Testen en Beheer’ van TestNet. TestNet is het platform voor het uitwisselen van kennis op het gebied van testen van IT-producten (www.TestNet.org).