Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Het belang van een goede teststrategie

Nieuwe kijk op testen, deel 2

Onmisbare factor in strijd om langdurig concurrentievoordeel

 

Computable Expert

Henk Fliek MSc
Lead Accenture Testing Groep Nederland, Accenture. Expert van Computable voor het topic Development.

In het vorige artikel van deze reeks heb ik een eerste indruk gegeven over een verandering in de markt die momenteel plaatsvindt inzake testen: een toenemend besef bij bedrijven en instellingen wereldwijd dat een volwassen testproces een onmisbare factor kan zijn in de strijd om langdurig concurrentievoordeel. Ter ondersteuning van het meten en verbeteren van zowel het gehele testproces als specifieke onderdelen daarbinnen is het unieke Test Assessment Framework (TAF) ontwikkeld waarvoor reeds wereldwijd octrooi is aangevraagd. TAF geeft een volledige (driedimensionale) indruk van de testvolwassenheid van de gehele testorganisatie: eerste dimensie: drie testdomeinen (teststrategie, testlevenscyclus, testdisciplines) omvatten in totaal vijftien testgebieden die worden geëvalueerd op hun testvolwassenheid, tweede dimensie: de evaluatie vindt plaats tegenover de vijf testvolwassenheidsniveaus van het Testing Maturity Model (TMM), ontwikkeld in 1996 aan het Illinois Institute of Technology, via een ‘Quick Assessment’ (kortere periode, meer subjectief) of een ‘Full Assessment’ (langere periode, meer objectief) en derde dimensie: de testvolwassenheid van elk testgebied wordt bepaald via de drie testinvalshoeken in de organisatie: processen, technologie en de mensen. In dit tweede artikel zal ik stilstaan bij het eerste testdomein in TAF: het belang van een goede teststrategie.

Tijdens mijn masterstudie informatiewetenschappen in Engeland heb ik mijzelf vaak de vraag gesteld wat eigenlijk een strategie is. De beroemde, en vaak geciteerde business management professor Henry Mintzberg gaf me het verlossende en tevens voor de hand liggende antwoord: 'in gewone taal: een strategie is een plan'.

Een teststrategie is dus een plan, maar het is wel een plan dat van begin tot eind het testtraject beschrijft. De lezer van een goede teststrategie moet een helder beeld kunnen krijgen van de testprocessen die gaan worden gevolgd, de organisatie dit gaat uitvoeren en de technologie die het testen gaat ondersteunen. De teststrategie heeft dus betrekking op het gehele project of programma, van begin tot eind.

De teststrategie is zo belangrijk voor de organisatie dat het logisch is de drie testinvalshoeken gelijk te stellen aan de drie testgebieden binnen dit eerste TAF-testdomein. Oftewel, de teststrategie bestaat uit de volgende drie testgebieden:

- TAF-testgebied 1: testmethodologie (= proces)
- TAF-testgebied 2: testomgeving en tools
- TAF-testgebied 3: testorganisatie en communicatie

TAF-testgebied 1: testmethodologie

We komen nu aan bij de kern van het Test Assessment Framework: de teststrategie vormt de basis voor het testen en de methodologie vormt de basis voor de teststrategie. Met andere woorden:

- Wat is de uitgangssituatie voor het testen? Dit is het testmodel.
- Hoe passen we het model toe binnen het project, programma en de organisatie? Dit is de teststrategieplanning.
- Waarmee wordt het testmodel toegepast binnen het project, programma en de organisatie? Dit zijn de testtechnieken en disciplines.

Het testmodel
Elk project gebruikt tegenwoordig wel een vooraf gedefinieerde ontwikkelmethodologie. Bekende voorbeelden zijn waterval, iteratief en/of incrementeel, agile, scrum, RUP (Rational Unified Process), het spiral-model, etc. Elke methodologie heeft wel zijn voor- en nadelen, afhankelijk van de context waarin deze wordt toegepast. Zo is een watervalmodel niet echt geschikt in een omgeving die gekenmerkt wordt door veel veranderingen in specificaties tijdens de bouw en is een iteratief of agile-model niet geschikt in een omgeving waar men live moet gaan in een ‘big bang'. Hoe dan ook, er zullen altijd specifieke testfasen moeten worden doorlopen in elk project, of dit nu eenmalig is of vaker binnen een bepaalde projectfase. Het ‘V-model' is een voorbeeld van zowel een ontwikkel- als testmethodologie. Binnen dit model worden bekende testfasen beschreven als unit/component testen (tijdens de bouw; denk bijvoorbeeld aan Java's JUnit), systeemtesten, integratietesten (tussen verschillende systemen), performancetesten en gebruikersacceptatietesten.

Teststrategieplanning
Het testmodel is een belangrijk, maar echter ook ‘statisch' begrip; het is (slechts) een model. Hoe het testmodel gaat worden toegepast op het project, programma en de organisatie wordt beschreven in de teststrategieplanning. Bij dit onderdeel van het eerste TAF-testgebied komen belangrijke en ook herkenbare vragen aan de orde zoals:

- Wanneer, en onder welke condities worden de verschillende testproducten opgeleverd, zoals testscripts, testscenario's, testdata, testcondities, etc.?
- Welke testfasen worden onderkend binnen de testlevenscyclus en hoe zijn deze beschreven?
- Wat is de structuur van de testuitvoering? Bijvoorbeeld wanneer en hoe vaak worden de testscripts en scenario's uitgevoerd?
- Wat is de aanpak om tot een testbegroting te komen?

Testtechnieken en disciplines
Uiteindelijk zal de teststrategieplanning moeten worden gerealiseerd en ondersteund door middel van (geavanceerde) testtechnieken. Tijdens testuitvoering zal bijvoorbeeld gebruik worden gemaakt van zogenaamde ‘black box'- en ‘white box'-testtechnieken. Een voorbeeld van zo'n ‘white box'-testtechniek is ‘branch testing' waarbij alle paden binnen een programma (onderdeel) worden doorlopen. Vaak worden deze testtechnieken ondersteund door geautomatiseerde tools (bijvoorbeeld JUnit) om tijd te kunnen besparen tijdens de bouw van de software.

Bij ‘black box'-testtechnieken is weinig tot niets bekend over de inhoud van de software zelf. Hier wordt gebruik gemaakt van een andere aanpak om de kwaliteit van de software inzichtelijk te maken. Bekende voorbeelden van ‘black box'-testtechnieken zijn grenswaarde-analyse en equivalentiepartitionering, waarbij specifieke datasets worden losgelaten op de software om bugs te vinden die betrekking hebben op het afhandelen van data bij onder andere invoervelden. Andere voorbeelden van (black box) testtechnieken zijn statistisch testen (via wiskundige modellen), gebruikersvriendelijkheidtesten, performancetesten, installatietesten, etc. Maar ook regressietesten en testautomatisering (geautomatiseerd regressietesten) kunnen als testtechnieken of testdisciplines worden gezien. Een bekend voorbeeld van een testdiscipline is het defectmanagementproces (ook wel bevindingenbeheerproces genoemd). Menig tester of testmanager zal wel eens hebben ervaren hoe onprettig het kan zijn als dit proces niet tijdig is beschreven (in de teststrategie) en geïmplementeerd binnen het project!

TAF-testgebied 2: testomgeving en tools

De testmethodologie (testmodel, teststrategieplanning en de testtechnieken) van het eerste TAF-testgebied zal ondersteund moeten worden met de nodige testomgevingen en tools. Ook deze zullen dus op strategisch niveau moeten worden beschreven.

Testomgeving
Grootschalige projecten zullen vaak gebruik maken van specifieke testomgevingen die uniek zijn voor elke testfase zoals gedefinieerd in de testmethodologie. Voorbeelden zijn een specifieke systeemtestomgeving waar de software in afzondering kan worden getest van de bouw, een gebruikersacceptatietestomgeving waar de eindgebruikers het volledig geïntegreerde eindsysteem kunnen testen op bruikbaarheid, een performancetest omgeving die representatief is voor de productieomgeving, etc. Soms wordt een omgeving gebruikt voor twee of meer testfasen (bijvoorbeeld een gecombineerde systeemtest en gebruikersacceptatietest). In dit geval moet worden beschreven hoe deze enkele fysieke omgeving meerdere ‘logische' omgevingen gaat ondersteunen en problemen gaat voorkomen met betrekking tot testers en gebruikers, software-installaties, testdata, etc.

Testtools
De afgelopen jaren is er een flinke vooruitgang geboekt in zowel de functionaliteit, bruikbaarheid en volwassenheid van testtools. Deze zijn vaak niet goedkoop, maar kunnen een gestructureerd en volwassen testproces wel enorm ondersteunen en daardoor dus ook bijdragen aan langdurig concurrentievoordeel. TAF analyseert het gebruik van de voor de hand liggende testtools als testmanagement en -uitvoering, defectmanagement, testautomatisering en performancemanagement. TAF kijkt echter naar het gehele systeemontwikkeltraject en daarom worden tools ter ondersteuning van bijvoorbeeld requirementsmanagement en softwareconfiguratiemanagement (versie, migratie en releasemanagement) ook onder de loep genomen.

Een vaak onderschat, en juist kritisch onderdeel binnen het gebruik van testtools, is dat van configuratie en bestuur (Engels: ‘governance'). Neem als voorbeeld defectmanagement. Een geavanceerde tool voor defectmanagement zal zeer flexibel en configureerbaar zijn; je zult elke willekeurige testrol kunnen definiëren (bijvoorbeeld ‘tester', ‘testmanager', ‘bouwer') en elke bijbehorende autorisatie om het defect van de ene naar de andere status te brengen (bijvoorbeeld van ‘nieuw' naar ‘open', van ‘open' naar ‘opgelost', etc.). Echter, het bestuur en de structuur van de testorganisatie zullen eerst bekend moeten zijn voordat kan worden begonnen aan de configuratie en autorisatie van deze tools. Een gedegen testomgeving en toolsstrategie kan dus niet zonder een gedegen testorganisatie en communicatiestrategie.

TAF-testgebied 3: testorganisatie encommunicatie

Het testproces zal uiteindelijk moeten worden uitgevoerd door mensen. Als er één onderwerp is waarvan ik de indruk heb dat we er nog weinig over weten, dan is het wel de mens en zijn plaats binnen de organisatie. Duizenden wetenschappelijke boeken en artikelen zijn geschreven over de relatie van mensen binnen organisaties, de rol van informatie in de organisatie en het hieruit voortvloeiende ontwikkelproces van informatiesystemen. Een van de resultaten van mijn onderzoek en thesis had betrekking op ‘organizational learning'. Sommige organisaties blijken beter in staat zichzelf te verbeteren en meer volwassen te worden dan anderen in het ontwikkelen van informatiesystemen. We weten nog steeds niet precies wat hiervan de oorzaak is, maar het is algemeen aanvaard dat er in ieder geval een structuur binnen elke organisatie moet bestaan die deze ‘organizational learning' kan ondersteunen en begeleiden. Deze ‘structuur' bestaat uit de organisatie(structuur) zelf, de communicatie- en participatiestructuur en de trainingsstructuur.

Testorganisatie
Een volwassen testorganisatie is gemodelleerd volgens de structuur zoals gedefinieerd in het testmodel (zie TAF-testgebied 1: testmethodologie). Dit betekent dat er dus is nagedacht over de verschillende testrollen en benodigde vaardigheden en dat deze rollen zijn gecreëerd in de testorganisatie. Denk bijvoorbeeld aan testmanager, testlead (een testmanager verantwoordelijk voor een specifieke testfase), functionele tester, performance tester, etc. Ook zal de inhoudelijke (functionele) kennis van het te ontwikkelen informatiesysteem en de kennis van de testprocessen zelf moeten worden verdeeld over de verschillende testteams om gestandaardiseerd (ook wel bekend als ‘geïndustrialiseerd') testen mogelijk te maken.

Communicatie en participatie
Het is van groot belang dat iedereen die betrokken is bij het testproces continu op de hoogte is van de voortgang, risico's, issues, etc. De communicatiestructuur die dit mogelijk maakt moet worden gebouwd en gemanaged; je kunt er niet vanuit gaan dat effectieve communicatie zomaar vanzelf plaatsvindt. Menig tester zal hebben ervaren dat het er nogal hectisch aan toe kan gaan tijdens het einde van een testfase of aan het einde van het gehele testtraject als alle betrokkenen steeds meer en vaker willen weten waar het project staat met betrekking tot de testuitvoering, defects, kwaliteit van de software, etc. Een juiste communicatiestructuur helpt alle betrokkenen de juiste discussie te voeren en de juiste beslissingen te nemen.

Communicatie en participatie zijn sterk aan elkaar gerelateerd. Participatie is een noodzakelijke activiteit ter ondersteuning van effectieve communicatie. Denk bijvoorbeeld aan de analyse van requirements door een testmanager; als deze niet worden getoetst op testbaarheid zal het project in de testfase zeker in de problemen komen. Ook zullen de testcondities en testscripts, scenario's, etc. door de business moeten worden getoetst op onder andere kwaliteit en dekking, aangezien er een direct verband is tussen het succesvol uitvoeren van deze testscripts en het ‘live' gaan van het nieuwe informatiesysteem. Een goed gedefinieerde participatiestructuur die continu wordt gemanaged, zorgt ervoor dat alle betrokkenen in het testproces niet voor onaangename verrassingen komen te staan tijdens het testproces.

Training
Naast een effectieve organisatie-, communicatie- en participatiestructuur is ook training onontbeerlijk voor een toename in de volwassenheid van iedere testorganisatie. Ik heb eens een geavanceerd testmetriekendashboard ontwikkeld voor een grote testorganisatie bij een bank. Deze organisatie gebruikte al testmetrieken, maar deze waren te eenvoudig en ontoereikend in relatie tot de complexiteit voor het programma. Nadat het dashboard was ontwikkeld, getest en uitgerold bleek de organisatie maar moeilijk in staat om de geavanceerde metrieken te vertalen naar effectieve acties die het testproces moesten bijsturen. Naast een probleem met de testmetrieken bleek dat de organisatie dus ook hulp nodig had bij het trainen van alle betrokkenen in het interpreteren van de testresultaten. Nadat een trainingsprogramma was opgesteld met de juiste rollen en verantwoordelijkheden werd de organisatie steeds beter in het vertalen van de testmetrieken naar concrete acties die het testproces konden controleren en verbeteren.

Het is dus uitermate belangrijk dat de noodzaak van een testtrainingsprogramma wordt onderkend. Een effectief testtrainingprogramma houdt onder andere in dat de noodzaak tot testtraining vooraf wordt onderkend en dat deze wordt gepland, relevante testtechnieken worden behandeld en dat het materiaal, de trainers en de trainees worden geëvalueerd zodat het trainingsprogramma continu kan worden bijgestuurd.

Wat is een volwassen teststrategie?

Een volwassen teststrategie is direct van invloed op de volwassenheid van het testproces en bepaalt daarmee dus ook de volwassenheid van het gehele systeemontwikkelproces. Zoals beschreven in het eerste artikel van deze reeks kunnen projecten hierdoor geavanceerde informatiesystemen voorspelbaar opleveren waardoor bedrijven beter en sneller kunnen inspringen op veranderingen in de markt. Het resultaat: langdurig concurrentievoordeel.

Hoe creëer je nu een volwassen teststrategie? De eerder genoemde professor in dit artikel, Henry Mintzberg, is van mening dat een strategie niet zomaar op papier wordt gezet, waarna iedereen deze gaat uitvoeren. Het ontwikkelen van een strategie is een proces dat tijd kost. Het is tevens iets wat een organisatie gaat ontdekken en iets wat wordt bijgestuurd aan de hand van de ervaring die de organisatie opdoet tijdens het verbeteren van de processen, technologie en de organisatie zelf. Juist hiervoor is het Test Assessment Framework ontwikkeld. TAF geeft de testgebieden aan die horen bij een teststrategie. Het geeft inzicht in de huidige volwassenheid van deze testgebieden volgens de volwassenheidsniveaus van het Testing Maturity Model (TMM). Om vervolgens een volgend testvolwassenheidsniveau van de teststrategie te bereiken, geeft het de onderdelen aan van de testgebieden die kunnen worden verbeterd.

De algemene TMM-volwassenheidsniveaus geven een goede indruk waar een testorganisatie zich bevindt vanuit een teststrategisch oogpunt:

- Niveau 1 - er is geen teststrategie.
- Niveau 2 - een teststrategie wordt zo nu en dan ontwikkeld op projectniveau.
- Niveau 3 - de teststrategie wordt ondersteund, onderhouden en gevolgd door een centrale testorganisatie op alle projecten. De teststrategie is volledig geïntegreerd in de systeemontwikkelmethodologie.
- Niveau 4 - volgens de teststrategie worden alle systeemgerelateerde software en documentatie, requirements, technisch/functioneel ontwerp, testplannen, testscripts, etc. geëvalueerd met behulp van vooraf gedefinieerde kwaliteitscriteria. Geavanceerde testmetrieken worden continu toegepast en onderhouden om het testproces te controleren en bij te sturen.
- Niveau 5 - de teststrategie en dus de gehele testorganisatie wordt continu verbeterd, ondersteund door processen als oorzaakanalyse (Engels: ‘root cause analysis') van defects, algehele procesverbetering en geavanceerde testautomatiseringstechnieken, onder andere via statistische testtechnieken.

Volgende artikelen

De doelstelling van dit artikel was om indruk te geven van het belang van een goede teststrategie. De eerste drie beschreven TAF-testgebieden (testmethodologie, testomgeving en tools en testorganisatie en communicatie) geven vorm aan de teststrategie en het eerste TAF-testdomein met dezelfde naam. Het definiëren van de juiste teststrategie is een proces dat continu zal moeten worden gemeten en bijgesteld. TAF ondersteunt de organisatie zowel bij het identificeren als het verbeteren van een volwassen teststrategie.

In het volgende artikel zal ik ingaan op de drie testgebieden die horen bij het volgende testdomein: de testlevenscyclus. De testlevenscyclus is een direct gevolg van de teststrategie: als de teststrategie het ‘wat' beschrijft, geeft de test levenscyclus aan ‘hoe' het allemaal gaat gebeuren. In het daaropvolgende artikel zullen de verschillende testdisciplines die tijdens het testen een sleutelrol spelen aan bod komen. In het laatste artikel zal ik ingaan op een onderzoek dat enige tijd geleden is ingesteld naar de voordelen van testcentralisatie en de verbetering van testvolwassenheid. In dit onderzoek komen interessante feiten naar voren die onderschrijven dat langdurig concurrentievoordeel voor bedrijven en instellingen daadwerkelijk wordt ondersteund door het verbeteren van testvolwassenheid.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/3317449). © Jaarbeurs IT Media.

?


Lees meer over



Lees ook


 

Reacties

Prima verhaal. Volledig en juist, maar wat is er uniek en/of nieuw aan? Volgens mij is het allemaal al eens eerder beschreven....

Na lezen van het artikel bekruipen me twee gevoelens. Ten eerste is het allemaal waar wat er staat mar dit weten we toch allemaal al en veel organisaties doen het toch al? Het klopt wel, de auteur heeft duidelijk kennis van testen maar wat is de nieuwswaarde.
Ten tweede bekruipt me enige teleurstelling. Het maken van TAF lijkt een op zichzelfstaand initiatief van een leverancier. Vaak blijft de toepassing dan ook beperkt tot een paar klanten van die leverancier. En dat in een tijd dat er juist allerlei organisatieoverschrijdende initiatieven zijn! Dit is (in grote lijnen) vergelijkbaar met TMMi (de opvolger van TMM), wat voor 60% af is en de laatste 40% wordt hard aan gewerkt. Daarnaast voldoet TAF niet aan ISTQB, de internationale teststandaard. Daardoor staat TAF buiten de algemene ontwikkelingen, terwijl de werkgever van de schrijver wel heel acief bijdraagt aan TMMi. Mag ik de auteur uitdagen bij te dragen aan de internationale ontwikkeling ipv zijn eigen model te ontwikkelen?

Beste Henk Fliek,

Ik vind het een heel erg sterk artikel en nodigt echt uit om het volgende deel ook te gaan lezen.

Het belang van een goede teststrategie wordt puntsgewijs zeer goed uitgelegd. De drie TAF gebieden fungeren inderdaad als basis.

Persoonlijk ben ik van mening dat bepaalde 'typen testers' het beter doen in de omgevingen die bij hun past. (sommige projecten zijn meer feitelijk gericht en andere weer agile, zo doen bepaalde testers het op bepaalde omgevingen beter of minder goed inherent daaraan).

Ik denk dat het ook zo is met de bedrijven en de gebieden. Voor sommige bedrijven is het beter de focus te leggen op gebied TAF1 en voor anderen juist weer op gebied TAF2.

Als je als bedrijf het voor jou belangrijkste gebied snel kunt bepalen kun je denk ik grote sprongen maken in de ontwikkeling van je teststrategie.

(En misschien vallen hier wel feiten over naar boven te halen door marktonderzoek.)

Succes met de volgende delen!

Een goed artikel.
Toch mis ik in de Strategie een cruciaal onderdeel: een analyse van de (bedrijfs-)risico's, op basis waarvan de testinspanning efficienter gemaakt kan worden.
We weten allemaal dat we niet alles kunnen testen, en het elementaire doel van testen is niet "kijken of de software werkt" maar "kijken of mijn bedrijfsprocessen geen gevaar lopen".

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×