Development

Software-ontwikkeling
Andy Zaidman

De afkeer van testen komt onder de loep

Analyse testgedrag maakt effecten bespreekbaar.

Andy Zaidman © Marike van Pagée
10 oktober 2022

Analyse testgedrag maakt effecten bespreekbaar.

Waarom besluit een ontwikkelaar software te testen of dat niet te doen? Het antwoord op die vraag is een complex samenspel van sociologische en technische processen, en de beschikbaarheid van techniek. Andy Zaidman zoekt met zijn team naar de afwegingen die rondom testen worden gemaakt. Softwareontwikkelaars moeten ook meer inzicht krijgen in die afwegingen met behulp van tools.

'Burden' is een woord dat vaak terugkwam in een groot onderzoek naar hoe software-ontwikkelaars aankijken tegen software testen. Mensen vinden het lastig en complex, zo blijkt, en er zijn veel meer negatieve dan positieve sentimenten rond testen in discussies op platformen als Stackoverflow en Reddit. Toch is testen een heel belangrijk onderdeel van softwareontwikkeling om bugs op te sporen en goede en betrouwbare producten op te leveren. Waarom lukt het een automerk wel om de techniek van een nieuw model vrijwel foutloos op de markt te brengen, maar bevat software eigenlijk altijd veel fouten, die vaak pas na verloop van tijd tot uiting komen?

De sociotechnische aspecten van die vraag waren voor Andy Zaidman, hoogleraar software engineering aan de TU Delft, de reden een onderzoeksvoorstel te schrijven dat in 2019 werd beloond met een Vici-beurs. Hij richt zich op testen die ontwikkelaars zelf schrijven en uitvoeren, dus niet het werk van gespecialiseerde testers.

Verleden

Het onderzoek bouwt voort op eerder werk dat Zaidman in het kader van een Vidi-beurs sinds 2013 deed. Dat toonde al onder meer aan dat softwareontwikkelaars een heel verkeerd beeld hebben over de tijd die ze besteden aan testen.  Van de ruim 2400 deelnemers aan dat onderzoek, bleek maar liefst de helft gedurende drie tot vijf maanden geen enkele test te hebben geschreven en geen enkele test te hebben uitgevoerd. En dat terwijl ze wisten dat ze meededen aan een onderzoek naar testdisciplines.

De andere helft dacht gemiddeld 49% van de tijd bezig te zijn met het schrijven en uitvoeren van tests. In praktijk was dat gemiddeld echter maar 27%, zo bleek uit geautomatiseerde metingen over een periode van drie tot vijf maanden. "Dus maar bijna de helft van hun eigen inschattingen", zegt Zaidman.

Op zoek naar de oorzaak van dat enorme verschil tussen perceptie en realiteit, gaven verschillende psychologen - waar het team van Zaidman mee samenwerkt aan dat - als verklaring dat klusjes die mensen vervelend vinden, voor hun gevoel veel langer duren. En veel ontwikkelaars vinden testen geen leuk onderdeel van hun werk.

Maar waarom vinden ontwikkelaars testen zo vervelend? "Het onderzoek is nog maar net gestart. Mijn uitgangspunt is dat er heel veel goede testers zitten onder de ontwikkelaars. Maar software ontwikkelen is een creatieve bezigheid en testen is eigenlijk een destructieve activiteit." Het is een van de hypothesen die Zaidman duidelijk wil krijgen. Het onderzoek moet uiteindelijk uitmonden in tools waarmee organisaties inzicht kunnen krijgen hoe hiermee - en met andere overwegingen - intern wordt omgegaan zodat ze daar iets aan kunnen doen.

Heden

Het onderzoek op de discussiefora van Stackoverflow en Reddit was een van de eerste stappen van dit meerjarig onderzoeksprogramma. Met Natural Language Processing (NLP)-technieken werden de teksten die in de discussiefora staan, geanalyseerd en daaruit werden sentimenten gehaald. In een volgende stap  - die over een of twee maanden begint - gaan de onderzoekers naar bedrijven toe om te inventariseren welke discussies binnen een team of binnen een organisatie gevoerd worden over testen. "Waarom zeggen mensen 'We moeten inzetten op meer testen' en waarom zeggen anderen 'We moeten minder inzetten op testen, want we hebben al veel andere dingen op ons bord'?"

Daarnaast kijkt het team ook of het mogelijk is het gedrag van teams te veranderen op basis van concrete data. "Dat ontwikkelaars veel minder tijd besteden aan testen dan ze eigenlijk dachten, komt omdat niemand ze vertelt hoeveel aandacht ze daadwerkelijk geven aan de verschillende activiteiten. We willen daarom - en ik plak er nu maar een titel op - met quality assurance analytics die activiteiten in kaart brengen. En vervolgens kijken of we daarmee ook mensen kunnen beïnvloeden." Stel team A besteedt 20% van de tijd aan quality assurance en team B 30%. Maar het werk van team B bevat wel de helft minder bugs. Gaat team A op basis van dat inzicht de werkwijze veranderen?

Zaidman wil dat analyseproces automatiseren en de teams op de hoogte houden via dashboards of periodieke mailings. Ze kunnen dan zelf zien hoeveel tijd er in testen is gestoken, hoeveel bugs zijn gerapporteerd en hoe het team zich verhoudt tot anderen teams in de organisatie.

Er zitten wel wat uitdagingen in het onderzoek, realiseert Zaidman zich. De belangrijkste is wel organisaties overtuigen om mee te doen. "Het is een heel gevoelig onderwerp. Mensen praten niet graag over testen, want het zegt iets over hoeveel fouten ze maken tijdens het programmeren. Vaak test je ook software van een teamgenoot en vind je zijn of haar fouten. Dat is een ongemakkelijke waarheid."

Verder zijn bedrijven huiverig om hun naam te verbinden aan zo'n onderzoek omdat wellicht duidelijk wordt dat ze minder aan testen doen dan een ander. "Ik werk met het hele scala aan bedrijven. In zijn algemeenheid zie ik vanuit mijn positie - en dat is een makkelijke positie - dat veel bedrijven heel goede software leveren maar dat het bij veel bedrijven beter kan, in de brede zin."

Het is ook een lastig onderwerp omdat er altijd sprake is van een trade-off. Software zonder bugs bestaat niet, stelt Zaidman. Misschien met de inzet van formele methoden, maar dat is erg tijdrovend en duur. "Dus hoe ver wil je gaan met testen en wanneer druk je op de knop 'Ship'?" En anders dan in de auto-industrie, waar een bug in de airbag tot heel kostbare terugroepacties leidt, kan een software-update in korte tijd naar alle gebruikers worden gepusht als er een bug moet worden opgelost.

Dat zorgt ook voor druk vanuit het management op de testactiviteiten. Er is met de klant een releasedatum afgesproken, maar er moet nog worden getest. Dat schuift dan makkelijk door naar de volgende release.  "De vraag is dus of het management voldoende tijd en ruimte geeft om te testen of is het een soort 'after thought'."

Toekomst

"We zoeken een heleboel theoretische zaken uit. Maar we proberen die inzichten ook uit in de praktijk. We kunnen niet zonder de interactie met de industrie. Google en Meta maken net als wij ook allerlei tools om het proces van software-ontwikkelen beter te maken. Zij leren van ons, wij leren van hen." Het is onderzoek wat geruime tijd in beslag neemt, eerst om inzichten te verwerven en vervolgens om prototypen te maken van tools die wat met die inzichten doen. "Verder denk ik dat het niet goed is, de inzichten alleen op te schrijven in wetenschappelijke papers. We moeten de prototypes ook echt uitbouwen tot een solide stuk software en dat open source maken zodat meer mensen het kunnen gebruiken." Maar echt iets veranderen, lukt alleen als er ook consultancy en een soort 'evangelisatie' plaatsvindt. Dat is meer een taak voor een spin-off. Daarbij ziet Zaidman voor zichzelf geen rol, maar hij hoopt wel dat leden van zijn team zich daarop willen storten.

Een heel nieuw en interessant vakgebied dat zich aandient, is het testen van software waar machine learning in verwerkt is. "In de onderzoekswereld wordt daar veel aandacht aan besteed. Er zijn echter nog geen heel goede allesomvattende aanpakken. Daarop ingaan is echt de uitdaging is voor de komende vijf tot 10 jaar."

Magazine AG Connect

Dit artikel is ook gepubliceerd in het magazine van AG Connect (november 2022). Wil je alle artikelen uit dit nummer lezen, zie dan de inhoudsopgave.

Reactie toevoegen
De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.