KLM wil complexiteit te lijf

KLM wil naar geautomatiseerde softwaretesten. "Ik denk dat het een kwestie van tijd is voordat men vastloopt. De complexiteit van processen maakt het bijna onmogelijk om ketens nog van begin tot eind te testen."

Softwareapplicaties worden steeds complexer. Dat maakt het haast onmogelijk om ketens nog van begin tot eind te testen. Vandaar dat de testafdeling van KLM heef ingezet op de automatisering van het testproces.

Teammanager Testmanagement Henk van Merode ziet een grote toekomst voor het modelgebaseerd testen. Voor de daarvoor benodigde tools is het echter nog te vroeg. Die zijn nog niet in geïntegreerde vorm beschikbaar.

De softwaretesters van KLM hebben op dit moment tussen de dertig en de veertig projecten onder handen. "Er lopen nu zo'n 130 it-projecten binnen het bedrijf," vertelt Henk van Merode, de teammanager testmanagement. "Wij proberen in ieder geval bij de top-10 wat betreft budget en risico, aanwezig te zijn. Maar we kijken ook naar de andere projecten."

Bij elkaar heeft Van Merode dertig testconsultants tot zijn beschikking. "Die houden zich voornamelijk bezig met coördinatie en testmanagement." Dat betekent dat het testwerk van dit team zich op dit moment beperkt tot klantacceptatie, serviceacceptatie en validatie. In de toekomst wil men de ‘tools’ en het aantal testanalisten uitbreiden.

Die laatsten moeten er volgens Van Merode ook snel komen. "De applicaties worden steeds complexer. Het testen daarvan kun je niet meer alleen door eindgebruikers laten doen. Die zijn toch te veel gericht op dat stuk dat ze zelf gebruiken, ze testen de randen niet en zijn niet bekend met de tools."

"Bij de functionele acceptatie zijn veel testers betrokken. Die vallen nu onder functioneel applicatiebeheer aan de businesszijde. Eigenlijk zouden we bij de IT van KLM een eigen afdeling moeten hebben, die de functionele acceptatie opzet met gekwalificeerde testanalisten. Ik denk dat het een kwestie van tijd is voordat men vastloopt. De complexiteit van processen maakt het bijna onmogelijk om ketens nog van begin tot eind te testen."

Toegevoegde waarde

Tegelijkertijd realiseert Van Merode zich dat het niet eenvoudig is om zijn diensten intern te verkopen. "Het is heel moeilijk om onze toegevoegde waarde aan te tonen. We hebben veel nagedacht over de manier waarop we onszelf moeten positioneren. Je kunt bijvoorbeeld meten in de productiesystemen en op die manier proberen onze bijdrage te kwantificeren. Maar daarvoor krijgen we de medewerking niet. Bovendien is de metriek moeilijk te maken. Je loopt het risico dat er iets heel anders uit komt."

Overdreven: "Stel dat wij twintig fouten hebben gevonden. En dat zij vervolgens zeggen dat ze voorheen nooit fouten hadden. Volgens mij is de beste manier om gewoon bezig te zijn en te laten zien dat je een goed testproduct oplevert. Aan het eind van de rit vertel je wat je hebt geconstateerd en wat er nog open staat. Vervolgens is het aan de business om te bepalen of dat een acceptabel risico oplevert."

Volgens Van Merode werkt op risico’s en eisen gebaseerd testen dan ook het best. "Zijn de risico's groot, dan test je veel. Zijn ze kleiner, dan doe je minder. Dat is goed aan je klant uit te leggen." Vandaar dat hij hier voor de toekomst op inzet.
Testen op een hoger niveau is echter veel moeilijker dan wanneer je je beperkt tot de functionaliteit. "Als je een project hebt dat drie jaar loopt, dan zijn de initiële eisen aan het eind van de rit niet goed meer. Bovendien is 80 procent van de eisen goed te beschrijven. Maar voor de rest geldt dat niet."

Op risico’s gebaseerd testen past volgens Van Merode goed bij de moderne it-ontwerpen. "Die zijn heel ingewikkeld en vragen om een multidisciplinaire aanpak waarin verschillende competenties samenkomen." Daarvoor zou het nodig zijn om meer naar productrisico's te kijken. "Wat is de impact van de resterende risicogebieden op je business, en wat is de kans dat het daadwerkelijk gebeurt in de productieomgeving? Dan komt het aan op kennis van het bedrijf, van wat de business drijft, en van de risico's. Daarover is wel veel bekend bij de business."

Die afhankelijkheid van de business maakt die aanpak echter moeilijk te verkopen. "Dan komt er al gauw terug "waar bemoei je je mee". We willen ons niet opdringen. Wij zouden het nooit accepteren als er nog fouten open staan die risico opleveren. De business heeft daarnaast echter nog hele andere overwegingen." Denk dan bijvoorbeeld aan de time-to-market en de kosten. "Je doet het uiteindelijk niet voor jezelf."

Supercomplex

Van Merode heeft echter niets te klagen over de samenwerking met projectmanagement. "Wij worden betrokken zodra er een it-vraag of -product in het spel komt, al vanaf het projectinitiatiedocument. Daar kunnen wij aangeven wat de kosten van het testproces zijn (ongeveer 30 procent), en benadrukken dat aandacht gegeven moet worden aan knelpunten zoals de testomgeving en het eventuele gebruik van geautomatiseerde testen. De projectmanager kan daar dan rekening mee houden bij hun aanbieding."

"Bovendien zijn ‘end-to-end’ tests heel ingewikkeld en moeten ze vroeg ingezet worden. Vandaar dat wij vanaf het begin een testmanager in het project laten meedraaien. Soms worden we al heel vroeg bij een project betrokken; dat is voor ons juist heel interessant. Ik wil nooit op de stoel van de business gaan zitten, maar soms vraagt een specifieke aanpak om een aanpassing van het testbeleid." Van Merode noemt moderne ontwikkelconcepten als rup (rational unified process), agile programming (ap) en soa (service oriented architecture) als voorbeelden.

"Met name soa maakt projecten ingewikkeld. Met zo'n enorme hoeveelheid kleine plukjes ontstaat een supercomplex systeem: al die afzonderlijke componenten werken afzonderlijk wel, maar samen soms niet meer. Soa lijkt heel aantrekkelijk, maar de complexiteit ligt in de oneindige ketens. Zolang dat binnen je eigen organisatie is, blijft dat nog overzichtelijk. Maar voor internationale organisaties wordt het moeilijk. Ik geloof in soa, maar het maakt het doortesten van de bedrijfsprocessen zeer lastig."

"Die complexiteit is alleen nog te managen met geautomatiseerde testen," aldus Van Merode. "Dat betekent dat we moeten investeren in tools en in mensen die die gereedschappen kunnen gebruiken." Op dit moment is het daarvoor echter nog te vroeg. "Het testen loopt altijd iets achter op de softwareontwikkeling. Bovendien moeten je mensen eerst ervaring met die tools opdoen."

Aan de gereedschappen wordt op dit moment wel gewerkt. "Soa wordt niet weggezet met de tools erbij. Daar zijn de leveranciers nu mee bezig." Voorbeeld daarvan is HP. "Ik was blij verrast met het enorme aantal tools dat beschikbaar is en komt. Het is wachten tot al die kleine deeloplossingen convergeren naar een nieuw integraal product."

Slimmer werken

Inherent aan de complexiteit van het testproces zijn de kosten natuurlijk een belangrijke drijfveer voor de transitie naar geautomatiseerde test-tools. "Die 30 procent kosten geldt voor het complete testproces, inclusief een deel van de ‘quality assurance’-activiteiten. Maar als je de processen niet aanpast, dan wordt dat nog duurder. We moeten slimmer werken en meer tooling gebruiken."

Volgens Van Merode wordt het testen daarmee een volwassen discipline. "Onder druk van de almaar stijgende kosten, wordt het testwerk steeds professioneler. We krijgen de tools. De methologieën zijn inmiddels redelijk stabiel. En testers zijn steeds meer gecertificeerd. Daarmee wordt testen langzaam maar zeker een vakgebied."