Softwaretests zijn niet afdoende. Dat zegt hoogleraar Jan Friso Groote van Technische Universiteit Eindhoven. Hij leidt daar de faculteit Systeemontwerp en is gespecialiseerd in de softwareveiligheid van ingebedde systemen. 'Als iemand zegt: de software is door en door getest, dan moet je in de lach schieten. Want dat kan niet.'
'Door software te testen, zul je nooit alle mogelijke fouten kunnen ontdekken.' De hoogleraar rekent voor dat het onmogelijk is de software onder alle mogelijke omstandigheden te testen. 'Stel je een systeem voor met twintig sensoren, die elk twee mogelijke waarden kunnen aannemen. Dan is het aantal mogelijke situaties gelijk aan 2 tot de twintigste macht. Dat zijn ruim een miljoen mogelijke situaties.'
Softwareverificatie
Volgens de hoogleraar kan software het best worden getest door het geautomatiseerd analyseren van een vereenvoudigde model van de software.
Daarnaast is het belangrijk dat aan universiteiten ontwikkelde softwareverificatiesystemen gemakkelijker toepasbaar worden in de praktijk. 'Technisch gezien is het al lang mogelijk om foutloze software te maken, via prototype verificatiesystemen zoals Coq en PVS. Die technieken bestaan al in een algemene vorm. Maar er ligt een innovatiegat tussen de universiteiten die deze technieken ontwikkelen en de ontwikkelaars die ermee in de praktijk moeten werken. Daardoor zijn er nog geen praktisch inzetbare tools.'
Die komen er ook waarschijnlijk niet snel, zo vreest Groote. 'Het probleem is dat zowel universiteiten als bedrijven de mankracht niet hebben om praktische verificatietools te ontwerpen. Wetenschappers hebben niet het budget om tientallen manjaren te bouwen aan dat soort tools. En de onderzoeklabs binnen grote bedrijven zijn bijna allemaal weggesaneerd.'
Software-eisen
Daarnaast zijn goede softwarespecificaties essentieel bij het voorkomen van programmeerfouten: 'Wat wil je dat de software wel doet, en wat juist niet?'
'Softwarespecificaties zijn vaak vaag, inconsistent en ze bevatten fouten. Een voorbeeld van een vage omschrijving is: de software moet gebruiksvriendelijk zijn. Daaruit kan een programmeur niet opmaken of hij een bepaald edit-veldje wel of niet moet aanmaken, hoe competent hij ook is.'
Hierdoor ontstaat volgens Groote 'een cultuur waarin programmeurs systemen bouwen naar eigen inzicht en steeds minder acht slaan op softwarespecificaties. Dat leidt tot een enorme verspilling van programmeerinspanningen en een slechte software-architectuur.'
Hoe inefficiënt die werkwijze is, illustreert Groote aan de hand van een metafoor: 'Stel je de bouw van een huis voor aan de hand van een onduidelijke schets. Stel je voor dat de aannemer desondanks begint met de bouw van het huis. Het gevolg: hak- en breekwerk, omleggen van leidingen, de constructie van extra steunpilaren, Kortom: enorme vertragingen en een gebrekkige architectuur.'
Agile ontwikkeling
Agile ontwikkeling helpt ook niet bij het voorkomen van programmeerfouten, aldus Groote. Bij deze ontwikkelmethode worden tussenversies weliswaar grondig getest, maar de methode staat volgens Groote de bouw van een gedegen software-architectuur in de weg. Opnieuw komt Groote met een huismetafoor om zijn stelling te verduidelijken: 'Het in korte sprintjes ontwerpen van je huisinrichting is prima te doen, maar een heel flatgebouw bij elkaar scrummen is heel andere koek.'
‘Het in korte sprintjes ontwerpen van je huisinrichting is prima te doen, maar een heel flatgebouw bij elkaar scrummen is heel andere koek.’
Hele andere koek, maar niet onmogelijk en er zijn al genoeg succes verhalen. Dat Agile/SCRUM geen wondermiddel is, wisten we al en dat is ook nooit bedoeld. Sommige projecten zijn beter met waterval, andere met een Agile aanpak. Grote of kleine projecten kunnen met beiden, maar je moet wel weten waarom. Bv. Havenbedrijf Rotterdam koos een Agile aanpak omdat ze tegen de tijd dat de software opgeleverd was (in waterval) was het alweer verouderd.
Beste Jan Friso, ik lees tussen de regels meer klachten over de architectuur en betrokkenheid van de Business/opdrachtgever:
‘Wat wil je dat de software wel doet, en wat juist niet?’: Blijven communiceren met de business!
‘maar de methode staat volgens Groote de bouw van een gedegen software-architectuur in de weg.’: Dat is gewoon niet waar. Als betere architectuur vereist is, dan steek je er gewoon meer moeite in.
Maar geef niet de methode de schuld.. It’s always a people issue! Mensen maken keuzes, niet de methode.
@ Jan Friso of interviewer
Agile is geen methode, maar een denkwijze/filosofie
Scrummen is geen werkwoord
Verkracht niet iets waar U geen weet van heeft (zo komt het over). Effectief werken is echt zo slecht nog niet als je verder kijkt dan alleen het woord “Agile” en het gewoon gaat doen.
Kort door de bocht dit verhaal. natuurlijk is er verschrikkelijk veel onbenaul in ICT. Maar net als ieder ander product, auto’s huizen, etc. kan ook software goed gebouwd worden en wel ZEKER zodanig getest worden dat geen fouten optreden. Al jaren geleden zijn er trouwens al methoden ontworpen om te testen of sofware voldoende fouvrij is.
Natuurlijk kan je kinderachtig zijn. Je kan nooit een plank van 1 meter afzagen. Er is altijd wel een foutmarge, bijvoorbeeld 0,0001 mm.
Het beknopte artikel raakt 3 onderwerpen:
1) testen vindt niet alle fouten
2) software specs zijn vaak inconsistent
3) agile is geen wondermiddel
Dat klopt alledrie 🙂
Echter:
Ad 1) met risk based testen haal je het beste uit mens en middelen, dus gegeven de context, opdracht, kwaliteitseisen. Precies wat je in een zakelijke context wil.
Ad 2) Communicatie, communicatie, communicatie! En faciliteer dat, en stuur het team er op.
Ad 3) Scrum richt zich uitsluitend op het aspect Team management: hoe je dagelijks, iteratief en in een release effectief met elkaar samenwerkt. Dat betekent dat relevante aspecten als requirements, architectuur, testen, deployen, non-functionals etc NIET besproken worden.
Maar… waar staat in de Scrum methode dat je met het badwater ook het kind moet weggooien? Niet doen dus! Gewoon je gezonde verstand gebruiken, ook incrementeel aan architectuur doen, soms een beetje voorbereiden en soms een beetje meebuigen met de ontwikkelingen. Het is echt niet zo moeilijk hoor!
@Anko
Dank voor je comment, ik zat er al stiekem op te hopen dat je iets kwam zeggen. Misschien kan je samen hoogleraar Jan Friso Groote van Technische Universiteit Eindhoven bekijken of er een “Open Space” of conferentie gericht op Agile & embedded systemen kan komen.
(Of is die er al geweest en heb je verwijzingen naar artikelen?)
Het vergelijken met het bouwen van een huis blijft de eeuwige vergelijking. Vergelijk het nu is met de noord-zuidlijn het probleem is duidelijk er moet een metro komen. Hoe lang doe je er over, wat kost het en weet je zeker dat het niet in stort?
Heel simpel toch? De aanbesteding pakt te duur uit dus doet de gemeente het zelf wel.
Waarom duurt het dan langer is het veel duurder en stort er hier en daar wat in?
Vergelijk software bouwen niet met een prefab huis waarvan alle factoren al bekend zijn.
Verder blijft het een kosten baten analyse. Op het moment dat de methode van de universiteit makkelijk inzetbaar is en er op deze manier goedkoper is te ontwikkelen komt het vanzelf goed.
Beste Jan Friso,
de problemen die je signaleert zijn duidelijk.
De oplossing is theoretisch en onhaalbaar vanwege geldgebrek. Dus we zijn terug bij af.
Wat kunnen we wel realiseren? Betere software specs met een formele taal/methode?
In de praktijk probeert men zijn best te doen met communicatie en realiseren dat het mensenwerk is. Maar daar krijgen we geen foutloze systemen mee.
Mijn ervaring is dat het eindprodukt de beste score krijgt als de specs het helderst zijn en mijn advies is dan ook voor degenen die zo min mogelijk fouten (financiele en softwarematige) wil: werk aan je specs!
Afgezien van de praktische onmogelijkheid om ‘alles’ te kunnen testen is het ook niet de juiste denkrichting. Het ‘er in testen van de kwaliteit’ van software is een dure methode (geldt trouwens even goed voor verificatie, want dat is ook het controleren op fouten).
Investeren in het helder krijgen van wat de SW moet doen levert meer op dan heel veel testen. Hetzelfde geldt voor het testen van de SW door de programmeur: doen, want dat is verreweg het goedkoopste detectiepunt voor programmeerfouten. In een omgeving waar de communicatie tussen de belanghebbende van de software, de maker en de tester goed functioneert kun je een goede balans zoeken tussen het investeren in kwaliteit in ontwerp-bouw-test. (Zie ook de toelichting van Anko Tijman).
Het toepassen van modellen kan helpen. Zeker bij systemen met een hoog risico (zoals in het artikel). Ik constateer echter dat de afstand tussen de ‘academische, formele modellen en correcte software’ wereld enerzijds en de ‘als gebruiker heb een IT systeem nodig dat mij in het werk ondersteunt’ wereld (daar ben ik meer van) anderzijds nog altijd groot is.
Als de academische wereld de brug kan slaan naar de wereld van de ‘dagelijkse praktijk’ en er geld mee verdiend of beter: bespaard kan worden dan volgt investering in tools vanzelf.
Het haakje is nog niet gevonden.
Waar mensen werken, worden fouten gemaakt. Foutloze software is dus een illusie. Gek genoeg wordt er bij een softwarefout altijd gezegd: “Het systeem is onvoldoende getest”. Als het dak van een huis lekt, zegt iedereen: “Het is niet goed gebouwd”.
Ik ben het met dhr. Groote eens. Maar alles nog beter dan iets verzinnen wat dan ‘stragile testen’ wordt genoemd. Volgensmij is men bij VX de weg een beetje kwijt geraakt.