TESTSOFTWARE. Probeert u het maar eens

Met de veralgemening van grafische interfaces is het automatisch testen van software een must geworden. Ook niet-informatici krijgen zo middelen in handen om softwareprojekten beter op te volgen.

In vele, vooral kleinere bedrijven heeft de aanpak van software-ontwikkeling nog altijd iets irrationeels, meent Peter Sterck, zaakvoerder van PS-Testware, een gespecializeerd bedrijfje op het Research Park in Haasrode. Software wordt namelijk vaak getest op een moment dat het al zeer moeilijk en duur is geworden om eventuele problemen nog op te lossen : vlak voor de oplevering. Daarna krijgt de gebruiker het produkt in handen met de boodschap “Probeert u het maar eens en geef eens feedback. “

Peter Sterck : “Men neemt het erbij dat er fouten zullen zijn, men vindt dat heel normaal. Een autofabrikant die op die manier over defekten zou denken, zou in geen tijd van de markt zijn geveegd. “

Nochtans bestaan er metodes en produkten die een en ander fel kunnen vergemakkelijken. Ze staan bekend als CAST, computer aided software testing, zeg maar computergesteund testen.

DOKUMENTATIE.

Peter Sterck beweert niet dat er te weinig wordt getest in de softwarebranche. Integendeel, grote gedeelten van de ontwikkelingsbudgetten gaan naar testen. Maar er is iets eigenaardigs aan de hand : terwijl andere bedrijfsuitgaven tot op de frank met dokumenten worden gestaafd, is vaak bedroevend weinig terug te vinden over wat er precies is getest en hoe. Peter Sterck : “Onze ervaring leert dat tussen 30 en 60 percent van het ontwikkelingsbudget wordt uitgegeven aan testen. Maar op weinige uitzonderingen na, worden daar geen gegevens over bijgehouden. “

De reden is dat het testen al is deze trend aan het keren nog vaak manueel wordt gedaan, met een trial and error-metode. Een module wordt geschreven en dan met de hand uitgeprobeerd. Bedrijven blijken weinig te investeren in testmiddelen. Volgens Performance Software gaat typisch 50 % van de personeelskosten in een toepassings-ontwikkelingsomgeving naar testen, terwijl testmiddelen en -training minder dan 5 % van het investeringsbudget wegkapen.

Ook in informatica-opleidingen wordt testen als het verre neefje behandeld. “Waarschijnlijk gaat niet 1 % van de aandacht naar testen, ” meent Peter Sterck.

In feite beginnen de problemen vaak al bij de konceptie van software-ontwikkeling zelf, waar nog al te dikwijls het zogenaamde watervalmodel wordt gebruikt. Peter Sterck : “Dat werkt als volgt. De toekomstige eindgebruiker maakt zijn wensen kenbaar aan een analist, die daarvan een analysedossier opstelt. Daarin staat wat er ontwikkeld moet worden. Vervolgens wordt dat dossier gekonkretizeerd in een logisch, daarna in een fysisch ontwerp en vervolgens omgezet in programma-onderdelen. Vaak automatisch wordt er dan kode gegenereerd. Uiteindelijk, als de zaak min of meer klaar is, wordt er volop getest. “

“Heel veel aandacht gaat naar pre-produktie en produktietesten. Men kent het parallel draaien, het proefdraaien, de acceptatietest, maar niemand kent de analysetest, en nochtans brengt dat veel meer op. Een fout vinden in de analysefaze is 300 keer goedkoper dan hem vinden in de produktiefaze. Natuurlijk worden verderop in het ontwikkelingsproces óók fouten gemaakt en die haal je er niet uit bij de analyse. Maar er zitten pertinent fouten in de analyse en in 99 % van de gevallen wordt die gemaakt door één persoon, die dat niet voorlegt aan een derde. ” Kortom, fouten worden te laat opgemerkt en gekorrigeerd.

Een ander probleem met het watervalmodel zijn de deadlines, de opleveringstijdstippen. The Standish Group International uit Massachusetts schat in een recent rapport dat slechts 16,2 % van de toepassingsprojekten op tijd, binnen het budget en funktionerend worden afgeleverd. Softwareprojekten vooral als ze omvangrijk zijn, denk aan Windows 95 zijn notoire laatkomers. En hoewel deadlines gewoonlijk iets verschoven kunnen worden, komt er een moment van de waarheid. Peter Sterck : “De latere fazen komen onder druk. Jongens, we moeten opleveren. Test wat sneller, test wat minder… Dat zal wel in orde zijn, want dat hebben we vorige maand nog gedaan. En dat is ontwikkeld door X, die is goed, laat maar zitten. “

“Aan onze prospekten stel ik de vraag : wat is de voorwaarde om een programma in produktie te nemen. In 9 van de 10 gevallen luidt het : de datum. En dan, als tweede faktor, eventueel : de kwaliteit ook nog een beetje. Want als de zaak niet werkt, dan kunnen we niks in produktie zetten. “

V-MODEL.

Nu wil PS-Testware niet gezegd hebben dat er een wondermiddel bestaat tegen de tijdsdruk op software-ontwikkelaars, maar aan de kwaliteit kan heel wat gedaan worden.

Als ontwikkelingsmodel schuiven PS-Testware en geestesverwanten het zogenaamde “V-model” naar voor. Daarin krijgt testen van bij de start van het projekt, in de analysefaze nog, konceptueel een even groot gewicht als het ontwikkelen zelf. Op die manier wordt de kwaliteitszorg in het ontwikkelingsproces ingebouwd.

Vaak is een analyse zeer abstrakt omdat zij de doelstellingen van de opdrachtgever in logische schema’s probeert te vatten. Peter Sterck : “Impliciet gaat er in die faze nog wel aandacht naar wat het programma echt moet zijn, hoe de software zal worden gebruikt. Maar de meeste aandacht gaat in de praktijk naar de vraag : hoe moet die software geschreven zijn ? ” Op dat punt kunnen al belangrijke misverstanden ontstaan.

Peter Sterck : “Een recent voorbeeld. Een Belgische bank bestelde recent een stuk software voor de handel in buitenlandse valuta. De eindgebruiker moest in één dag tijd een aantal kontrakten kunnen inbrengen en die moesten kunnen worden afgesloten aan een bepaalde koers. De software-ontwikkelaar een externe firma ging aan de slag en leverde een produkt dat effektief de mogelijkheid gaf om een koers en verschillende kontrakten in te brengen. Alleen bleek bij de acceptatietest, dat men in het programma éérst de koers en daarna de kontrakten moest ingeven, terwijl het eigenlijk de bedoeling was dat er aan het einde van de dag een afrekening kon worden gemaakt, zodat de trader dan een overzicht had van de kontrakten die hij kon afsluiten als hij een bepaalde koers aanvaardde. “

“Het principe was juist, maar men had niet voldoende duidelijk gemaakt, hoe men dat nu écht zou doen. Het programma moest totaal herschreven worden. “

A-TECHNISCH.

Dergelijke fouten kan u vermijden, aldus Peter Sterck, door tegelijk met het analysedossier een testdossier op te stellen met daarin een antwoord op de vraag : hoe valideer ik de software die ik in de analyse beschreven heb ? In zo’n testdossier komt niets technisch te staan. Of het programma onder Windows zal draaien in een client/server-omgeving of op een terminal gekoppeld aan een mainframe, is irrelevant voor de evaluatie. Het testdossier beschrijft gewoon wat het programma moet doen.

Peter Sterck : “Konkrete dingen als : ik vul gegeven A en gegeven B in op het scherm en dan zie ik op hetzelfde scherm de berekening van A maal B. Als wij dan op basis van de analyse in de ontwerpfaze een datamodel gaan maken, waarin bijvoorbeeld de grootte van de velden voor gegevens A en B wordt bepaald, dan kunnen we ook ons testdossier verder gaan detailleren en onze testen konkretizeren. Enzoverder, tot we aan de ene kant uitvoerbare programma’s hebben, en aan de andere kant uitvoerbare testen. “

Het testdossier blijft daarbij a-technisch. Een veel voorkomend probleem bij het ontwerp van programma’s die hun gegevens halen uit relationele databases, is bijvoorbeeld dat de relatie tussen de gegevens in de database kan worden verbroken. De tabel met de bestellingen in de database is bijvoorbeeld ontkoppeld geraakt van de tabel met de produktidentifikaties. Het resultaat is meestal dat er op het scherm foute gegevens verschijnen. Peter Sterck : “Ontwikkelaars zullen u dan zeggen dat de fout is, dat de relatie weg is en dat u daardoor niet aan de juiste gegevens geraakt. Wel, bij het testen moet u dat kunnen omdraaien. U moet stellen : de fout is eigenlijk dat u die gegevens niet bekomt. “

Een interessante observatie van PS-Testware is ook dat er veel tijd gaat naar het uitvoeren van testen, maar weinig naar vragen als : welke testen doe ik en moet ik déze testen wel doen ? En, bewijzen deze testen inderdaad wat ik wens te bewijzen ? Peter Sterck : “Als ik mijn prospekten vraag hoeveel percent van de totale testtijd zij aan het uitdenken van hun testen spenderen, dan is dat nooit meer dan 10 percent op het geheel. De reden ligt voor de hand : zelfs die korte reflektie is dikwijls al zo overweldigend dat zij zo snel mogelijk met het testen willen beginnen. “

Want testen is een langdurig en dom werk, maar bovendien (paradoksaal genoeg) ook zeer moeilijk. Volgens de ervaring van PS-Testware in de Benelux wordt, bij manueel testen van toepassingen, elke belangrijke funktionaliteit tussen 4 en 20 keer getest. Peter Sterck : “Een Belgisch financieel netwerk heeft een pakket in oplevering, dat nu 10 maanden in test is. Op dit ogenblik gaat het om run 80, dat wil zeggen dat de software 79 keren voor verbetering en aanvulling terug naar ontwikkeling is gestuurd. En het is nog niet gedaan. “

Manueel hertesten betekent : elke keer van nul af aan herbeginnen. Vandaar het “domme” karakter van het werk. Het moeilijke eraan is dat die herhaling telkens met een uitzonderlijke (zeg maar, oosterse) discipline moet worden uitgevoerd.

De business case om automatische testsoftware in te voeren, is dan ook overweldigend. De belangrijkste argumenten zijn :

– Het evidente : een test die automatisch kan worden uitgevoerd kan worden herhaald. Dit is zeer belangrijk omdat, zoals elke ontwikkelaar weet, de hele testprocedure in feite van nul moet worden hernomen na de korrektie van een fout. In de manuele praktijk gebeurt dit uiteraard niet. Opdrachtgevers zijn geneigd de testtijd als een percentage van de ontwikkelingstijd te zien en niet als een veelvoud daarvan. “Een manweek voor een korrektie laten volgen door twee manmaanden voor hertesten. Niemand accepteert dat, ” stelt Peter Sterck. Maar als testen automatisch kunnen worden herhaald zonder menselijke tussenkomst wordt dat wel mogelijk.

Zeer evident wordt de nood aan snel, automatisch testen bij de toepassing van de zogenaamde Rapid Application Development (RAD)-techniek. Daarbij bouw je, in nauwe samenwerking met de gebruiker, snel een toepassing in blokken funkties gewoonlijk die je dan telkens afwerkt en oplevert. De toepassing is daardoor al operationeel, terwijl ze in feite nog in opbouw is. Terwijl de programmeur telkens een blok afwerkt, moet de tester telkens de hele toepassing opnieuw onder handen nemen. “Bij RAD moèt je automatisch testen, je hebt gewoon geen andere keuze, ” betoogt Peter Sterck, die in RAD-gebruikers (waaronder enkele kleine Belgische banken, het SD Sociaal Sekretariaat en Walsh International) dankbare afnemers vindt.

– Tweede sterk punt van automatisch testen : efficiënte foutverhelping. Het probleem met bugs is dat ze meestal slechts opduiken bij een ingewikkelde samenloop van omstandigheden. Wie een fout rapporteert, moet kunnen beschrijven hoe hij ze heeft veroorzaakt. Maar hoe deed u dat ook alweer ? Testprogramma’s houden die kronologie van interakties bij en laten zo toe de fout te reproduceren. Met een pakket als SQA TeamTest kan u ook simulaties uitvoeren.

SLECHTS HALFAUTOMATISCH.

Nu moet u niet denken dat zulk testen echt automatisch verloopt. Een testprocedure zal nooit automatisch kunnen worden ontworpen. U zal minstens zelf altijd (1) de omgeving moeten definiëren van waaruit wordt gewerkt (database, gegevens, toepassing), (2) moeten vastleggen welke akties worden uitgevoerd, en (3) wat het resultaat daarvan moet zijn. Geen enkele computer kan bijvoorbeeld weten tenzij u het hem zegt dat de schermen van een bepaalde firma een blauwe achtergrond horen te hebben, omdat blauw de bedrijfskleur is.

Een andere beperking is, dat testen nooit 100 % herbruikbaar zijn. Als u uw software heeft veranderd, is het mogelijk dat u ook uw test zal moeten aanpassen. Heeft u uw software geheel herschreven (dat is een eufemisme voor een nieuw programma maken), dan zal u ook de konkrete tests moeten herschrijven.

Voorspellen hoeveel automatisch testen u zal opbrengen, is moeilijk omdat het zo afhankelijk is van de omstandigheden. Performance Software meent dat een besparing van 20 percent op testuitgaven mogelijk moet zijn of zo’n 10 percent op de totale kost van een systeem over zijn levenscyclus. Dat zijn voorzichtige schattingen. Kliënten van SQA Inc. geven in testimonials hebt u hem ? tijds- en kostenbesparingen op van vele tientallen percenten tegenover manueel testen. In de praktijk ligt de keuze allicht eenvoudiger : zonder testsoftware komt u er gewoon niet langer.

BRUNO LEIJNSE

HET V-MODEL Testen als integraal onderdeel van het softwareproduktieproces.

PETER STERCK (PS-TESTWARE) Een foutenrapport bij elke oplevering.