Auteur: Kees Blokland ● kees.blokland@polteq.com
Er bestaan verschillende manieren om het testen op te delen. Zo kennen we de indeling in testsoorten (test levels). Iedere testsoort heeft een bestaansreden, vaak gekoppeld aan een bepaald testdoel. Zo zijn vaak voorkomende testsoorten ontstaan, zoals de systeemtest, de FAT en de ketentest. Het toepassen van herkenbare testsoorten schept helderheid in een organisatie. Maar hoe houden we in de gaten of een testsoort nog goed op zijn plaats zit en voldoende bijdraagt aan de teststrategie?
Defect removal efficiency
Sommige organisaties meten hoeveel bugs iedere testsoort vindt en doorlaat. Hoe gunstiger die verhouding, hoe beter de testsoort is in het ‘verwijderen’ van bugs uit het systeem. Als de FAT een hogere score heeft dan de systeemtest, dan zou dat kunnen betekenen dat de FAT beter zijn werk doet. Zelf vind ik het veel interessanter te kijken naar wat voor defects je vindt in een testsoort:
– Vinden we defects die een eerdere test ook (makkelijker?) had kunnen detecteren?
– Vindt men later defects die wij ook (makkelijker?) hadden kunnen vinden?
– Vinden we defects die goed passen bij de tests die we doen?
Testgevallen
Een testsoort die veel tests heeft, lijkt een goede dekking te geven. Een pluspunt zou je zeggen. De vraag is echter: waarom zijn zoveel tests nodig? Is dat soms omdat er weinig vertrouwen is in de testdekking van andere testsoorten, zoals de unit-test? Een test doen we omdat we daarmee een risico willen afdekken en daarvoor moeten we ons afvragen wat de beste plaats is om dat te doen. Voorbeeld: unittests zijn klein, snel en in staat concrete functionele risico’s af te dekken, maar weer beperkt in het vinden van moeilijk vindbare, dieperliggende problemen die pas boven water komen als subsystemen interactie hebben.
Round Earth heuristic of Test Strategy (James Bach)
Warm aanbevolen: de presentatie van James Bach met de titel ‘My Problem With the Pyramid’. Het biedt een uitstekende kapstok om de vraag ‘Wat is de effectiviteit van een testsoort?’ vanuit verschillende kanten te belichten. Veel leesplezier!
My problem with the Pyramid
NieuwsMagazine
Ik kan wel huilen.
Dat Bach en co de piramide omdraaien om er een andere twist aan te geven is perfect. Maar de tekst die ze erbij zetten zegt exact hetzelfde als dat wat ze afkraken. De ET saus voegen ze toe. Ik stel voor om er dan een rechthoek van te maken.
ijzersterk artikel Kees! ik zou een aanvulling willen doen:
dit artikel past er goed bij: https://www.stickyminds.com/article/shift-left-approach-software-testing?utm_source=twitter&utm_medium=social&utm_campaign=mk-shift-left-approach-software-testing
“Dus de combinatie gedachte is dan:”
Als FAT testen 10x is, en FAT testen worden minder bugs gevonden dan Systeem test, wat is dan wijsheid?
In mijn ervaring / omgeving zie ik eigenlijk nauwelijks meer de traditionele opdeling in testsoorten. FAT? PAT? UAT? De afgelopen 5-10 jaar niet benoemd / gekaderd.
Dit is natuurlijk sterk gerelateerd aan de omgeving waarin je werkt; als je in-house software development doet voor interne tools, is een UAT organiseren zinniger zijn dan wanneer je een publieke website / webapp wereldwijd beschikbaar maakt met een simpele druk op de knop voor je cloud deployment.
Wat ik wel heel sterk vind aan het verhaal van James is het benoemen van de datastromen in relatie tot de lagen van het systeem. Hierdoor wordt heel duidelijk dat niet alle type issues gevonden kunnen worden met bv. unit tests. Dat geeft ook het probleem in het ‘shift left’-idee aan; er is een limiet in hoever bepaalde issues “naar links kunnen” wat betreft detectie. Een probleem met data-afhankelijkheden is niet met unit testen te ondervangen. Meer unit testen schrijven is dan ook zinloos als in een systeem veel problemen met data-relaties worden gevonden.
Ook het benoemen van OS en frameworks is een goede toevoeging. Die worden vaak niet getest, ze worden ‘for granted’ genomen. Maar dat is vaak niet terecht. Borging op OS- of frameworkfunctionaliteit die ‘naar boven toe’ cruciaal is, is helemaal geen slecht idee. Meerdere keren meegemaakt dat een wijziging in OS of framework problemen gaf met datatime gerelateerde code.
Verder is inderdaad het kijken naar wat voor soort fouten er op een bepaald moment gevonden wordt vele malen belangrijker dan het aantal (en de onderlinge relatieve aantallen binnen de testsoorten). Aantal bugs is altijd al een beroerde metric geweest…zijn 10 UI issues erger dan potentieel datacorruptie in een database? Wat als je een belangrijke betalende klant kan verliezen op die UI issues en de datacorruptie alleen kan optreden bij niet betalende gebruikers? Etc.