Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet het redactionele gedachtegoed van Computable.

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 | Dit artikel heeft nog geen cijfer (te weinig beoordelingen) | 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.

 

Deel dit artikel via LinkedIn
Deel dit artikel via Facebook
Deel dit artikel via Twitter

De sleutel voor succesvolle software development: betrek eindgebruikers

De kwaliteit van software is een belangrijke asset voor iedere grote Nederlandse organisatie. Het ontwikkelen van......

81 vacatures
Wetenschappelijke Softwareontwikkelaar

Tessella Ltd , 's-Gravenhage

Back-end Developers in Rotterdam en Amsterdam

Label A , Amsterdam

PHP-developer

zuiderlicht , Maastricht

Ontwikkelaar hard- en software

Ministerie van Defensie, Commando Zeestrijdkrachten , Den Helder

Maatwerkontwikkelaar Oracle EBS

SSC-ICT Haaglanden van het ministerie van Binnenlandse Zaken en Koninkrijksrelaties , Zoetermeer

Top 10 reagerende bezoekers
      Aantal
reacties
Gemiddelde
waardering
Klik voor meer info 1 2090 6.82
Klik voor meer info 2 1536 6.74
Klik voor meer info 3 1245 6.69
Klik voor meer info 4 1145 6.65
Klik voor meer info 5 899 6.58
Klik voor meer info 6 628 6.36
Klik voor meer info 7 446 6.34
Klik voor meer info 8 1137 6.14
Klik voor meer info 9 750 6.08
Klik voor meer info 10 462 6.06