Auteur: Maurice Siteur ● maurice.siteur@capgemini.com
Op 6 november werd alweer de 26e Nederlandse Testdag gehouden, een initiatief van de academische wereld en de testindustrie om met elkaar ideeën uit te wisselen. Dit keer vond het evenement bij de TU in Delft plaats.
Er was een veelheid aan sprekers waardoor er genoeg te kiezen viel. Mijn focus was dit keer op de academische sprekers en gelukkig waren er deze keer geen formules. Toch moest ik zo af en toe wel even goed nadenken over wat ik hoorde en hoe ik dat in de praktijk moest zien. In dit artikel belicht ik een paar onderwerpen die tot mijn verbeelding spraken.
Mutation testing
Nogal wat sprekers spraken over ‘mutation testing’. Voor wie de ISTQB-woordenlijst heeft doorgenomen, zal deze term bekend voorkomen. Het komt erop neer om bewust fouten te introduceren in de code en dan te kijken of de test(software) de fouten vindt. Het toetsen van de kwaliteit van de tests dus. De toepasbaarheid ervan werd vergeleken met drie typen organisaties en ook drie typen medewerkers. Van kleinschalig-1 project tot de grote bedrijven (denk aan Amazon). Het blijkt dat je mutation testing het beste op unit/component niveau kunt toepassen, waarbij BC (branche coverage) al gehaald moet zijn. Dat laatste is wel een punt waar veel bedrijven niet aan voldoen. Het zegt dat de test eerst een goed niveau gehaald moet hebben. Mutation testing toont anders aan dat je BC nog moet halen.
Er zijn ook tools die de drempel om mutation testing toe te passen, lager maken. Laat maar gewoon zien dat de tests niet compleet zijn. Het management gaat dan mogelijk wel in beweging komen. No news is good news, immers. Dit kan met een tool voor een hele applicatie worden aangetoond en dat is slecht nieuws. En dan nog moet er een behoefte zijn – gewoon betere code levert niks op, althans niet iets waar je meteen veel geld mee gaat verdienen. Mutation testing past dan ook goed in de test automation pyramid, waarbij de focus op laag in de piramide is. Laag betekent een focus op unit testing.
De vraag is of mutation testing een type tool of een type test is. Voor mij is het een type test. Er zijn vele toepassingen die onder mutation testing vallen, zoals het genereren van variaties voor code, omgevingen tot meer analyse-achtige tools. Ook hier is het dus belangrijk om te bepalen wat je precies wilt, voordat je een tool gaat zoeken.
Amplification
Dit komt uit het STAMP-project. In dit project wordt geprobeerd om op basis van foutmeldingen of dumps te herleiden hoe deze fout is ontstaan. Iets wat een tester vaak zwaar valt. Je hebt een bevinding, maar probeer die maar eens te reproduceren. Het is geen AI (artificial intelligence), maar het gaat wel die kant op. En er zijn al diverse tools op de markt, die richting AI gaan, ook open source. Het installeren van tools in het algemeen is lastig, omdat je vaak geen admin rechten hebt. Ontwikkelaars hebben die vaak wel en dus moet de tester als volwaardig ontwikkelaar gezien worden. Op die manier kan ook de tester (simpele) tools uitproberen.
Hoe waardevol zijn mijn testgevallen?
We zijn allemaal wel benieuwd naar hoe effectief we nu eigenlijk zijn met testen. Testontwerptechnieken helpen daarbij, maar heel goed zijn we niet in het toepassen daarvan. Het kan ook iets anders aangepakt worden. Door middel van het scoren van de punten waarop je test. Denk dan aan velden, business rules, database acties enzovoort. Vervolgens kijk je per testgeval welke punten geraakt worden. De testgevallen met de meeste punten zijn de testgevallen met de meeste waarde. Op deze manier geef je risk based testen meer inhoud. Wanneer zou ik dit toepassen? Als ik naar minder testgevallen wil.
De basis van dit verhaal lag in de gametheorie. Wat is de optimale strategie om te winnen? En als tester zou je graag elk deel van het proces willen manipuleren zodat je de veranderingen in gedrag makkelijker kunt identificeren.
Story telling
Aan de hand van de Harry Potter cyclus werd uitgelegd wat we als testers aan story telling hebben. Hoe ziet een verhaal eruit en wie vertelt wat? Zo heeft een verhaal een story line met een reeks gebeurtenissen. De eerste keer lezen we voor de plot van een boek. Pas bij de tweede keer beginnen details op te vallen en dus de verbanden. Op basis van een haarfijne analyse kregen we een andere blik op Harry Potter. Zonder Hermelien had Harry Potter boek 7 nooit gehaald. Bepaalde gebeurtenissen komen pas in latere boeken en dat heeft een doel, maar beseffen we dat ook altijd?
Dit verhaal past goed bij het geaccepteerde gedachtegoed dat je niet te snel een mening moet hebben. Bekijk het ook eens van de andere kant. Afwijkend is niet altijd fout. Een leuke statement vond ik: lezers zoeken patronen en testers denken in anti-patterns.
Al met al een goed congres en ik kijk al uit naar volgend jaar waarvoor we zoeken nog een organisator zoeken.
NieuwsMagazine