Testen van gemaakte software is een vanzelfsprekendheid, maar wat is het gevolg van testen? Dat er fouten gemaakt worden bij software ontwikkeling staat vast. Het voorkomen van fouten scheelt kosten. Vooral als fouten laat ontdekt worden zijn de kosten voor het verwijderen enorm. Het aantal fouten en moment van optreden wordt vaak gemeten en daardoor voorspelbaar. Capers Jones heeft op dit gebied zelfs al benchmarkgegevens gepubliceerd, waarmee een bedrijf zich kan meten.
Softwaretests zijn niet afdoende, dus worden voor het voorkomen allerlei technieken aangewend zoals geautomatiseerd testen, design reviews en code reviews. Maar kijken we wel genoeg naar het effect van deze methoden?
Als software goed geschreven is, dan is testen op bugs en reviewen onzinnig. Het is alsof je testscripts uitvoert op een volledig getest systeem en overal netjes groene vinkjes mag plaatsen. Je bent een hoop tijd kwijt geweest voor het maken van goede testscripts en kunt die snel uitvoeren en allemaal op geslaagd zetten. We weten dat dit in de praktijk bijna nooit het geval is, maar soms (of ten dele) wel. Waarom soms wel en soms niet?
Goede ontwikkelaar is lui
Een gezegde onder ontwikkelaars is: ‘een goede ontwikkelaar is lui'. De kern hiervan is dat een ontwikkelaar zo min mogelijk tijd wil besteden om iets te doen. Als hij iets moet doen dat saai en herhalend is, zal hij eerder een programma schrijven dat diezelfde taak uitvoert, dan dat hij het saaie werk doet. Met het programma spaart hij dan gelijk tijd uit. De luie ontwikkelaar is hier dus iemand die op een snelle en slimme manier zijn werk doet.
Toch wordt lui zijn meestal als negatief ervaren. Zo zijn er ontwikkelaars die een hekel hebben aan het onderhouden van de code van een ander, en ontwikkelaars die niet houden van testen. Gelukkig kunnen we hier aparte testers voor inschakelen, hetgeen niet helemaal probleemloos is.
Vangnet
De testers vormen namelijk een vangnet voor de luie ontwikkelaar. De ontwikkelaar denkt al snel: 'dat gaat de tester toch nog testen', dus staakt zijn eigen testinspanning. Een andere reden die een luie ontwikkelaar zal aandragen is natuurlijk tijdsdruk. Het is te lastig, complex en tijdrovend om dit helemaal door te testen is dan een veel gehoord argument. Voor een tester is het echter net zoveel of vaak nog meer werk. De combinatie van luiheid en geen zin in testen leidt hier tot het doorschuiven van de testinspanning en daardoor ook tot late foutdetectie.
Deze luiheid en het doorschuiven kunnen een vast patroon worden. De ontwikkelaar denkt niet eens meer na of hij zelf moet testen, want daar zijn tenslotte anderen voor. Het is als het ware werkverschaffing van de ontwikkelaar aan de tester. In tijden van crisis is baanbehoud natuurlijk prettig, maar dit is toch een structureel probleem.
Met of zonder vangnet
Iedereen kent de circusacts, waarbij gebruik wordt gemaakt van vangnetten. De vraag is of een circusact vaker mislukt met of zonder vangnet. Indien er een vangnet wordt gebruikt zijn de gevolgen niet zo groot. Lichamelijk zal de acrobaat niets mankeren, en hij kan waarschijnlijk zijn act vervolgen als hij/zij niet teveel geestelijk in paniek is geraakt. Als er geen vangnet is, zijn de gevolgen desastreus en zal de acrobaat de act mogelijk nooit meer uit kunnen voeren. In de softwareontwikkeling zijn de gevolgen minder duidelijk, maar toch is het goed even deze metafoor voor ogen te houden.
De slagingskans van de act zonder vangnet zal namelijk hoger liggen omdat de acrobaat zich iedere keer goed zal concentreren voordat hij begint aan zijn act. Er staat immers veel op het spel. Een tussenvorm is niet zo gebruikelijk, maar kan natuurlijk wel. Een vangnet met flinke gaten erin. De acrobaat zal alleen aan de gaten denken, maar heeft bij het vallen misschien wel geluk. In dit geval zou de acrobaat dus eigenlijk niet moeten weten waar er wel en waar geen vangnet is om tot het hoogste slagingspercentage te komen.
Niet meer testen
Als we dat doortrekken naar software ontwikkeling dan moet je de ontwikkelaars de indruk geven dat er niet meer getest wordt. Je laat ze alleen de gaten in het vangnet zien. Op die manier voelen ze zich zelf verantwoordelijk voor de correcte werking in productie. Dit sluit ook prima aan bij een Agile benadering waarbij eigen verantwoordelijkheid en brede kennis van de teamleden belangrijk is.
Ik probeer de ontwikkelaars in mijn team altijd hun eigen kwaliteit te laten toetsen. Door veel aandacht te geven aan principes en testen van eigen code door middel van unit tests. Het daarna door een ander laten reviewen of testen van de software moet voor de ontwikkelaar geen vanzelfsprekendheid zijn. De gevolgen van een fout worden hierdoor groter, echter zullen er minder fouten worden gemaakt. Voor de zekerheid kunnen nog wel toevallige code reviews of tests worden uitgevoerd. Zo verbetert de kwaliteit van de ontwikkelde software voordat er getest wordt door een aparte tester. Maar echt niet meer laten testen door een aparte tester vind ik wel een erg groot risico.
Verwijzingen
Jones, C. (2008), Applied Software Measurement: Global Analysis of Productivity and Quality, Third Edition, McGraw-Hill.
@Pascal
Geautomatiseerd testen levert vooral veel op als je veel regressietesten moet doen. Vooral bij een lange levenscyclus van je product is dat snel terug verdiend
@pavake,
Ik gebruik automatisch testen voor twee zaken
QA, in een soort van extreme programming omgeving. das o.a. een eis voor DSP dingen waar ik wel es mee bezig ben.
En voor het ontwikkelen en testen binnen omgeving waar de specs wispelturiger zijn dan het weer.
(praat ik vooral over internet gerelateerde zaken dus technisch niet erg hoogstaand, maar het betaald de rekeningen)
Zoals Simon al aangaf in de eerste reactie is het artikel inderdaad vooral gericht op kwaliteitsbewustzijn. Het gaat me erom duidelijk te maken dat het beter is om te richten op een ontwikkelaar die goede software oplevert dan een tester die een ontwikkelaar daarop telkens terecht wijst. Dat is natuurlijk ook nog iets anders dan de juiste (aansluitend op klantwensen) opleveren. Ik heb bewust vermeden om aan te geven welke testen we het over hebben, om extra te prikkelen en dat is zo aan de reacties te zien gelukt. Ik wil eigenlijk vooral aangeven dat het testen op bugs eigenlijk bij de ontwikkelaar hoort te liggen. Het liefst in de vorm van unit tests. Andere testen die voor een bruikbaar systeem veel belangrijker zijn, vallen dus sowieso buiten de scope van dit artikel.
Het weglaten van testen is vooral in de beleving van mensen nodig net als in het vliegtuig voorbeeld. Als een kind fietst met zijwieltjes dan zit die vaak ook zo scheef mogelijk op de fiets; er gebeurt immers niets. Hij leert dan niet echt te fietsen. Zo lang het niet echt zeer doet, dan is de mensen geneigd de grens op te zoeken en die rekken we op als er andere mensen de problemen afvangen of erger nog oplossen.
“Andere testen die voor een bruikbaar systeem veel belangrijker zijn, vallen dus sowieso buiten de scope van dit artikel.”
Hahaha, dan moet je misschien even je titel aanpassen. Want met zo’n algemene titel, is je verhaal wel heel erg beperkt!
Aardig artikel, maar helaas strookt de titel niet met de inhoud. En, eerlijk gezegd, is de inhoud ook nogal wat verwarrend en tegenstrijdig.
Het begint met de beschrijving van een ideale wereld, waarin ontwikkelaars oneindig zorgvuldig zijn. Met als onderliggende bewering dat dan testen niet nodig zou zijn, omdat die luie ontwikkelaars dan zelf hun werk wel zouden testen… Maar, de bewering was toch dat testen niet meer nodig zou zijn?
Ik neem aan dat de auteur niet bedoelt dat dan testen overbodig is, maar wel als aparte discipline. En dan ook zonder aparte rol. De ’tester’ verdwijnt dan. ‘Projecten zonder testers, wie durft?’ Dit kan ik volgen. Zeker als Agile methoden, zoals Scrum, worden gebruikt. Hoewel ook daar veelal in een ‘Defintion of Done’ zal staan dat de software ge-unit-test moet zijn. Testen als activiteit zal dus wel blijven.
Iets anders wat dit betoog lastig maakt is het luie gebruik van het werkwoord ’testen’: het werkwoord ‘testen’ mist een zelfstandig naamwoord. Volgens mij zijn bijvoorbeeld keten-, uitwijk-, capaciteits- en security-testen heel lastig door ontwikkelaars zelf uit te voeren. Laat staan de Gebruikers Acceptatie Test. Als ik weer mag aannemen dat de auteur doelt op de Functionele Acceptatie Test, dan kan ik hem wel weer volgen. Jammer dan alleen van zijn laatste zinnen, waarin hij zelf toch weer een lans breekt voor onafhankelijk testen: “Voor de zekerheid kunnen nog wel toevallige code reviews of tests worden uitgevoerd. […] niet meer laten testen door een aparte tester vind ik wel een erg groot risico.’
Kijk, nu komen deze auteur en ik weer bij elkaar: het is goed als ontwikkelaars hun best doen om zelf ook als een ‘echte tester’ naar hun eigen werk leren kijken. Dat zal zeker de kwaliteit vergroten. Maar onafhankelijk uitvoeren van testen blijft nuttig. Zowel uit het oogpunt van risicobeheersing als uit praktisch oogpunt. Testen is nu eenmaal iets anders dan iets bouwen.
En ‘Ja’, als in mijn project alle stakeholders allemaal een oneindig grote risicobereidheid hebben, dan durf ik te ontwikkelen zonder te testen. Maar dan wel met ‘garantie tot de deur’. En ‘Nee’, als professional zal ik dat eigenlijk toch nooit willen.
@Jaap
Het is goed opgemerkt dat het artikel en de titel enigzins uit elkaar liggen. Niet meer testen kan in een veel bredere betekenis worden opgevat dan hier in het artikel staat. Het artikel gaat veel meer in op een bewustwording van het effect dat aparte testers kunnen hebben. Ik bedoel dan vooral testers die gericht zijn op het vinden van functionele fouten (niet werken volgens specificatie) en om testers die heel dicht bij ontwikkelaars staan kunnen hebben. Veel minder om bijvoorbeeld ketentesters, performancetesters of gebruikers die een acceptatietest uitvoeren.
De titel is bewust zo breed gekozen om te prikkelen. Verder is ook de inleiding bewust zo neergezet, als in een ideale wereld. Toch staan die twee niet helemaal los. Een ideale wereld is vaak gebaseerd op principes waar niet van afgeweken wordt. Ik ben een groot voorstander van werken met principes die kwaliteit tijdens ontwikkeling waarborgen. Hiermee forceer je een ontwikkelaar anders na te denken over de gemaakte code. Dit wordt ook gedaan door een ontwikkelaar meer als een tester te laten denken. Dit maakt de tester niet overbodig, maar de tester die het vuile werk van de ontwikkelaar opknapt is gelukkig ook niet meer nodig.