Organisaties worden zich steeds bewuster van de noodzaak om gestructureerd te testen, en zoeken naar wegen om hun testproces te verbeteren. Daarbij grijpt men vaak naar modellen voor het optimaliseren van testprocessen. Hoewel deze modellen waardevolle diensten bieden bij doordacht gebruik, kleven er ook nadelen aan. Optimalisatie van het testproces vereist een bedrijfsspecifieke aanpak, terwijl de beschikbaar modellen standaardrecepten bieden. Een testconsultant laat zien hoe een maximaal rendement is te behalen.
Modellen voor testprocesoptimalisatie kennen een aantal knelpunten. Zo zijn de vragenlijsten erg lang waardoor een beoordeling veel tijd in beslag neemt Veel modellen stellen een diagnose van het ‘gedrag’ van de betrokken organisatie en besteden geen aandacht aan de problemen waarmee managers en gebruikers in de praktijk worden geconfronteerd. Verder zijn modellen niet bedrijfseigen. Er worden ‘standaard’ oplossingen geboden voor unieke problemen en er bestaat geen mogelijkheid om voort te borduren op wat er reeds is opgebouwd binnen een specifieke organisatie. Tevens zijn de beschrijvingen te complex en vaktechnisch voor niet-professionele softwaretesters en IT- en lijnmanagers die het testproces in hun portefeuille hebben.
Een aantal modellen houdt geen rekening met ondernemingsdoelstellingen, en middelen om resultaten te kwantificeren en te meten ontbreken vaak
De genoemde beperkingen worden hieronder nader toegelicht.
Beperking modellen
Bij een inventarisatie van de beschikbare modellen blijkt dat diverse daarvan vragenlijsten bevatten, gericht op het bepalen van de huidige stand van zaken ten aanzien van het testproces. Het beantwoorden van deze vragen leidt veelal tot indeling op een schaal, waaruit de volwassenheid van het testproces blijkt. Een nadeel van dergelijke vragenlijsten is dat zij vaak (te) veelomvattend zijn. Het beantwoorden van honderden vragen werkt niet bemoedigend wanneer men het testproces onder handen wil nemen. Bovendien ligt de problematiek binnen een organisatie vaak op een beperkt aantal specifieke gebieden. Het stellen van honderden vragen doet derhalve aan als het vuren van een schot hagel om deze problemen boven tafel te halen. Dit is niet efficiënt.
Het feit dat veelal een diagnose van gedrag wordt gesteld, in plaats van de problemen die de organisatie ondervindt in kaart te brengen, is een ander serieus manco van diverse modellen. Vergelijk dit met een huisarts die een patiënt met rugklachten naar huis stuurt, met het advies meer groente en fruit te eten en te stoppen met roken. Alhoewel stuk voor stuk goede adviezen om de gezondheidstoestand van de patiënt te verbeteren, leiden zij niet tot een oplossing voor het probleem.
In het verlengde hiervan moet bedacht worden dat het bieden van standaardoplossingen zowel voor- als nadelen met zich meebrengt. Een mogelijk voordeel is dat een bepaald advies zich keer op keer in de praktijk heeft bewezen. Het gevaar is echter aanwezig dat wanneer onvoldoende rekening wordt gehouden met de unieke omstandigheden die de organisatie kenmerken, een standaardrecept geen of zelfs een averechts effect heeft.
Bij elk verbetertraject is het van essentieel belang dat wordt uitgegaan van de (bedrijfs)doelstellingen van de organisatie. Enkele modellen houden hier rekening mee. Anderen gaan hier echter aan voorbij, hetgeen ertoe kan leiden dat men de verkeerde richting op wordt gestuurd. Een voorbeeld van zo’n doelstelling is dat testen ertoe moet leiden dat van elk systeem inzicht bestaat of het aan de acceptatiecriteria voldoet. Het is duidelijk dat bij een dergelijke doelstelling andere verbeteracties passen, dan wanneer de organisatie ernaar streeft de doorlooptijd van het testen te halveren!
Tot slot heeft het ontbreken van middelen om resultaten te meten en te kwantificeren tot gevolg dat organisaties niet in staat zijn de effectiviteit van doorgevoerde maatregelen vast te stellen. Of een verbetertraject voor hen rendabel is geweest, blijft daardoor ongewis.
Problemen overwinnen
De genoemde beperkingen zijn zeker geen reden om de bestaande modellen voor het verbeteren van het testproces links te laten liggen. Voor veel organisaties is het noodzakelijk de kwaliteit van het testen te verbeteren. Een model kan daarbij een bruikbaar hulpmiddel zijn, zolang het met de nodige zorg wordt gehanteerd. Drie tips bij het hanteren van modellen zijn: gebruik het model voor jezelf als een checklist;
Stel het model niet centraal, en raadpleeg een consultant die beschikt over uitgebreide testexpertise en gedegen adviesvaardigheden.
Wat kan men nu nog meer doen om te profiteren van de voordelen van modellen? Eén mogelijke werkwijze, die door ons met succes is toegepast, is hieronder weergeven.
- Formuleren van probleemstelling en doelstellingen;
- Beoordelen van stand van zaken op basis van verkorte vragenlijst en probleemanalyse;
- Brainstormen over oplossingsrichtingen;
- Aanvullen lijst van oplossingen met behulp van ‘standaard’ oplossingenmodel;
- Opstellen plan van aanpak (inclusief toetsing ideeën);
- Terugkoppelen voorstellen naar de organisatie en zonodig bijstellen,
- Bijstellen plan van aanpak;
- Verkrijgen van goedkeuring budgetten, en dergelijke,
- Uitvoeren eerste cyclus verbeteringen;
- Evalueren testresultaten;
- Bijstellen aanpak naar aanleiding van evaluatie;
- Uitvoeren tweede cyclus verbeteringen.
Van probleemstelling naar oplossingsrichting
Het vertrekpunt bij de gehanteerde aanpak wordt gevormd door de doelstellingen en de problemen van de organisatie. Doelstellingen moeten ‘smart’ zijn: specifiek, meetbaar, acceptabel (voor de betrokkenen), realistisch en tijdgebonden. Dit verschaft een basis om na het doorvoeren van verbeteringen de resultaten daarvan te kunnen toetsen aan de doelstellingen. Tevens dienen zij aan te sluiten bij de meer algemene bedrijfsdoelstellingen van de betrokken organisatie.
Nadat de doelstellingen en de probleemstelling expliciet zijn gemaakt, wordt de stand van zaken ten aanzien van het testproces in kaart gebracht. Hierbij wordt gebruik gemaakt van een ingekorte vragenlijst, die is afgeleid van het gehanteerde model. Het is raadzaam om de vragen, die gewoonlijk in vaktermen zijn geformuleerd, te vertalen naar de belevingswereld van de personen die de vragen gaan beantwoorden. Vraag bijvoorbeeld niet aan een eindgebruiker of er binnen zijn organisatie aan ‘white-box’ testen en ‘black-box’ testen wordt gedaan. De kans is groot dat je dan het eerstvolgende half uur kwijt bent om de begrippen ‘white-box’ en ‘black-box’ uit te leggen. Een geschiktere vraag is bijvoorbeeld hoe ontwikkelaars hun eigen software testen, waar zij daarbij op letten, en in hoeverre er tevens functionele- en gebruikerstesten plaatsvinden om te komen tot acceptatie.
Als onderdeel van de inventarisatie onderzoekt men tevens in meer detail voor welke problemen de organisatie zich in de praktijk geplaatst ziet. De probleemstelling wordt dus verder uitgediept. Een nuttig hulpmiddel daarbij is het houden van interviews met vertegenwoordigers van diverse betrokken afdelingen (gebruikers, beheerders, systeemeigenaren, ontwikkelaars, enzovoort). Hier kan een schat aan informatie worden gewonnen! Teneinde een gemeenschappelijk kader te kweken, is het ook zinvol om in een sessie met vertegenwoordigers van de organisatie gezamenlijk de problemen in kaart te brengen. Eventueel kan een taxatie worden gemaakt van het volwassenheidsniveau van de organisatie in relatie tot het gehanteerde model. Of dit aan de orde is, is afhankelijk van de gekozen doelstelling(en). Een belangrijke vraag is of de organisatie capabel genoeg is om te kunnen veranderen. Als het antwoord daarop ontkennend is, is het beter om op korte termijn geen investeringen te doen in het testproces. Resultaten zouden in deze omstandigheid immers uitblijven.
Zodra helder is waar de organisatie staat en wat de op te lossen problemen zijn, wordt gericht gewerkt aan het definiëren van doeltreffende maatregelen. Het verdient aanbeveling in deze fase de verleiding te weerstaan om direct naar een model te grijpen. Het raadplegen van de geboden ‘standaardoplossingen’ kan ertoe leiden dat het creatieve gedachteproces in de kiem wordt gesmoord. Het gaat er nu juist om oplossingen te bedenken die toegespitst zijn op de unieke omstandigheden waarin men zich bevindt. Begeleiding door een ervaren testconsultant is raadzaam om het proces in goede banen te leiden. Daarbij moet echter worden voorkomen dat de (externe) consultant met een lijst van voorstellen komt, die klakkeloos wordt overgenomen. De organisatie moet immer zelf kunnen en willen veranderen. De consultant begeleidt dat proces, maar neemt het niet over.
Voorstellen worden derhalve zoveel mogelijk geformuleerd door medewerkers van de eigen organisatie. Dit waarborgt dat de benodigde betrokkenheid tot stand komt. Bij het genereren van mogelijke oplossingen kan dankbaar gebruik worden gemaakt van technieken als brainstormen, brown paper-sessies, enzovoort. Waar het om gaat, is dat zoveel mogelijk suggesties worden aangedragen. De toetsing daarvan op bruikbaarheid komt later.
Waak ervoor dat bij het bepalen van de (concept) verbeteracties rekening wordt gehouden met hetgeen reeds goed is geregeld in de organisatie. Tracht daar op voort te borduren. Elke organisatie doet wel iets goed op het gebied van testen. Dit mag niet verloren gaan!
Zodra de ideeënstroom opdroogt (en niet eerder), kan men eventueel een model raadplegen en bekijken of daaruit nog zinvolle aanvullingen naar voren komen.
Plan van aanpak
Als de voorgaande stappen met succes zijn doorlopen, beschikt men over een uitgebreide lijst met mogelijke verbeteracties. Vervolgens gaat men bepalen aan welke criteria een verbeteractie moet voldoen. Hieronder volgt een aantal voorbeelden.
Acties moeten bijdragen aan het oplossen van de problemen of realisatie van de doelstellingen. Maatregelen moeten passen binnen een bepaald budget of binnen een bepaalde tijdsduur doorgevoerd kunnen worden. Verbeteracties mogen niet leiden tot ingrijpende organisatorische wijzigingen. De vereiste middelen om maatregelen door te voeren moeten aanwezig zijn, evenals het benodigde draagvlak.
Het is van belang te onthouden dat elke organisatie haar eigen criteria heeft. Men kan dus niet volstaan met standaardlijsten. Voorstellen die de toetsing aan de criteria doorstaan, worden in een concept plan van aanpak verzameld.
Zodra een eerste filtering van de voorstellen heeft plaatsgevonden, vindt terugkoppeling plaats naar vertegenwoordigers uit diverse delen van de organisatie. De vorm waarin dit gebeurt staat vrij. Mogelijke werkwijzen zijn het organiseren van workshops of discussiebijeenkomsten. Van belang is dat er gelegenheid bestaat tot interactie tussen de betrokkenen. Dit levert de waardevolste feedback op.
De volgende twee stappen in het proces zijn regulier van aard. Op grond van de resultaten van de voorgaande fasen wordt het Plan van Aanpak voor testprocesoptimalisatie nader uitgewerkt en zonodig bijgesteld. Vervolgens wordt het ter goedkeuring voorgelegd aan het management.
Bij het verkrijgen van de benodigde goedkeuring is het zaak te wijzen op de voordelen die voortvloeien uit de voorgestelde maatregelen. Gewoonlijk is daarbij een financiële onderbouwing in termen van kosten en baten nodig. Het is vaak niet eenvoudig om die op te stellen. De kosten van testprocesoptimalisatie zijn te calculeren, maar baten laten zich maar moeilijk in financiële termen voorspellen. Toch is het van belang hiertoe een poging te doen, daar bedrijfseconomische afwegingen vaak een doorslaggevende rol spelen in de besluitvorming. Eén mogelijke invalshoek is om te kijken naar de kosten die op dit moment gemaakt worden om storingen in de productie te herstellen, en naar de investeringen in correctief onderhoud. Ook verlies van productie ten gevolge van het niet functioneren van systemen, en de kosten van klachtenafhandeling zijn factoren die in de analyse betrokken kunnen worden. Aan de hand van dergelijke informatie wordt bepaald wat de kosten zijn die optreden als er niet wordt geïnvesteerd in optimalisatie van het testproces.
Doorvoeren van verbeteringen
Na het verkrijgen van de benodigde goedkeuring wordt een projectmanager aangesteld onder wiens leiding een verbeterteam – bestaande uit vertegenwoordigers van de organisatie – aan de slag gaat om verbeteringen door te voeren. Een goede informatievoorziening aan alle lagen van de organisatie is in deze fase uitermate belangrijk. Daarbij kan een kick-off bijeenkomst, het verspreiden van een nieuwsbrief of het instellen van een klankbordgroep van pas komen. Met name in deze fase kan weerstand ontstaan tegen het doorvoeren van veranderingen. Het is dan ook zaak hierop te anticiperen. De kwaliteit van de informatievoorziening en de mate van ondersteuning die wordt geboden, zijn de belangrijkste factoren die bijdragen tot acceptatie. In voorkomende gevallen kan het nodig zijn om met betrokkenen te onderhandelen omtrent de wijze waarop verbeteringen in het testproces worden geïmplementeerd.
De resultaten van de doorgevoerde maatregelen worden continu geëvalueerd. Ook vindt na afloop van de eerste cyclus een evaluatie van het project plaats. Op grond van de resultaten van deze evaluatie vindt, waar nodig, bijsturing plaats. Vervolgens start een nieuwe verbeterronde.
Het verbeteren van het testproces is een noodzakelijke aangelegenheid, die een bedrijfsspecifieke aanpak vereist. Modellen die standaardrecepten bieden, kunnen daarbij slechts ondersteunend zijn. Steeds moet worden gezocht naar op maat gesneden oplossingen. De hier geschetste aanpak helpt organisaties om verbeteringen in hun testproces te realiseren, die aansluiten bij hun doelstellingen.
Marco Dekkers, productmanager KZA kwaliteitszorg
Wat is testen?
Hieromtrent bestaat veel verwarring. Volgens een populair denkbeeld is testen het zoeken naar fouten. Dit is niet juist! Testen is een proces dat erop gericht is aan te tonen of de kenmerken van een product voldoen aan de eisen die daaraan zijn gesteld. Alle activiteiten die hiermee gepaard gaan zoals meten, onderzoeken en keuren vallen onder de definitie van testen. Als uitvloeisel van deze activiteiten ontstaat inzicht in de eventuele verschillen tussen de actuele status en de vereiste status van een product. Op grond van dit inzicht is af te leiden welke risico’s worden gelopen als men een bepaald product accepteert voor gebruik. Dit dient als basis voor (management) beslissingen omtrent in-productiename. Testen is dus een instrument om de kwaliteit (of het gebrek daarvan) vast te stellen. Het vinden van fouten is daarbij een middel en geen doel op zich.
Testen dient synchroon te lopen met systeemontwikkeling en is dus geen separate fase die volgt op realisatie. Idealiter start het testproces tegelijk met het opstellen van (functionele) ontwerpen.
Modellen voor optimalisatie testproces
In de afgelopen jaren zijn diverse modellen ontwikkeld die richting proberen te geven aan pogingen om het testproces te optimaliseren. Veel van deze modellen kiezen voor een benadering die vergelijkbaar is met die van het Capability Maturity Model, dat zich richt op de kwaliteit van systeemontwikkelingsprocessen.
Optimaliseren van testprocessen is een relatief jong vakgebied, getuige het feit dat nagenoeg alle modellen na 1995 zijn ontwikkeld en in feite nog lang niet uitontwikkeld zijn.
Hieronder enkele voorbeelden van beschikbare modellen.
Test Improvement Model: vertoont veel overeenkomsten met het CMM. Het model onderscheidt vijf niveaus: initieel, baseline, kosteneffectief, risicoverlagend en optimaliserend. Elk niveau stelt eisen aan onder andere de testorganisatie, planning en voortgangsbewaking en het ontwerp van testgevallen.
Test Organization Maturity: commercieel product dat niet wordt vrijgegeven. Na het invullen van een elektronische vragenlijst krijgt men een lijst van verbeterpunten toegestuurd. Aanbevelingen zijn afkomstig uit een database met standaardoplossingen en worden slechts beknopt omschreven.
Testability Maturity Model: model dat zich met name richt op de testbaarheid van informatiesystemen. Er worden drie niveaus onderscheiden: zwakke-, basis- en sterke testbaarheid. Het model besteedt geen aandacht aan de organisatie van het testproces en testtechnieken en is derhalve beperkter van opzet dan de overige modellen.
Testing Maturity Model: In 1996 als artikel gepubliceerd model van het Illinois Institute of Technology dat veel overeenkomsten vertoont met de opzet van het CMM. Het model onderscheidt vijf niveaus en omvat een beoordelingsmodel om de volwassenheid van een testproces te bepalen.
Test Process Improvement�: Nederlands model dat in 1998 werd gepubliceerd. Het model kent twintig aandachtsgebieden, elk met een aantal oplopende niveaus. Beoordeling van de stand van zaken vindt plaats op basis van een vragenlijst. De resultaten hiervan worden uitgedrukt in een ‘Test volwassenheidmatrix’.