Niet meer testen, wie durft?

01-11-2011 13:10 | Door Ben Ootjers | Lees meer artikelen over: Testing | Er zijn 16 reacties op dit artikel | Permalink
Computable Expert
Ben Ootjers
Ben Ootjers

IT Architect Unisys

Expert van Computable voor het topic Development

Meer

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.

 

Reacties op dit artikel
De redactie vindt deze reactie: OKSimon, 02-11-2011 8:34
Het is dus een kwestie van kwaliteitsbewustzijn en het handelen daarop.
Als ontwikkelaars keer op keer laten blijken dat ze 'lui' zijn en dus broddelwerk afleveren, is er maar één oplossing: dáár is de deur - vertrekt u maar.
Dat vereist een cultuuromslag: wellicht iets minder de nadruk leggen op planning, en iets meer op kwaliteit. Het moet je eer te na zijn om je werk terug gestuurd te krijgen.
De redactie vindt deze reactie: OKPim Hermans, 02-11-2011 11:57
Ja en nee. De strekking is inderdaad dat als je een vangnet ophangt dit vangnet luiheid in de hand werkt. Een ABS levert later remmende automobilisten op. Menselijk gedrag. Maar is een vangnet of ABS dan onzinnig? Nee. Want dood laten vallen of te pletter laten rijden is ook geen optie. Wel is de rol van een tester anders en moet ook anders; niet testen achteraf maar begeleiden en vragen vooraf! Beter een goede vraag vooraf (toetsend) dan 1000 testen achteraf. De rol van een tester in 'agile' is meer gericht op het voorkomen van fouten dan het klassieke testen op de gebouwde functionaliteit. Achteraf. Want dat is duurder en levert het ongewenste vangnet op. Feitelijk is het niets meer dan het stimuleren van kwaliteitsbesef binnen (maar ook buiten) het team. De beste manier van toetsen is nog altijd vragen of iedereen binnen het team met de zojuist gebouwde auto de weg op durft. Met de handen los van het stuur en dan hard op de rem trappen..... het liefst op een gladde ondergrond :-)
De redactie vindt deze reactie: OKMichiel, 02-11-2011 12:52
Een tester vroeg betrekken is natuurlijk een goede zaak.
 
Daarnaast: zorg dat de ontwikkelaar tussen de oren krijgt dat hij alleen resultaten oplevert die productiewaardig zijn.
 
Dus niet opleveren om te laten testen, maar opleveren om in productie te nemen (en dan uiteraard nog wel de kwaliteit controleren).
De redactie vindt deze reactie: OKFrank Brechts, 02-11-2011 13:07
"Als software goed geschreven is, dan is testen op bugs en reviewen onzinnig.".
 
Voordat je kunt concluderen dat de software goed geschreven is moet je dat toetsen. Overigens kan software goed geschreven zijn, maar toch niet voldoen aan de wensen van de gebruiker. M.a.w.: het is belangrijk om ontwikkelaars en testers continu in de loop te houden. Overigens vind ik testen compleet doorgeslagen tegenwoordig, vroeger deed de ontwikkelaar zelf zijn testen en was de kwaliteitsbewustheid groter. Vaak zie ik testers die niet eens weten wat software echt is en die staan dan al gauw met de mond vol tanden bij een ontwikkelaar. Voor een gesmeerde machine geef ik dan ook vaak voorkeur aan voormalige ontwikkelaars die het testvak leuk vinden. Dat maakt ook de kloof tussen ontwikkelaars en testers kleiner.
De redactie vindt deze reactie: OKcpt, 02-11-2011 13:37
Over welke tests wordt hier gesproken als er "test" staat? Unit tests? Integratie tests? Acceptatie tests? (vul andere tests hier aan).
 
De programmeur zou elke opgeleverde applicatie inclusief unit tests moeten opleveren, de persoon aan wie dit wordt overgedragen kijkt of de tests voldoende diepgang hebben (maar ook niet teveel). Een van de manieren waarop dit kan gebeuren is via tools als Emma (als men met Java werkt in elk geval); maar alleen als deze tools als hulpmiddel worden gebruikt, niet als enigste bewijs.
 
Diverse mensen hebben al terecht aangedragen dat niet de programmeur moet zeggen dat het goede programmatuur is, maar dit moet aantonen door geslaagde tests.
 
Kortom: het artikel gaat om diverse redenen mank.
De redactie vindt deze reactie: OKRob van Steenbergen, 02-11-2011 13:39
Dit stuk gaat eigenlijk maar over één onderdeel van testen als ik het zo doorlees: Testen op de technische aspecten van de software en fouten in de code. Ik denk zelf dat de beste 'tester' om deze fouten te ontdekken de ontwikkelaar zelf is. Ook omdat een gevonden probleem dan snel is opgelost, de programmeur kan zelf het snelste het probleem oplossen. Dit is veel effectiever dan een aparte tester neer te zetten. De gemiddelde tester is niet constant bezig met programmeren en kent de code niet zo goed (of helemaal niet).
 
Het is altijd goed dat de programmeur samen gaat zitten met een tester, die als het goed is de testtechnieken beheerst, waardoor de programmeur zijn eigen (automatische unit) testscripts nog beter kan maken.
 
De tester zelf kan zich vervolgens gaan richten op de vraag :"Wordt de goede software gebouwd?". Dit is meer dan het vinden van fouten in code. Dit komt meer neer op het controleren of de software die gemaakt wordt wel aansluit op de processen van de business en de wensen van de gebruikers.
 
'Fouten vinden in code' is meer gericht op de details, op onderdelen en losse functionaliteiten: focussen op de technische kwaliteit. De 'aparte tester' zal meer het overkoepelende verhaal moeten bekijken (de-focussen). Sluit het aan op de werkelijkheid. Verder kan de 'aparte tester' gespecialiseerd zijn in performance testen, security, usability of anders.
 
Hierdoor scheidt je de werkzaamheden op het testvlak, twee of meer soorten van tests (proces of specialisatie in testsoorten), waarbij je ook geen dubbel werk doet.
 
Één keer iets testen is genoeg, dubbel testen maakt het inefficiënt. In plaats van het vangnet zo groot mogelijk te maken worden er meerdere vangnetten opgehangen op de plaatsen waar de grootste risico's zitten voor de business en gebruikers.
De redactie vindt deze reactie: OKStephen Poley, 02-11-2011 13:45
Een eenvoudige oplossing die ik met succes heb toegepast is als volgt. Alle software wordt wel degelijk getest door een aparte tester. Als hij echter meer dan een of twee voor de hand liggende fouten ontdekt - d.w.z. fouten die door de ontwikkelaar zelf redelijkerwijs gevonden hadden moeten worden - dan stopt hij gewoon met testen. De module gaat terug naar de ontwikkelaar met de boodschap om deze keer een goede unit test te doen. Meestal werkt dat heel effectief, zonder de drastische oplossing van Simon toe te passen.
 
Overigens werkt hetzelfde aanpak prima met reviews van documenten: als de reviewer al in de eerste paar pagina's een waslijst aan fouten ontdekt, dan keurt hij het document af zonder de rest te lezen.
De redactie vindt deze reactie: OKPaVaKe, 02-11-2011 13:50
Wat dat betreft vind ik het principe van één van de vliegtuigbouwers wel leuk (ik weet niet of het een broodje aap verhaal is overigens, maar dat doet in dit geval niet af aan het principe): bij de eerste testvlucht vliegen alle engineers mee.
 
Zeker weten dat ze ervoor zullen zorgen dat ze goede kwaliteit afleveren op deze manier!
En daarmee kom je dan ook op de opmerking van Michiel: kwaliteit moet tussen de oren zitten.
 

Maar om dan maar niet meer te testen gaat een paar bruggen te ver.
Ik kan er heilig van overtuigd zijn dat ik goede software heb gemaakt, en kan het wellicht nog bewijzen ook. Echter, als ik de spec anders geïnterpreteerd heb dan de auteur, kan het zo maar zijn dat mijn software iets anders doet dan bedoeld. Een test door een onafhankelijk tester kan (let wel: kan) dit afvangen.
 
Dito voor wat grotere complexe systemen, liefst ontwikkeld op verschillende fysieke lokaties en zo. Alle ontwikkelaars en/of teams zijn er van overtuigd dat ze iets goeds hebben gemaakt, aan alle kwaliteitseisen voldoend. Maar als we alles gaan integreren op systeemniveau werkt het vaak toch niet. Daar kom je liever achter bij het testen dan op het moment dat je bij de klant staat met je spullen.
 
Wat ook niet gaat helpen is dat je in een aantal sectoren bepaalde test-bewijslast zult moeten overleggen alvorens je het product op de markt mag zetten. Ik voorzie een praktisch probleempje hier als ik niet meer ga testen.
 
Tot slot weet ik niet met wat voor ontwikkelaars de auteur gewerkt heeft, maar "ontwikkelaars de indruk geven dat er niet meer getest gaat worden" komt op me over alsof je ze als een stel domme ganzen wil behandelen. Ik ga de ontwikkelaars vertellen dat er niet meer getest wordt, maar er komen wel defects binnen omdat iets niet werkt ???
De ontwikkelaars waar ik mee gewerkt heb tot op heden zullen daar in ieder geval niet in trappen.
 

Misschien dat de auteur een carrière als autocoureur kan overwegen, daar kun je met een stuk minder risico bochten afsnijden.
De redactie vindt deze reactie: OKFrank Brechts, 02-11-2011 14:00
@PaVaKe: Ja, dat is een broodje aap. Arbotechnisch niet toegestaan en ook dom om gelijk alle engineers de lucht in te laten gaan... ;-)
 
Iets serieuzer: Vaak weet de ontwikkelaar niet alle wensen en eisen, omdat er aan de voorkant van een traject geen betrokkenheid wordt geregeld door managers. Ik ga in principe uit van de goede bedoelingen en vraag mij dan ook af wat exact de oorzaak of reden kan zijn van bevindingen op software. Als je die reden/oorzaak vindt, dan heb je al het halve werk gedaan. Ik noem het veel voorkomende voorbeeld van de projectmanager die eigenhands de inhoud gaat bepalen, alleen maar omdat zijn project dan lekker vlot gaat....
De redactie vindt deze reactie: OKPascal, 02-11-2011 14:56
Ik heb gemerkt dat het ontwikkelen van geautomatiseerde test vaak veel meer tijd en moeite kost dan er in de (deel)applicatie gestoken kan worden.
Tenminste een functionele test is aardig maar dat het spul werkt geloof ik zo ook wel, het gaat zich om al die vele uitzonderings situaties waar je om te beginnen al niet eens aan denkt.
Simpel voorbeeldje y = a/(b-c) dat een deling door 0 kan opleveren. Dat staat nergens gespecificeerd.
Zelf maak ik vrij vaak testroutines omdat ik nogal eens te maken heb met veranderingen in specificaties (op zich al weer een heel artikel waard).
Ik vind dit overigens best een aardig artikel, en de reacties lijken dat ook wel te bevestigen.
 
@PaVaKe ik vloog ooit een kist waar net een nieuwe motor in was gezet die pas een half uurtje had proefgedraaid, gewoon zelf goed controleren voor je vertrekt.
De redactie vindt deze reactie: OKPaVaKe, 02-11-2011 16:10
@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
De redactie vindt deze reactie: OKPascal, 02-11-2011 19:22
@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)
De redactie vindt deze reactie: OKBen Ootjers, 03-11-2011 10:33
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.
De redactie vindt deze reactie: MatigOneens, 03-11-2011 17:23
"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!
De redactie vindt deze reactie: OKJaap Schuttevaer, 11-11-2011 15:02
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.
De redactie vindt deze reactie: OKBen Ootjers, 11-11-2011 20:29
@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.
93 vacatures
Web Developer ASP.NET C# (Medior / Senior)

NiDiDo BV , Barneveld

PHP Programmeur

BWSS B.V. , Deventer

.NET (C#) Programmeur

Let's build IT , Hoorn NH

Pielen in PHP, of on Rails in Ruby?

ForecastXL (via Quoratio BV) , Groningen

Senior SAP BW Specialist - Tilburg

Achmea , Tilburg

Top 10 Reagerende members
  Aantal reacties
met 3+ sterren
Gemiddelde
waardering
Klik voor meer info1 1571 6.2
Klik voor meer info2 1305 6.0
Klik voor meer info3 1271 6.2
Klik voor meer info4 1072 6.2
Klik voor meer info5 980 6.1
Klik voor meer info6 901 6.1
Klik voor meer info7 755 6.2
Klik voor meer info8 524 6.1
Klik voor meer info9 405 6.2
Klik voor meer info10 399 6.0