Waarom het testen van software beter moet

Image

Door: Ed Hilkman

In de ruim 20 jaar dat ik actief ben in het testvak heb ik ervaren dat met name het regressietesten van software – zowel handmatig als geautomatiseerd – een tijdrovende aangelegenheid is met onvoldoende garanties op een goed werkend systeem.

De oorzaak hiervan ligt mijns inziens in de wijze waarop testgevallen tot stand komen. Dit introduceert vervelende en tijdrovende bottlenecks die vanuit het ‘klassieke’ testperspectief moeilijk zijn op te lossen. Dit drijft mij om alternatieve testmethodes en -tooling te onderzoeken.

Mijn meest recente onderzoek spitst zich toe op het efficiënter testen van procesgestuurde front-end applicaties waarvan ik de resultaten in een aantal blogs toelicht. Het eerste blog in deze reeks gaat in op de bottlenecks die ik in de praktijk ervaar met regressietesten.

Bottleneck #1. Testsnelheid neemt af

Tegenwoordig wordt software over het algemeen agile ontwikkeld. In sprints van enkele weken bouwt en test een Scrum team functionaliteit. Een sprint kent grosso modo twee functionele tests: een systeemtest om de werking van de nieuwe en gewijzigde functionaliteiten te testen en een regressietest waarmee de tester vaststelt of de ongewijzigde functionaliteiten nog correct werken. Aan het einde van de sprint worden de systeemtestgevallen (al dan niet een subset) toegevoegd aan de regressietestset. Het aantal regressietestgevallen neemt dus per sprint toe en daarmee ook de benodigde testtijd. Gevolg is dat testers na enkele sprints onvoldoende tijd hebben om te testen. Testen wordt dan een hobbel in het proces.

Bottleneck #2. Niet overdraagbaar, niet onderhoudbaar, onvoldoende dekking

In een willekeurige verzameling testgevallen zitten onderling weinig verschillen. Daar is een goede verklaring voor. Een tester wil het gedrag van een applicatie zien als er één variabele verandert. Een testset is dus vooral redundant, met enkele verschillen. Dat maakt een testset lastig onderhoudbaar (zoek de verschillen). Dit wordt nog eens versterkt doordat de tester de vertaling van requirements en specificaties naar testgevallen zelden vastlegt (de uitwerking van een testtechniek, welke aspecten worden gecombineerd in een testgeval etc). De oorzaak hiervan is vaak tijdgebrek. Het uitvoeren van een test wint het nagenoeg altijd van het bijhouden van een goede administratie.

Dit heeft een aantal gevolgen:

  • Door het ontbreken van die vertaling en de eerder genoemde redundantie is een testset dus vrijwel niet overdraagbaar. Sterker nog, na enkele weken kan een tester nauwelijks zelf zijn eigen werk fatsoenlijk onderhouden;
  • Zonder goede administratie kan nimmer onderbouwd inzicht worden gegeven in de dekking (requirements) en dekkingsgraad (specificaties) van een test. Op basis van mijn ervaring durf ik te stellen dat regressietests nimmer meer dan 40% van de risico’s afdekken. En dat is bovendien een optimistische inschatting! Als productverantwoordelijke voor een primaire applicatie, zou ik een dergelijke beperkte dekking niet acceptabel vinden!
  • Aan het einde van een sprint weet de tester welke testgevallen fouten aan het licht hebben gebracht, maar niet aan welke requirements wordt voldaan. En het probleem wordt nog erger als requirements wijzigen. Welke testgevallen moeten dan worden bijgewerkt?
Bottleneck #3. Pesticide paradox

Agrariërs beschermen hun landbouwgewassen tegen insecten met pesticiden, waardoor de insectenpopulatie sterk wordt uitgedund. Het deel van de populatie dat overleeft bouwt een zekere resistentie op tegen een bepaalde pesticide, waardoor de effectiviteit bij elk volgend gebruik hiervan afneemt. Deze paradox is ook van toepassing op regressietests. Eenmaal uitgevoerd levert een regressietest in elke volgende run steeds minder nieuwe bevindingen op. Binnen de landbouw valt dit op te lossen door telkens de pesticide formule iets te wijzigen. Voor een tester betekent dit het aanpassen en uitvoeren van onderhoud op de regressietest, wat een lastige en tijdrovende bezigheid is.

Conclusie

Op basis van voorgaande kom ik tot de conclusie dat we in de praktijk testsets bouwen die nauwelijks onderhoudbaar en vrijwel niet overdraagbaar zijn, onvoldoende dekking bieden en de testsnelheid doen afnemen.

Kortom het (regressie)testen van software moet dus beter! In mijn volgende blog licht ik daarom een aanpak toe waarmee dit mogelijk is.

Delen:

Ed Hilkman

Ed Hilkman is Test Consultant met ruim 20 jaar ervaring in het testen van software. Hij is gespecialiseerd in testautomatisering en technisch testen en doet veel onderzoek naar nieuwe testtechnieken.
Bekijk de LinkedIn pagina van Ed Hilkman