De kleine TMMi Doelgericht testprocessen verbeteren
Erik van Veenendaal en Jan Jaap Cannegieter
Inhoud Ten geleide
9
1
Inleiding 1.1 Introductie 1.2 Het Test Maturity Model integration 1.3 Bronnen 1.4 De kosten en baten van TMMi
13 13 13 15 18
2
TMMi: het model 2.1 Inleiding 2.2 De volwassenheidsniveaus van TMMi 2.2.1 Niveau 1 Initieel 2.2.2 Niveau 2 Beheerst 2.2.3 Niveau 3 Gedefinieerd 2.2.4 Niveau 4 Management en meting 2.2.5 Niveau 5 Optimalisatie 2.3 De structuur van een procesgebied 2.4 Generieke componenten en samenhang met specifieke componenten
21 21 22 22 23 24 25 26 26
3
TMMi-procesgebieden, -doelstellingen en -toepassingen 3.1 Inleiding 3.2 Generieke doelstellingen en generieke toepassingen 3.3 Specifieke doelstelling en specifieke toepassingen Testbeleid en -strategie Testplanning Testbewaking en -beheersing Testontwerp en -uitvoering Testomgeving Testorganisatie Testopleidingsprogramma Testfasering en -integratie Niet-functioneel testen Collegiale reviews
31 31 32 36 36 37 40 42 45 46 49 50 52 55
4
TMMi-assessments 4.1 Inleiding 4.2 Assessmenttypen 4.3 TMMi-assessmentaanpak 4.4 Certificering van TMMi-assessors
56 56 56 59 63
Inhoud
28
5
TMMi implementeren 5.1 Inleiding 5.2 Het veranderingsproces 5.3 Succesfactoren TMMi-implementatie 5.3.1 Opstarten verbeterproces 5.3.2 Realiseren verbeteringen 5.4 Test Process Improvement Manifesto
65 65 66 72 72 74 75
Bijlage 1 Relaties tussen TMMi en CMMI
78
Bijlage 2 Bronnen voor invulling van TMMi
82
Bronvermeldingen
88
Verklarende woordenlijst
91
Over de auteurs
100
Over de bedrijven
102
Register
104
De kleine TMMi
1
Inleiding
1.1 Introductie De afgelopen decennia laten zich kenmerken door de bewustwording in de IT-industrie dat continue kwaliteitsverbetering van doorslaggevende betekenis is om op langere termijn te kunnen overleven. Dit kan onder andere verklaard worden doordat de markt steeds hogere kwaliteits eisen stelt aan softwareproducten evenals het belang van software in de maatschappij als geheel. Voor een blijvende betrouwbare werking dienen softwareproducten van hoge kwaliteit te zijn. IT-organisaties en -afdelingen worden gedwongen om kwaliteitssystemen te ontwerpen en in te richten waarmee kwalitatief hoogwaardige producten worden voortgebracht. Het fenomeen ‘software process improvement’ kwam in een stroomversnelling na de introductie van het Software Capability Maturity Model, afgekort CMM [Paulk e.a.]. Dit model gaf de nodige structuur en richting aan procesverbeteringstrajecten. CMM werd het middel om te bepalen ‘waar een organisatie staat’. Zoals Watts Humphrey het zelf graag beschreef: ‘If you don’t know where you are, a map won’t help.’ Voor de testwereld bleek CMM echter onvoldoende. Op volwassenheidsniveau 3 van het CMM worden er weliswaar eisen aan het testproces gesteld, maar deze zijn van een te hoog abstractieniveau om daadwerkelijk bruikbaar te zijn. Deze beperkte diepgang is in tegenspraak met het feit dat testen zo’n 30% tot 40% van het totale projectbudget voor zijn rekening neemt. De opvolger van het CMM, het Capability Maturity Model Integration for Development (CMMI) [CMMI DEV], heeft met de procesgebieden Verificatie en Validatie meer aandacht voor testen. CMMI blijft echter voor een stapsgewijze verbetering van het testproces te weinig gedetailleerde handvatten bieden. De nadruk van CMMI ligt op organisatorische en software engineering-processen en niet zozeer op de karakteristieken van het testproces. Als antwoord op deze problematiek is door de TMMi Foundation het Test Maturity Model integration (TMMi) ontwikkeld. TMMi is een model dat ten aanzien van CMMI als complementair wordt gepositioneerd en dat een kader schept voor het verbeteren van de kwaliteit van de testprocessen. 1.2
Het Test Maturity Model integration
Oorsprong
Het TMM-raamwerk is in de jaren negentig ontwikkeld door het Illinois Institute of Technology [Burnstein] als een model, complementair aan het CMM, specifiek gericht op het verbeteren van testprocessen. TMMi bouwt voort op het TMM-raamwerk en de praktijkervaringen in verschil lende domeinen met TMM. Daarnaast zorgt TMMi voor afstemming
Inleiding
13
en complementariteit ten aanzien van CMMI. Deze complementariteit is voor veel organisatie die CMMI gebruiken een belangrijke reden om voor TMMi te kiezen als testverbetermodel. Testen wordt binnen TMMi gedefinieerd in de meest brede zin van het woord en omvat alle productkwaliteitsgerelateerde verificatie- en validatieactiviteiten.
Testen: Het proces bestaande uit alle levenscyclusactiviteiten, zowel statisch als dynamisch, die te maken hebben met planning, voorbereiding en evaluatie van producten en aanverwante zaken om aan te tonen dat ze aan de gespecificeerde eisen voldoen, dat er wordt voldaan aan de doelstelling en om fouten op te sporen [ISTQB Foundation Syllabus].
Structuur
TMMi hanteert een aantal volwassenheidsniveaus die grotendeels sequentieel doorlopen moeten worden tijdens het verbeteren van een testproces. Binnen TMMi is een vijftal niveaus onderkend op basis waarvan kan worden bepaald hoe volwassen het testproces is en welke verbeteringen noodzakelijk zijn c.q. prioriteit dienen te krijgen. Op elk niveau van het model wordt een aantal procesgebieden onderkend en voor elk procesgebied is een aantal volwassenheidsdoelstellingen gedefinieerd. Een organisatie voldoet aan de eisen van een bepaald TMMiniveau als aan alle gedefinieerde doelstellingen van het betreffende niveau is voldaan. Voordelen
Het toepassen van TMMi levert een gestructureerd en beheerst testproces, een positieve bijdrage aan productkwaliteit, een hogere productiviteit van de testorganisatie en veelal doorlooptijdverkorting (zie paragraaf 1.4). TMMi is ontwikkeld om organisaties te ondersteunen bij het evalueren en verbeteren van hun testproces. Binnen TMMi ontwikkelt testen zich van een chaotisch, ongestructureerd proces met een tekort aan goed opgeleide testers en tools, tot een volwassen en beheerst proces dat het voorkomen van fouten als belangrijkste doelstelling heeft. Scope
De doelgroep van TMMi is net zoals bij CMMI zowel de software- als system engineering-discipline. TMMi richt zich op de testactiviteiten en het verbeteren van testprocessen in beide disciplines. System engineering betreft de ontwikkeling van totale, meestal multidisciplinaire, systemen, waar zowel software als hardware onderdeel van uit kunnen
14
De kleine TMMi
maken. Bij software engineering gaat het specifiek om de ontwikkeling van softwareproducten c.q. informatiesystemen. Sommige modellen voor testprocesverbeteren richten zich met name op de black-box testsoorten, zoals TPI [Koomen/Pol] of TPI Next [TPI Next], of slechts op één pijler van gestructureerd testen, zoals het Test Organization Maturity (TOM)-model gericht op het onderdeel test organisatie. TMMi richt zich nadrukkelijk op alle testsoorten inclusief statisch testen en alle pijlers van gestructureerd testen. Ten aanzien van dynamisch testen zijn derhalve zowel white-box testen als black-box testen nadrukkelijk onderdeel van het verbeterproces binnen TMMi. Als men het model in detail bestudeert, komen nadrukkelijk alle vier de pijlers van gestructureerd testen (fasering, technieken, organisatie en infrastructuur [TMap]), alsmede de essenties uit TMapNext [TMapNext] aan bod. 1.3
Bronnen
Capability Maturity Model Integration
Bij de ontwikkeling van TMMi is nadrukkelijk gebruikgemaakt van het TMM-raamwerk zoals ontwikkeld door het Illinois Institute of Technology. Naast het TMM is ook CMMI een hele belangrijke bron geweest tijdens de ontwikkeling van TMMi. CMMI is inmiddels een de facto standaard voor procesverbeteren binnen de IT-industrie. Het CMMI-model onderkent zowel een stapsgewijze als een continue representatie. De stapsgewijze representatie gaat uit van een voorgedefinieerd groeipad langs verschillende volwassenheidsniveaus en procesgebieden. Bij de continue representatie wordt voor ieder procesgebied een aantal vaardigheidsniveaus beschreven. De volgorde waarin de procesgebieden worden geïmplementeerd dient de organisatie vervolgens zelf te bepalen en dat geldt tevens voor het gewenste vaardigheidsniveau per procesgebied. TMMi is ontwikkeld als een groeimodel met een stapsgewijze represen tatie. Het TMMi-model heeft een structuur waarbij procesgebieden, doelstellingen en toepassingen worden onderkend. CMMI is met name gebruikt bij de naamgeving en definities van de structuurelementen (zie paragraaf 2.3) alsmede de uitwerking van sommige procesgebieden. Zowel TMMi als CMMI maken gebruik van het overervingsprincipe: ‘aan alle onderdelen van het onderliggende niveau dient te zijn voldaan, om te kunnen beginnen met het daaropvolgende niveau’. TMMi is niet alleen qua structuur vergelijkbaar met CMMI, het is tevens een aanvulling op CMMI toegespitst op het testproces. Door de TMMi Foundation wordt aangegeven dat in een later stadium wellicht een continue representatie van TMMi wordt ontwikkeld. Dit zal naar alle waarschijnlijkheid de
Inleiding
15
inhoud van het model niet veranderen. Het zal slechts van invloed zijn op de structuur en representatie. Door de TMMi Foundation is TMMi gepositioneerd als complementair aan CMMI. In veel gevallen heeft een te bereiken TMMi-niveau speci fieke ondersteuning nodig vanuit procesgebieden binnen CMMI op een vergelijkbaar of lager niveau. In sommige gevallen zelfs vanuit een hoger CMMI-niveau. Procesgebieden en activiteiten die in detail zijn uitgewerkt binnen CMMI zijn over het algemeen niet opnieuw beschreven binnen TMMi. Naar deze procesgebieden wordt slechts verwezen. Een voorbeeld is het procesgebied Configuratiemanagement. Uiteraard is configuratiemanagement tevens van toepassing op testproducten (testware). Dit onderdeel is niet in detail uitgewerkt binnen TMMi; aan de configuratiemanagementactiviteiten binnen CMMI wordt gerefereerd en ze worden impliciet hergebruikt. Het procesgebied Collegiale reviews vormt een uitzondering op deze regel. Dit is zowel in CMMI als onderdeel van een procesgebied als in TMMi als procesgebied opgenomen aangezien TMMi ook als een zelfstandig testverbetermodel moet kunnen worden toegepast. Evolutionair testmodel
Een andere belangrijke bron voor de ontwikkeling van TMMi is het evolutionaire testmodel, ontwikkeld door Gelperin en Hetzel [Gelperin/ Heztel], waarin de evolutie van het testproces wordt beschreven over een periode van veertig jaar. Ook is gebruikgemaakt van het door Beizer ontwikkelde model waarin de evolutie van de denkwijze van de individuele tester centraal staat [Beizer], en internationale teststandaarden zoals de IEEE 829-standaard voor softwaretestdocumenten [IEEE 829]. De testterminologie die wordt gebruikt in TMMi is volledig afgestemd op de wereldwijde terminologie zoals gedefinieerd door de ISTQB en vastgesteld in de ISTQB Standard Glossary of Terms Used in Software Testing [ISTQB Glossary of Terms]. De eerste fase in het evolutionaire testmodel van Gelperin en Hetzel is beschreven als ‘debugging-oriented’. Gedurende deze fase, te vergelij ken met TMMi-niveau 1, kent de softwareorganisatie geen verschil tussen testen en debuggen. Testen wordt gezien als een debugging-activiteit. Het doel van testen is ervoor te zorgen dat de software draait zonder down te gaan. In de daaropvolgende ‘demonstration-oriented’ fase wordt het testen losgekoppeld van debuggen. Beide activiteiten hebben hun eigen doelstelling: debuggen moet ervoor zorgen dat de software draait en testen heeft als doel te laten zien dat de software functioneert conform de specificaties. Tijdens deze fase worden testplanning en testtechnieken geïntroduceerd in de organisatie. Testen start echter pas
16
De kleine TMMi
relatief laat in het project. De demonstration-oriented fase en de hierop volgende ‘destruction-oriented’ fase hebben een sterke relatie met TMMi-niveau 2. In de destruction-oriented fase wordt testen gezien als een activiteit om fouten te ontdekken. De stelling ‘dat er altijd fouten zijn’ geldt hierbij als uitgangspunt. De testdoelstelling ‘aantonen dat de software functioneert volgens de specificatie’, wordt nadrukkelijk uitgebreid met het zogenoemde negatief testen. Negatief testen wordt hierbij gedefinieerd als ‘testen om aan te tonen dat een component of systeem niet werkt’ [BNTQB]. Het negatief testen heeft meer te maken met de houding van de testers dan met een specifieke aanpak of een testontwerptechniek, zoals testen met ongeldige invoerwaarden of uitzondering. Tijdens de ‘evaluation-oriented’ fase wordt testen geïntegreerd in het softwareontwikkelproces. Testen is nu een activiteit die al vroegtijdig in een project begint. De scope van testen wordt verruimd door ook het vinden van fouten in documentatie (bijv. requirements) met behulp van reviews als testen te beschouwen. Alle activiteiten die te maken hebben met het vinden van fouten, worden gezien als onderdeel van het testproces. De doelstelling van testen wordt geformuleerd als (kwantitatief) inzicht bieden in de kwaliteit van het product. De evaluation-oriented fase is te koppelen aan elementen uit TMMi-niveau 3 en gedeeltelijk zelfs aan TMMi-niveau 4. Het model wordt gecompleteerd door de ‘prevention-oriented’ fase, vergelijkbaar met TMMi-niveau 5. Tijdens deze fase is testen een volledig gedefinieerd en beheerst proces. De focus van het testen is niet meer het vinden van fouten, maar het voorkomen van fouten, zowel in het product als het proces. De testactiviteiten zoals reviews, testplanning en testontwerp zijn dan ook hierop gericht. Tevens worden nieuwe testactiviteiten zoals causale analyse in de organisatie geïntroduceerd. De samenhang tussen het evolutionaire testmodel en TMMi is weerge geven in tabel 1.1. Tabel 1.1 Relatie evolutionair testmodel en TMMi Evolutionair testmodel
TMMi
Debugging-oriented fase
niveau 1 ‘Initieel’
Destruction-oriented fase
niveau 2 ‘Beheerst’
Demonstration-oriented fase Evaluation-oriented fase
niveau 3 ‘Gedefinieerd’ niveau 4 ‘Management en meting’
Prevention-oriented fase
Inleiding
niveau 5 ‘Optimalisatie’
17
1.4 De kosten en baten van TMMi Het uitvoeren van een verbetertraject met behulp van TMMi vraagt om een investering. Wanneer men spreekt over kosten en opbrengsten van TMMi wordt doorgaans een onderscheid gemaakt tussen harde en zachte kosten, en harde en zachte opbrengsten. Harde kosten en opbrengsten zijn die zaken die direct aan het verbetertraject zijn toe te wijzen en tevens direct in geld zijn uit te drukken. Voorbeelden van harde kosten zijn inspanning van mensen (uren), training en externe ondersteuning. Voorbeelden van harde opbrengsten zijn toename in productiviteit en minder verstoringen tijdens productie en lagere herstelkosten als gevolg van het eerder vinden van fouten. Zachte kosten en opbrengsten zijn die zaken die op een indirecte manier met het verbetertraject te maken hebben of moeilijk in geld zijn uit te drukken. Voorbeelden van zachte kosten zijn de benodigde tijd voor een leercurve, inwerktijd door functieveranderingen en productiviteits verlies door weerstand. Voorbeelden van zachte opbrengsten zijn toename in motivatie van personeel, trouwere klanten, hogere uitwisselbaarheid van medewerkers en een betere werksfeer. In de praktijk worden voor een Return on Investment (ROI)-berekening vaak alleen de harde kosten en harde opbrengsten meegenomen. Aan de ene kant is dat begrijpelijk omdat deze gegevens eenvoudiger te bepalen zijn dan de zachte kosten en opbrengsten. Aan de andere kant zijn de zachte opbrengsten soms groter of zelfs belangrijker dan de harde opbrengsten. Het is dan ook beter om te proberen ook de zachte opbrengsten mee te nemen wanneer de toegevoegde waarde van een TMMi-verbetertraject wordt bepaald. Aangezien investeringen in procesverbetereringen gedurende een langere periode om steun van het management vragen, is het cruciaal het rendement van een dergelijk verbetertraject te meten. Aangezien TMMi nog relatief jong is, is het aantal publicaties over kosten en opbrengsten vanuit de praktijk beperkt. Om hier toch een idee van te krijgen, is in tabel 1.2 een overzicht opgenomen van praktijkcijfers over verbetertrajecten in het algemeen. Let wel, dit zijn voornamelijk cijfers van CMM(I)-verbetertrajecten. De tabel is hier opgenomen onder de aanname dat TMMi-verbetertrajecten zich in enigszins vergelijkbare regionen bevinden. In de praktijk wordt vaak gezegd dat de opbrengsten van procesverbetering moeilijk te meten zijn. De meeste organisaties vinden het relatief eenvoudig om kosten te meten, maar hebben het moeilijk zodra het om de opbrengsten gaat. De harde opbrengsten van TMMi worden veelal gemeten door de oude situatie, de situatie van voor de implementatie van TMMi, te vergelijken met de nieuwe situatie. Het uitdrukken van zachte
18
De kleine TMMi
Tabel 1.2 Kengetallen van verbetertrajecten [Van Solingen] SPI-kengetallen
Reële
Reële
Gemiddelde
minimumwaarde
maximumwaarde
waarde
C 1.000
C 5.000
C 2.500
1%
5%
3%
C 5.000
C 55.000
C 20.000
4
10
7
Kosten Financiële uitgaven per medewerker Tijdsbesteding per medewerker Opbrengsten Financiële waardering per medewerker Return On Investment
opbrengsten, zoals ‘toename van klanttevredenheid’ of ‘meer motivatie bij personeel’, kan door middel van interviews of vragenlijsten worden gemeten. Zoals eerder aangegeven is het expliciet meten van kosten en opbreng sten van een investering in TMMi belangrijk. Dit garandeert de conti nuïteit van het verbetertraject en stimuleert het commitment van zowel management als medewerkers. Om enigszins een beeld te geven van mogelijke resultaten (opbrengsten) wordt hierna een aantal resultaten weergegeven van organisaties die een TMMi-verbetertraject hebben uit gevoerd waarbij één van de auteurs betrokken was. Een organisatie in het domein van de technische automatisering, die uiteindelijk als één van de eerste testorganisaties wereldwijd TMMiniveau 3 bereikte, rapporteerde resultaten op het gebied van verkorting van de doorlooptijd van de testuitvoeringsfase (figuur 1.1) en een hogere foutvindeffectiviteit tijdens de systeemtest (figuur 1.2). De foutvind effectiviteit is hierbij gedefinieerd als ‘het aantal gevonden fouten in een testfase, gedeeld door het aantal gevonden fouten in de testfase plus de fouten die erna, op welke manier gevonden worden’ [ISTQB Glossary of Terms]. Bijna elke organisatie rapporteert na verloop van tijd een betere voor spelbaarheid van het testproces. Dit is onder andere te zien in figuur 1.3. Deze rapportage is eveneens afkomstig van een organisatie uit het tech nische domein; ditmaal een organisatie van TMMi-niveau 2. Uit het financiële domein ten slotte nogmaals een rapportage die een verbetering
Inleiding
19
van de foutvindeffectiviteit tijdens de systeemtest laat zien (figuur 1.4). Deze organisatie was op weg naar TMMi-niveau 2. 20 18 16 14 12 10 8 6 4 2 0 Jaar 1
Jaar 2
Jaar 3
Figuur 1.1 Testdoorlooptijd van de systeemtest (in weken) 75 70 65 60 55 50 Jaar 1
Jaar 2
Jaar 3
Jaar 4
Figuur 1.2 Foutvindeffectiviteit van de systeemtest (percentage) 160 140 120 100 80 60 40 20 0
Figuur 1.3 Afwijking testtijd besteed versus begroot (percentage)
50 40 30 20 10 0 Jaar 1
Jaar 2
Jaar 3
Figuur 1.4 Foutvindeffectiviteit van de systeemtest (percentage)
20
De kleine TMMi
