Ik loop al aardig wat jaartjes mee in testland en al die tijd zie ik een rode draad. Los van trends, hypes of innovaties. De rode draad is de testtechnieken!
Iedereen praat erover. In elke cursus worden ze gedoceerd. Het bekende rijtje wordt telkens weer gepresenteerd, zoals grenswaarde analyse, beslissingstabellen, procescyclustest, syntactische test en semantische test.
Heel goed zou je denken, alleen er zit een adder onder het gras. In de praktijk zie ik nog steeds dat testtechnieken niet of nauwelijks worden toegepast. Ik vind dat erg jammer want we praten altijd over dekkingsgraad. Om de dekkingsgraad aan te tonen is het structureel toepassen van testtechnieken een uitstekend hulpmiddel.
De vraag is natuurlijk; hoe komt het nu dat testtechnieken zo mondjesmaat worden toegepast? Ik heb daar geen sluitende verklaring voor. Uiteraard kan ik wel een aantal redenen bedenken.
De noodzaak van het toepassen van testtechnieken wordt niet altijd onderkend. In de teststrategie wordt wel aangegeven dat bepaalde testtechnieken toegepast moeten worden, maar in de uitwerking schort het er nogal eens aan.
Impliciet gebruik is een andere oorzaak. In het ontwerp van de testgevallen wordt bijv. wel met grenswaarde rekening gehouden maar traceerbaar is het niet.
In veel projecten wordt het gebruik van testtechnieken niet echt afgedwongen. We lezen een usecase, bedenken welke testgevallen mogelijk cq noodzakelijk zijn en werken dit uit. Er vindt geen audit plaats op de testgevallen en zeker niet of de afgesproken dekkingsgraad is ingevuld. Dit kun je aantonen door het gestructureerd toepassen van testtechnieken.
Tot zover een aantal mogelijke verklaringen. Waarom is het gebruik van testtechnieken dan wel belangrijk?
Veel systemen ondersteunen de kernprocessen binnen een organisatie. De organisatie is afhankelijk van de IT en moet volledig op de systemen kunnen vertrouwen. Berekeningen moet juist zijn. Processen moeten van begin tot het eind probleemloos doorlopen kunnen worden. Hoe garandeer je dat? Juist! Door de toepassing van de juiste testtechnieken op het juiste moment. Met het gebruik van testtechnieken breng je de benodigde testsituaties in kaart en garandeer je over de gehele keten heen de afgesproken kwaliteit.
Vooral in de zogenaamde mission critical systemen is een correcte kwaliteit van eminent belang.
Kortom, testtechnieken moeten bij alle testsoorten en testtypen een prominente plaats hebben en aanwezig zijn in de gereedschapskist van iedere tester. Zonder roest of stof maar in blinkende staat. Aan ons als testers de uitdaging om daadwerkelijk ons gereedschap te gebruiken.
Laten we over 1 jaar eens kijken hoe we er voor staan!
——————————————————————————–
Jos van Rooyen is senior testadviseur/ principal consultant testen bij Bartosz ICT bv
De vraag is natuurlijk; hoe komt het nu dat testtechnieken zo mondjesmaat worden toegepast?
Volgens mij komt het vaak doordat ontwerpen te vaak ontbreken, of te beperkt zijn. Hoe kan ik een beslistabel gebruiken, als het ontwerp niet alle situaties beschrijft. Hoe kan ik grenswaardeanalyses uitvoeren als de grenswaarden niet eens beschreven worden. Of performance criteria niet bekend zijn?
Ik kan mij voorstellen dat een tester in zijn testleven hierdoor weinig kansen krijgt om zijn testtechnieken te gebruiken/oefenen, waardoor het ook lastig wordt om zo’n techniek aan te passen voor specifieke situaties, zoals een ontwerp in concept vorm of wel heel erg ‘free format’ opgesteld.
Zoals je wel eerder hebt beschreven, begint het bij een goed ontwerp. Kwaliteit attribuut testbaarheid: kan ik de juiste testtechnieken gebruiken bij dit ontwerp? Wat je dan niet leert op zo’n testcursus is hoe een goed ontwerp er uit moet zien voor het kunnen gebruiken van een testtechniek, zodat de tester goede input kan leveren aan de ontwerper.
Jos,
Helemaal mee eens. Waarom “we” ze niet gebruiken? Dat heeft meerdere oorzaken denk ik: veel testers weten niet hoe ze effectief toe te passen. Simpelweg omdat ze het te moeilijk vinden. Het kost namelijk tijd om ze te leren en testmanagers sturen er niet op (omdat ze zelf het ook niet echt snappen?). Bovendien denk ik dat het vrij moeilijk is uit te leggen aan onze klanten. Tenslotte is het niet eenvoudig om de jusite testtechniek te kiezen. Dat wordt ook niet getraind omdat het situationeel afhankelijk is.
En de tijdsdruk maakt dat we al snel terugvallen naar testen op gevoel, helaas. Testtechnieken toepassen kost schijnbaar veel tijd, terwijl ik denk dat het juist tijd bespaard.
Ik herinner me een project waarbij de testers de EVT gingen toepassen. De eerste uitwerking kostte meer dan hele dag met review erbij misschien wel 2 dagen, de tweede nog maar een dag, etc. Na een week kostte het nog slecht een paar uurtjes om de testcases op te stellen. In hetzelfde project hebben we veel meer testtechnieken toegepast: met name ook state transition testing. Iets wat de testers wel geleerd hadden in de ISTQB training maar eigenlijk niet of nauwelijks onder de knie hadden.
Kortom: trainen, trainen, trainen! Niet alleen in een cursus, maar zeker ook in projecten! En ja, de testmanager mag ook wel eens naar een opfriscrusus!
Sturing op dekkingsgraad klinkt mooi in theorie, maar hoe ga je zoiets toepassen in de praktijk? Voor unit testen is dat perfect te doen met behulp van code coverage tools, maar eens je het functionele pad opgaat, kan er nog enkel gestuurd worden op functionele requirements. Dat is natuurlijk beter dan niets, maar op zich zegt dit ook vrij weinig. Je kan immers 100% functionele requirements testen en misschien toch maar 20% van het te testen systeem raken.
In die optiek is het beter om het principe van risk based testing toe te passen door meer tijd en geld te steken in de systeemonderdelen die kritisch zijn en de minder belangrijke delen te voorzien met minder formele technieken. Zo kan je beslissingstabellen en EVT toepassen voor de bedrijfskritische processen en dit eventueel aanvullen met exploratory testing of error guessing. De processen met een normale belangrijkheid kan je dan testen met bijvoorbeeld equivalentieklassen.