We worden steeds vaker geconfronteerd met fouten in software. Sommige zijn onschuldig, zoals die in Windows. Andere leggen het telefoonverkeer plat of doen een Ariane neerstorten. En straks komt het jaar 2000… Er wordt te weinig getest en zeker niet optimaal, zegt de Noorse test-consultant Hans Schaefer in een interview.
Testen van software vindt altijd achteraf plaats, als de softwarefouten al door programmeurs gemaakt zijn. Bovendien bevindt het testen zich in de afsluitfase van een project dat meestal achterloopt op het schema, zodat er onder zware tijdsdruk getest moet worden. Fouten kosten dan een hoop tijd, geld en ergernis. Stellen dat fouten voorkomen altijd beter is, lijkt een open deur. Maar waarom wordt daaraan niet meer aandacht besteed?
We spraken hierover met de Noorse test-consultant Hans Schaefer, gespecialiseerd in software-kwaliteit en testen.
"Ik vind uiteraard ook dat fouten zoveel mogelijk voorkomen moeten worden, maar fouten zijn nooit helemaal te vermijden. Het testen blijft dus. Ik heb erg veel aan voorlichting gedaan op de universiteiten in Noorwegen. De houding van de meeste hoogleraren is dat als je ontwerp maar goed is, testen overbodig is. Testers zijn natuurlijk ook voor een goed ontwerp, maar vinden dat je bij het analyseren of ontwerpen er ook over moet nadenken hoe je de implementatie later wilt testen. Op die manier ontwikkel je het ontwerp en de testcases tegelijkertijd. Daardoor word je je meteen ook beter bewust van wat er mogelijk fout kan gaan. Helaas gebeurt dit simultaan ontwikkelen nog veel te weinig."
Schaefer legt uit hoe hij in het testen verzeild raakte. "Ik werkte in een slecht gemanaged ontwikkelproject van een Noors researchcentrum. Op een zeker ogenblik liepen de zaken, zoals wel vaker, echt in het honderd. Ik werd aangesteld om te onderzoeken hoe dat was gekomen en heb daarover nogal wat presentaties gegeven. Bij gebrek aan beter raakte ik steeds bekender en werd mijn hulp steeds vaker ingeroepen. Op een goed ogenblik word je dé expert." Schaefer is nu consultant en draait af en toe mee in projecten.
Onlangs was hij in Nederland om onder meer te praten over de CMG-methode voor het ontwikkelen en automatiseren van tests met behulp van actiewoorden (zie Computable, 23 en 30 juli 1997).
Meer of minder fouten?
Ondanks alle goedbedoelde pogingen gaat de kwaliteit van software er niet op vooruit, zo luidt de mening van softwareconsultant Les Hatton (Computable, 5 september 1997). Nu worden de systemen steeds complexer en dringen computers verder door in onze maatschappij, zodat fouten grotere consequenties hebben en meer en meer zichtbaar worden.
Schaefer: "De kwaliteit van software, gemeten in het aantal fouten per duizend regels code, wordt steeds beter. Helaas is de groei van de complexiteit en de grootte van systemen veel sneller dan de afname van het aantal fouten per duizend regels code. Hierdoor groeit het aantal fouten in ‘een systeem’ onvermijdelijk. Zelfs de beste bedrijven zien geen kans om zich aan dit fenomeen te onttrekken."
Het probleem is volgens Schaefer niet alleen te wijten aan gedistribueerd en gelijktijdig computergebruik, zoals wel wordt gesteld. Veel problemen ontstaan doordat processen steeds verder geautomatiseerd worden. Als de output van het ene programma direct in een volgend programma wordt ingevoerd, en dit proces wordt een aantal keren herhaald, dan kan een kleine fout in het eerste programma grote en onvermoede gevolgen in de volgende programma’s hebben. Een factuur waarop geen of een onjuist jaartal voorkomt, kan in de erop volgende programma’s de meest wilde fouten veroorzaken. Komen er in de tussentijd nog mensen aan te pas, dan wordt zoiets meestal wel ontdekt en gecorrigeerd. Maar hoe meer een proces is geautomatiseerd, des te groter is de kans op fouten, vooral als er lange tijd zit tussen de bewerkingsstappen.
2000
Het ‘jaar 2000’-probleem is inmiddels een onderwerp dat uitgebreid in de media aan de orde is geweest. Het klinkt nu bizar dat programmeurs destijds vanwege twee extra datumplaatsen in een record die miljarden verslindende ellende over ons heen hebben gebracht. ING Barings voorspelt dat eenvijfde van alle Nederlandse bedrijven twee maanden plat zal liggen vanaf 1 januari 2000. Een eenvoudige rekensom leert dat als een computercentrum 30.000 programma’s heeft die per programma één dag testen vergen, je 150 manjaar kwijt bent. Die tijd en al dat geld had toch veel beter aan vernieuwingen besteed kunnen worden dan aan het repareren van oude fouten?
Schaefer: "Natuurlijk, maar hoe belangrijk dat ook moge zijn, ik vind het een weinig opwindend probleem. Vanuit het oogpunt van testen is de oplossing voor Y2K alleen een kwestie van regressie-testen. Je test de software voor en na bepaalde datums, niet alleen 1 januari 2000; je vindt fouten en lost die op. Het probleem is echter dat vrijwel niemand de juiste testcases heeft ontwikkeld en dat nu iedereen dit manco als een razende aan het herstellen is. Als ze die testcases wel zouden hebben gehad, was er nu geen vuiltje aan de lucht."
Hij legt uit dat het ‘jaar 2000’-probleem maar een klein onderdeel is van ‘business cycle’-testen. Tussen de stappen van een proces kan een lange tijd liggen, waarin veel kan veranderen. Daarom moet de gehele cyclus getest worden. Stel bijvoorbeeld dat een factuur na twee maanden nog niet betaald is, dan moet er een herinnering gestuurd worden en eventueel later nog een tweede. De afwikkeling van de factuur kan een jaar in beslag nemen, terwijl de geadresseerde inmiddels verhuisd kan zijn of overleden; werkt het systeem dan nog of raakt het op tilt?
Hoeveel Y2K-fouten worden er nu werkelijk gevonden? Is het allemaal hype of is het een werkelijk probleem?
Schaefer: "Nee, het is wel degelijk een groot probleem, maar ik kan er geen goede cijfers over geven. Dit is ook erg afhankelijk van de wijze waarop men het probleem aanpakt. Er zijn bedrijven die oudere en dus verdachte toepassingen opnieuw ontworpen en ontwikkeld hebben. Daarin zitten veel minder Y2K-problemen dan wanneer men begint met het testen van de ongewijzigde toepassingen. Het is bovendien onmogelijk om alle fouten in alle programma’s te vinden, je kunt hooguit de belangrijkste fouten vinden, als je het testen tenminste op een slimme manier aanpakt." Hij noemt Microsoft als voorbeeld van een bedrijf dat uitstekend test en ondanks alle resterende fouten het toch goed doet in de markt. De meeste bedrijven testen echter onvoldoende of pakken het testen verkeerd aan.
Aanpak
Hoe kunnen bedrijven of instellingen het testen beter aanpakken?
Schaefer: "Als eerste zullen ze een overzicht moeten maken van alle computers en software die gebruikt wordt. Een vriend van me vertelde dat bij een verhuizing duidelijk werd dat een computer in zijn kantoor een database-server bleek te zijn, die al jaren in het netwerk stond en veel gebruikt werd. De verantwoordelijke persoon was al lang geleden vertrokken en niemand wist dat het ding bestond, laat staan dat iemand zich ervoor verantwoordelijk voelde. Fijn dat hij zo betrouwbaar werkte, maar hij kan wel een haard van problemen vormen." Zo staan er in genetwerkte omgevingen vaak nogal wat onbeheerde computers.
"De tweede stap is om alle systemen en programma’s te categoriseren. Ik werk meestal met vier categorieën. In de eerste categorie vallen de programma’s die van grote invloed zijn op de maatschappij, die in een nutsbedrijf bijvoorbeeld de stroomvoorziening kunnen uitschakelen. In de tweede categorie vinden we de systemen en programma’s die kritisch zijn voor het voortbestaan van het bedrijf, bijvoorbeeld die voor het factureren. In de derde categorie vallen de systemen ten behoeve van klanten, medewerkers en toeleveranciers. De vierde categorie, tenslotte, omvat alle andere systemen. De eerste twee categorieën moeten goed getest zijn, punt uit. In de derde categorie kun je volstaan met een vorm van menselijke backup voor het geval dat er problemen ontstaan. Men tracht deze oplossing ook te gebruiken voor problemen in de eerste twee categorieën omdat er anders te veel te testen valt en er te weinig mensen beschikbaar zijn, maar dat is natuurlijk niet juist", aldus Schaefer.
Gereedschappen
Er zijn nogal wat gereedschappen op de markt. Kunnen die het testen vergemakkelijken?
Schaefer: "In principe wel, als je maar weet hoe je ze moet programmeren en als je goed voorbereid bent. De gereedschappen worden vrijwel steeds gedemonstreerd door iemand die lui achterover zit, waarbij de testcases snel achter elkaar over het scherm vliegen. Maar dan moet je wel eerst al die testcases van tevoren gemaakt hebben, dat vertellen ze er niet bij!"
Alle gereedschappen werken door een vergelijkingstest met de testcases: ze bekijken of het systeem op de ene datum net zoals op een andere datum werkt. Hierbij wordt niet alleen voor en na 1 januari 2000 getest, maar ook op andere datums, zoals 09/09/1999, die aanleiding tot problemen zouden kunnen geven.
Schaefer vervolgt: "De testgereedschappen zijn redelijk goed, maar dat betekent niet dat ze alle fouten zullen vinden. De gereedschappen bieden alleen een mechanisme voor de vergelijking; fouten worden alleen gevonden als de juiste testcases worden gebruikt. Dat kan heel gecompliceerd liggen ten gevolge van vreemde combinaties in de invoergegevens, vooral als de cyclus van een transactie in het bedrijf zich over lange tijd uitstrekt. Belangrijk is dus om de testcases tegelijk met het systeem te ontwikkelen volgens het V-diagram (zie Computable, 7 februari 1997)."
Aandeel van het testen
Is er iets te zeggen over de verhouding tussen de inspanningen voor het testen en die voor het ontwikkelen?
Schaefer: "Dat hangt vooral af van de risico’s die verbonden zijn met fouten. Voor een toepassing die alleen intern gebruikt wordt, is een testaandeel van 10 procent waarschijnlijk meer dan genoeg. Bij banken en verzekeringsinstellingen moet je toch wel aan meer dan 30 procent denken. Microsoft werkt in sommige projecten met het buddy-systeem, waarbij iemand over de schouders van de programmeur meekijkt – dan kom je dus al over de 50 procent! Voor het besturingssysteem van een raket kan wel 80 procent van de inspanningen uit testen bestaan. Het percentage dat aan het testen wordt besteedt hangt dus af van de inschatting van de risico’s." Een goede inschatting vormt een probleem voor het management.
Leren van fouten
Het blijft moeilijk om de kwaliteit van software tijdens de ontwikkeling te bewaken. Helpt ISO-9000 hierbij, of moet men het meer zoeken in de richting van de methodieken van W. Humphrey? Schaefer: "ISO-9000 betekent vooral dat je het ontwikkelproces gedocumenteerd hebt, niet dat het ook correct werkt. Er staat wel iets in over leren en optimaliseren, maar ISO heeft voor testen nauwelijks betekenis. Het Capability Maturity Model (CMM) van Humphrey werkt in dit opzicht veel beter, omdat dit niveaus van rijpheid van de organisatie aangeeft. Ik zie nog meer in het Personal Software Process (Computable, 10 oktober 1997), een vorm van het CMM dat gericht is op persoonlijk leren. Ik ben betrokken bij een project waarbij het zelfs gebruikt wordt voor een groep van vijftien programmeurs."
Schaefer verklaart dat het belangrijkste is, dat je leert van je fouten. In de meeste organisaties wordt er wel op fouten getest, maar onvoldoende nagedacht over hoe men zulke fouten in de toekomst kan vermijden. "Het initiatief hiervoor moet vanuit de top komen. Testen en discussies over fouten worden in het algemeen als weinig opwindend, zo niet als vervelend beschouwd. De top moet het belang hiervan onderstrepen. In een van de bedrijven waar ik werk, wordt maandelijks een bijeenkomst gehouden om te bespreken wat voor fouten er gevonden zijn en hoe die voorkomen zouden kunnen worden. Dat maakt mensen bewust en daar leren ze van. Maar in de meeste projecten worden fouten gecorrigeerd en praat men er verder niet over." Schaefer pleit er ook voor om het project én het budget te laten doorlopen tot zes maanden na de release, waardoor het oplossen van de dan gevonden fouten een onderdeel van het ontwikkelproject wordt. Nu worden de topmensen meestal al lang voor de release op andere projecten gezet, zodat zij te weinig leren.
Optimaliseren van testen
Zal de noodzaak van testen verminderen door de invoering van zulke leerprocessen of zal testen juist een prominentere functie in de ontwikkeling krijgen?
Schaefer: "De noodzaak van testen blijft, omdat het een onderdeel van het leerproces is. Omdat de complexiteit van de software sneller toeneemt dan onze mogelijkheden om die te testen, zal de nadruk op testen alleen maar toenemen. Denk maar aan de invoering van de euro en wat dat allemaal voor problemen kan veroorzaken. Vooral in landen zoals België en Italië die geen centen kennen in hun bedragen… Daarom is het belangrijk om vanaf het begin van een project goed na te denken over hoe je wilt gaan testen. De testers zullen tenminste even gekwalificeerd moeten zijn als de ontwikkelaars. Dat betekent dat het management testen aantrekkelijker zal moeten maken, want de meesten zien het nu als een geschikte bezigheid voor aankomende of uitgerangeerde programmeurs."
In de ogen van Schaefer zou het ontwikkelen van de testcases heel goed gedaan kunnen worden door gebruikers en de test-automatisering door een aparte groep die gereedschappen bouwt. Hij vergelijkt testen met het werk van parkeerwachters, die ook dingen moeten controleren en die door de rest van de wereld meestal niet positief worden beoordeeld. "Toch moeten ze er zijn en vervullen ze een nuttige functie." Ook topmanagers zullen dat moeten inzien. Zij zullen zich meer met kwaliteit en testen moeten bezighouden.
Binnenkort gaat Schaefer met vakantie naar China en hoopt daar te kunnen meerijden op de stoomlocomotieven. Een vreemde hobby voor iemand die met computersystemen werkt? "Helemaal niet!" Lachend zegt hij: "Dat is pure hardware, daarvan weet je precies wat het wel en niet doet. Dat zul je van software nooit kunnen zeggen…"
Hein van Steenis,
freelance medewerker Computable
