Informatiesystemen steeds worden complexer en bedrijfs-kritischer worden. Testen van systemen groeit steeds meer uit tot een integraal onderdeel van software-ontwikkeling: "Een hele leuke bezigheid die zeer veel creativiteit vraagt." Testen is wel moeilijker dan het bouwen zelf, zo is de ervaring.
Als analisten en programmeurs geen fouten zouden maken en er voldoende preventieve maatregelen genomen werden, zou testen eigenlijk niet nodig zijn. Er wordt al zoveel gedaan om de kwaliteit van het software-ontwikkelproces te verhogen. Waarom is er dan toch zo’n sterk groeiende belangstelling voor testen? "Mensen maken nu eenmaal fouten", zegt Martin Pol van IP/Software Control Testen. "Preventie alleen is onvoldoende. De informatiesystemen zijn nu veel complexer, waardoor het moeilijker is geworden alles te controleren. Geautomatiseerde systemen breiden zich in onze maatschappij sterk uit, en hun correct functioneren wordt steeds belangrijker. Onze industrie heeft het geluk gehad dat het tot nu toe redelijk gegaan is, maar bedrijven en instellingen die eenmaal een ramp hebben meegemaakt, zijn zich er heel goed van bewust geworden dat testen geen overbodige luxe is."
Pol is in Nederland een van de grote gangmakers op het gebied van het testen van informatiesystemen. Afgelopen december organiseerde hij met veel succes het EuroSTAR ’96 congres in Amsterdam, met ruim vijfhonderd deelnemers van wie zo’n tweehonderd uit Nederland. Wat is hem tijdens het congres speciaal opgevallen? "Vooral de enorme belangstelling voor de problematiek van het jaar 2000", zegt Pol. "Al vijftien jaar geleden is dit ter sprake gebracht. Je zou denken dat het nu geen probleem meer zou moeten zijn, maar het tegendeel is waar. We hebben er een hele dag conferentie aan gewijd plus een tutorial van een dag." Daarnaast viel Pol de grote belangstelling op voor de voor managers georganiseerde middag, die vooral gericht was op de bewustwording van het testen.
Pol kwam ongeveer vijftien jaar geleden bij de belastingdienst met het thema testen in aanraking. Men stond daar toen voor de opgave alle systemen te herontwerpen vanwege de grote reorganisatie van de dienst; naast de ontwikkeling is ook het testen daarvan in de plannen meegenomen. Pol: "Naast het ontwikkelingsproces, moet je ook het testproces optimaliseren. Honderd procent testen is onmogelijk. Je moet je dus afvragen hoe je het zo optimaal mogelijk kunt doen."
Optimaal en gestructureerd
Behalve optimaal, moet testen ook gestructureerd plaatsvinden. Dat houdt in dat testen een geïntegreerd bestanddeel is van een projectplan. Pol heeft bij IP samen met een team de op vier pijlers stoelende Tmap methode ontwikkeld (beschreven in twee boeken): Fasering (wanneer doe je wat, en welke voorzieningen zijn daarvoor nodig), Technieken (welke middelen en gereedschap worden daarbij gebruikt), Infrastructuur (welke technische en organisatorische infrastructuur is nodig) en Organisatie (het toewijzen van taken en verantwoordelijkheden).
"Gestructureerd testen houdt een planmatige aanpak in", zegt Pol, "waarbij je van tevoren nadenkt over hoe je wil gaan toetsen en testen. Dat moet een weloverwogen, goed geïntegreerd onderdeel van het algemene projectplan zijn. In het verleden was testen vaak een verborgen onderdeel van het werk, waar de opdrachtgever nauwelijks mee in aanraking kwam. Bij gestructureerd testen moet de opdrachtgever zich niet alleen expliciet bezig houden met het ontwikkelingsplan, maar ook met het testplan. Er moet een goede balans tussen de vier pijlers gevonden worden. In andere, rijpere industrieën is zoiets overigens al lang gebruikelijk."
Hoe staat het in andere landen met het testen van informatiesystemen? "Vooral Engeland loopt voorop", meent Pol. "Nederlanders moeten het testen in de praktijk leren; wij geven veel cursussen in bedrijven. Testopleidingen moeten in Nederland hun plaats nog verdienen in de reguliere opleidingsprogramma’s. In de Verenigde Staten is het testen bij sommige grote bedrijven goed geregeld, elders werkt men zeer pragmatisch. Over Duitsland is weinig bekend: systeemontwikkeling vindt vaak plaats in softwarehuizen, op basis van turnkey. In België is veel belangstelling – ik ben bezig met het oprichten van een Nederlands/Belgisch genootschap voor gestructureerd testen. Verder geldt dat hoe zuidelijker je in Europa komt, hoe minder ontgonnen het gebied is."
Kwart totale kosten
Testen kan wel een kwart van de totale ontwikkelingskosten uitmaken. Om een en ander te optimaliseren, moeten tal van beslissingen worden genomen, over zaken als voortgangscontrole, ontwikkelen en beheer van testware, beheer van de testresultaten, configuratiemanagement, change management, dekkingsanalyse (welke stukken programmatuur behoeven meer testen dan andere), risico-analyse, enzovoorts.
Behalve over structureren, moet ook nagedacht worden over het automatiseren van testen. Over de daartoe beschikbare gereedschappen is een speciaal ButlerBloor rapport verschenen (zie kader).
Hans Buwalda van CMG Finance is de geestelijke vader van de CMG:CAST, een nieuwe, praktische methode voor het geautomatiseerd uitvoeren van testen. Op de vraag waarom in zijn ervaring de belangstelling voor testen zo sterk is toegenomen, antwoordt hij: "Systemen worden steeds complexer, en hun eventuele falen heeft steeds verstrekkender gevolgen. Vandaar dat men een grotere zekerheid eist. De grotere complexiteit is merendeels een gevolg van de nieuwe technologieën zoals client/server, object oriëntatie en, nu snel opkomend, intranet. De grotere gebruikersvriendelijkheid daarvan schept veel meer mogelijkheden voor de ontwerper, dus ook meer dat fout kan gaan. Een modern object-georiënteerd dialoogvenster voor een eindgebruikertoepassing bezit tegenwoordig al snel tweeduizend eigenschappen, zoals plaats, afmeting, kleur, te ondernemen acties, onderliggende database-acties, enzovoort. Die kunnen onmogelijk allemaal getest worden. Uitbreiding van het aantal databases, vooral de gedistribueerde, versterkt deze situatie nog meer.
Extra dimensie
"Er komen meer schakels in het proces", vervolgt Hans Buwalda, "en meer interfaces, en er wordt meer in real-time gewerkt. Allemaal extra dimensies die de complexiteit verhogen en dus het aandachtsgebied voor testen vergroten. Waar de mainframe-omgeving met batchverwerking grotendeels bediend wordt door specialisten, verschuift die taak bij client/server steeds meer richting eindgebruikers. Speciaal in de bankwereld geldt dat je centraal erg goed moet testen voordat je de systemen in de vele bijkantoren gaat installeren. In de financiële wereld zijn geautomatiseerde systemen een essentieel onderdeel van de primaire bedrijfsprocessen, en is de kwaliteit van deze systemen dus van cruciaal belang."
Hoe wordt de theorie in de praktijk gebracht? Gebruikt men inderdaad het V-model, dat stappen in de ontwikkelcyclus van software rangschikt in de vorm van een V, waarbij de ontwikkelingsfasen links staan en de daarmee overeenkomende testen rechts? "De praktijk is weerbarstig", zegt Buwalda. "Testen is moeilijk, zelfs nog een graadje moeilijker dan ontwikkelen, en dat geldt voor zowel het analyseren van de te testen materie als voor het ontwerpen en het uitvoeren van de tests. Naast analyseren en ontwerpen moet je heel concreet bepalen hoe je de materie wilt testen. Je kunt daarbij per definitie geen aspecten in het midden laten, wat je bij een analyse of ontwerp soms wel doet. En wil je het testen geheel of gedeeltelijk automatiseren, wat vooral belangrijk is voor het onderhoud later, dan zul je het testgereedschap tijdig moeten ontwikkelen."
Honderd mensjaar
Op het EuroSTAR congres waren nogal wat leveranciers van CAST-gereedschap (Computer Aided Software Testing) aanwezig. Hoe belangrijk is gereedschap voor testen? "In veel gevallen erg belangrijk", meent Buwalda. "Neem bijvoorbeeld het jaar 2000 probleem. Om daar goed op voorbereid te zijn moet alle bedrijfskritische programmatuur getest worden, inclusief de programmatuur die niet door een impactanalyse als jaar 2000 gevoelig is aangewezen. In een middelgroot rekencentrum worden typisch rond de twintigduizend programma’s gebruikt. Stel dat je gemiddeld een dag aan het onderzoeken, aanpassen en testen van elk programma besteedt, dan kost dat honderd mensjaar!".
"Vandaar dat het goed automatiseren van testen zo belangrijk is. Daarvoor moet je vooraf maatregelen nemen, want de testmiddelen en -systemen moeten ook ontwikkeld worden. Nu speelt het jaar 2000 probleem, maar dat is nog slechts een voorproefje van wat ons straks te wachten staat met de invoering van de euro, als elk programma gedurende een bepaalde periode zelfs twee soorten munteenheid moet kunnen verwerken. Wil je dat goed kunnen testen, dan zul je nu maatregelen moeten treffen. Bij zuiver handmatig testen zijn tweehonderd testgevallen al veel. Met automatisch testen vinden wij, gebruikmakend van onze methode, twintigduizend testgevallen heel normaal."
Statisch broncode langslopen
Wat voor soort gereedschappen zijn er, en welk gebied beslaan ze? Buwalda: "Er is een breed scala leveranciers. De keuze moet afgestemd worden op de specifieke eisen van ieder project. Er zijn gereedschappen die programma’s controleren: statisch de broninstructies langslopen of dynamisch de werking controleren aan de hand van testgevallen. In een zogenaamd bug-tracking systeem worden de testresultaten bijgehouden, waarbij de afwijkingen worden geclassificeerd als problemen die moeten worden opgelost, de echte bugs, en de problemen die daarvan het gevolg zijn. Met zo’n systeem worden in een log-file ook de veranderingen en oplossingen bijgehouden. Ander gereedschap beoordeelt de dekkingsgraad van het testen: zijn er gedeelten van de software die niet getest zijn, en zo ja: waarom niet; zijn er gedeelten die extra aandacht vragen? Enzovoorts."
Als je een fout in het begintraject kunt vermijden, is het corrigeren vele malen goedkoper dan wanneer je pas aan het eind van de ontwikkeling die fout ontdekt. Hoe past preventie in het nieuwe testproces? "Uitstekend", zegt Buwalda, "je wordt bij onze methode al bij de analysefase gedwongen na te denken over de manier van testen. Dit levert een soort extra controle, die preventief werkt. Inspecties aan het eind van elke fase moeten daarom niet alleen het ontwikkelwerk beoordelen, maar ook het testwerk. Overigens zijn fouten nooit helemaal te vermijden. Je moet tijdens de ontwikkeling in goed overleg met de opdrachtgever een afweging maken tussen de kwaliteitseisen en de testkosten en -tijd, en proberen daartussen een optimale balans te vinden."
Verkeerde weg?
Tom DeMarco brak op het congres een lans voor ‘langzaam’ ontwikkelen. Door eerst gedurende een relatief lange tijd met een kleine groep mensen na te denken over de opzet en het ontwerp van software en dan pas te gaan coderen, zou je veel efficiënter en effectiever kunnen ontwikkelen. Toch werken veel bedrijven met RAD-technieken (Rapid Application Development). Zijn die op de verkeerde weg?
"Dat is moeilijk te zeggen", vindt Buwalda. "RAD-technieken worden vaak mede gebruikt om de kwaliteit van het ontwerp te verbeteren. Ik geloof dat DeMarco in principe gelijk heeft, maar het vereist moed en vooral visie om een dergelijke strategie te volgen. Heel belangrijk bij de ontwikkeling van nieuwe software is immers de time-to-market. Overal waar concurrentie is, moeten dingen snel van de grond komen voordat een concurrent marktaandeel afsnoept. Maar ik ben ervan overtuigd dat een goed ontworpen systeem juist in een dergelijk spanningsveld een belangrijke voorsprong kan betekenen."
"Een ander interessant spanningsveld is de belangstelling van de opdrachtgever voor het nieuw te bouwen systeem, vooral in een vroeg stadium van een project. Die is vaak zeer bepalend voor de kwaliteit en adequaatheid van een ontwerp, en dat geldt dan ook voor het testen. En vergeet niet dat naast al ons functioneel en technisch testen ook aandacht moet worden geschonken aan de bruikbaarheid van het systeem voor eindgebruikers. Die moeten niet worden opgezadeld met een onbruikbaar systeem, ook al is dat van nog zo’n goede technische en functionele kwaliteit"
Testzaal met spiegels
Hoe test je de bruikbaarheid van een systeem? "Dat is een nogal moeizaam proces", meent Pieter Lankhorst van IBM, "zoals veel dingen die met mensen te maken hebben, onder andere omdat de criteria moeilijk te bepalen zijn. Het is vaak eenvoudiger om enkele alternatieven door representatieve gebruikers te laten vergelijken en te vragen waar hun voorkeur naar uitgaat. Tot voor kort was het nauwelijks mogelijk om de bruikbaarheid van een produkt op zichzelf te meten. Maar sinds enkele jaren hebben we nu de SUMI-vragenlijst, waarmee zelfs heel verschillende produkten met elkaar kunnen worden vergeleken."
Lankhorst vertelt dat SUMI (Software Usability Metrics Inventory) rond 1992 door de Ierse University of Cork is ontwikkeld in het kader van een Esprit-programma. Het is een lijst met vijftig zorgvuldig gestelde generieke vragen over de bruikbaarheid van een produkt, waarop proefpersonen kunnen antwoorden met ‘mee eens’, ‘weet ik niet’, of ‘niet mee eens’. De algemene vragen hebben betrekking op de efficiëntie van het produkt, de emotionele binding met het produkt, de mate waarin het produkt de gebruiker op weg helpt, het gevoel het produkt de baas te zijn, en de leerbaarheid van zijn gebruik. De scores voor deze vijf basisaspecten worden ten slotte gewogen in een algemeen percentage, dat vergelijkbaar is tussen produkten. Een score tussen vijftig en zestig punten betekent per definitie dat de bruikbaarheid hoger is dan gemiddeld.
Lankhorst leidt de IBM User Interface Design Group in Uithoorn. Hij beschikt daar over een testzaal met halfdoorlatende spiegels waarachter testers het verloop kunnen volgen en op video opnemen. Een dergelijke faciliteit, die tegenwoordig vrijwel onmisbaar is voor het testen van bruikbaarheid, vindt men ook veel bij banken. De techniek hiervoor is in de jaren zeventig ontwikkeld in de VS.
Lankhorst: "Het is vaak opmerkelijk op welke dingen je stuit. Uit overlevering ken ik het verhaal van de floppy diskette uit de oertijd van de PC, waarbij de instructie luidde dat je de diskette uit het envelopje moest halen voordat je het in de machine stopte. Toevallig lag er een keer een floppy zonder envelopje, en de gebruiker probeerde toen het zwarte, plastic omhulsel met een schaar open te maken… Dat soort dingen kun je niet verzinnen, dat moet blijken."
Beginnen met de motor
Lankhorsts achtergrond is in industriële vormgeving (TH Delft), en hij heeft een uitgesproken mening over de computerwereld in het algemeen: "Analisten en programmeurs zijn vaak erg knap in het vinden van de beste gebruikers-interface. Voor hen bestaan vaak geen alternatieve mogelijkheden, zoals elders in de bedrijfswereld. Ik vergelijk software-ontwikkeling met die van een auto voor de Tweede Wereldoorlog: men begon met de motor, en daarom heen werd een carrosserie ontworpen en ten slotte het interieur. Men werkte van binnen naar buiten. Om een goede bruikbaarheid, een goede usability te krijgen, moet je het precies andersom doen: van buiten naar binnen werken. Beginnen met de analyse van taken van eindgebruikers, vervolgens alternatieven bedenken voor hoe die het beste uitgevoerd kunnen worden, en dan die alternatieven proefondervindelijk vergelijken. Participatie in het begin van een project levert oneindig veel meer op dan testen aan het einde."
Lankhorst toont zijn testzaal, waar een proefpersoon bezig is met het uitvoeren van een opdracht voor het project Veenendaal, een elektronische marktplaats voor gemeente en bedrijven. Dit project wordt gerealiseerd door IBM, ABN Amro en Casema/NKM, om nieuwe vormen van elektronische dienstverlening via het kabelnet te onderzoeken. "Bij deze proef werken wij met proefpersonen die nog nooit eerder met een computer gewerkt hebben. Het is heel belangrijk om echt representatieve gebruikers als proefpersoon te hebben."
Op zoek naar nieuwe problemen
Is dit testen niet kostbaar? "Helaas wel.", zegt Lankhorst. "Voor een project met tien tot vijftien proefpersonen praat je al gauw over enkele tienduizenden guldens, dus dat doe je alleen als de bruikbaarheid later voorop moet staan. Tegenover de kosten van testen staan natuurlijk altijd de kosten voor het oplossen van problemen die je niet hebt gevonden vanwege niet-testen. Er is ook een afweging met training en ondersteuning: als er maar een handjevol gebruikers is, kun je die beter een goede training geven dan de bruikbaarheid opvoeren. Omgekeerd, als je veel gebruikers hebt die je niet kunt trainen, moet je goed testen en ontwerpen."
"De huidige trend is: aandacht voor de bruikbaarheid in een vroeger stadium van een project. In steeds meer gevallen doen we eerst een relatief goedkope taakanalyse en bekijken we alleen de gebruikers-interface op basis van onze ervaring, zonder uitvoerig te testen. In andere gevallen proberen we een soort huisstijl voor beeldschermen te ontwikkelen uit de veelheid van grafische mogelijkheden. Dat schept een gevoel van herkenning bij het zien van een nieuw programma, wat zijn bruikbaarheid verhoogt. Het werk aan bruikbaarheid moet passen bij de latere behoefte."
Van een nogal duf onderdeel aan het einde van het traject van software-ontwikkeling, ontwikkelt testen zich tot een integraal onderdeel daarvan. Voor een werkzaamheid die vooral door beginners werd uitgevoerd, worden nu steeds hoger gekwalificeerde informatici ingezet. In de woorden van CMG’s Hans Buwalda: "Testen is een hele leuke bezigheid die zeer veel creativiteit vraagt." Testen heeft niet langer de doelstelling om alleen zoveel mogelijk fouten te ontdekken. Het nieuwe testen wil het kwalitatief gewenste resultaat op een optimale manier realiseren.
Hein van Steenis, free-lance medewerker Computable.
Cast Tools: An Evaluation and Comparison
In een in 1995 verschenen rapport van ButlerBloor onder bovenstaande naam wordt een twintigtal testgereedschappen onder de loep genomen. Aan de hand van dit rapport kunnen organisaties het voor hen meest geschikte gereedschap uitzoeken.
De markt voor deze gereedschappen is sterk gefragmenteerd, blijkt uit het rapport. Het zijn veelal kleine bedrijven die zich op specifieke aspecten of gebieden richten. Het rapport beschrijft hun produkten en de mogelijkheden daarvan in detail.
In een apart hoofdstuk worden diverse aspecten rond het gebruik van het gereedschap besproken: het doel van testen, de afwegingen en de organisatie die nodig is om het gestructureerd toetsen en testen zo optimaal mogelijk te realiseren.
