Joel on Software

Joel on Software   Joel over Software

 

Andere "Joel on Software" artikelen in het Nederlands

Andere "Joel on Software" artikels in het Engels

Email de auteur (uitsluitend in het Engels)

 

Top vijf (foutieve) redenen waarom je geen testers hebt


Door Joel Spolsky
Vertaald door Koen Verheyen
Geredigeerd door Bernard Vander Beken
30 april 2000

In 1992 had James Gleick veel problemen met buggy software. De nieuwe versie van Microsoft Word voor Windows was uit en werd door Gleick, een wetenschappelijk schrijver, afschuwelijk bevonden. Hij schreef een lang vlammend artikel in de "Sunday New York Times Magazine", het Word team kastijdend omdat ze klantenwensen zo negeerden en zulk een gigantisch buggy product opleverden.

Later, als klant van een lokale Internet provider Panix (toevallig ook mijn Internet provider), wou hij een manier om zijn mail automatisch te filteren en te sorteren. De UNIX tool daarvoor is procmail, echt archaïsch en met een interface die zelfs door de fanatiekste UNIX groupies obscuur wordt gevonden.

Hoedanook, Mr. Gleick maakte onvermijdelijk één of andere onschuldige typfout in procmail waardoor al zijn mail plots weg was. In een vlaag van woede besloot hij zijn eigen Internet provider op te zetten. Via het inhuren van Uday Ivatury, een ontwikkelaar, richtte hij Pipeline op, dat eigenlijk wat vóór liep op zijn tijd: het was de eerste commerciële Internet provider met enige vorm van grafische interface.

Nu had Pipeline natuurlijk zo zijn eigen problemen. De allereerste versie gebruikte geen enkel protocol voor foutcorrectie en had dus de neiging te crashen of zaken door elkaar te gooien. Zoals elke software had het zijn bugs. Ik solliciteerde voor een job bij Pipeline in 1993. Tijdens het interview vroeg ik Mr. Gleick naar het artikel dat hij had geschreven. "Nu u aan de andere kant van de omheining staat," vroeg ik, "hebt u nu wat meer appreciatie voor hoe zwaar het is goede software te maken?"

Gleick was niet vol van berouw. Hij ontkende dat Pipeline bugs had. Hij ontkende dat het maar enigszins zo slecht was als Word. Hij vertelde me: "Eens, Joel, zal ook jij Microsoft komen te haten." Ik was geschrokken dat zijn jaar ervaring als softwareontwikkelaar, niet enkel als softwaregebruiker, hem geen spikkeltje appreciatie had gegeven voor de moeilijke taak bug-vrije, makkelijk te gebruiken software te maken. Dus liep ik weg, de job weigerend. (Pipeline werd uitgekocht, door PSI, de eigenaardigste Internet provider op aarde om dan zonder ceremonie te worden geëxecuteerd.)

Software heeft bugs. CPUs zijn buitensporig kieskeurig. Ze weigeren absoluut om te gaan met dingen die ze niet expliciet zijn aangeleerd, en ze weigeren op de meest kinderachtige wijze. Als mijn laptop van huis weg is heeft hij de neiging te crashen omdat hij de netwerkprinter niet vindt die hij gewoon is. Wat een baby. Waarschijnlijk ligt het aan één enkele lijn code met één kleine minuscule, bijna onbelangrijke, bug erin.

Daarom heb je met absolute zekerheid een QA afdeling nodig. Je hebt 1 tester per 2 ontwikkelaars nodig (en meer als je software moet werken onder veel complexe configuraties of besturingssystemen). Elke ontwikkelaar zou nauw moeten samenwerken met één enkele tester, hem zoveel private builds toewerpend als nodig.

De QA afdeling moet onafhankelijk en machtig zijn, het mag niet rapporteren aan ontwikkeling. In tegendeel, het hoofd van QA zou een vetorecht moeten hebben tegen elke release die niet voldoet aan de inspectie.

Mijn eerste echte software job was bij Microsoft, niet bepaald beroemd voor zijn hoge kwaliteit, maar dat niettegenstaande een groot aantal testers tewerkstelt. Dus had ik eigenlijk zo'n beetje gedacht dat elke softwareafdeling testers had.

Velen hebben die ook. Maar een verbazend aantal heeft er géén. En veel softwareteams geloven zelfs niet in testers.

Je zou denken dat na de Kwaliteitsmania van de jaren 80, met allerlei inhoudsloze internationale "kwaliteitslabels" zoals ISO-9000 en dooddoeners als "six-sigma", managers nu zouden verstaan dat het hebben van producten van hoge kwaliteit zinvol is. En dat doen ze. De meesten hebben het gesnapt. Maar nog steeds komen ze aandraven met redenen om geen testers aan te werven. En het zijn allemaal drogredenen.

Ik hoop te kunnen uitleggen waarom die ideeën fout zijn. Als je gehaast bent, sla dit artikel dan over en begin voltijds testers in te huren, één per 2 ontwikkelaars.

Dit zijn de meest gehoorde dwaze excuses die ik gehoord heb om geen testers aan te werven:

1. Bugs komen van luie ontwikkelaars.

"Indien we testers in dienst nemen", houdt deze fantasie ons voor, "worden ontwikkelaars slordig en schrijven ze slechte code. Door testers te vermijden forceren we ontwikkelaars om direct goede code te schrijven."

Ja, dat zal wel. Als je dat echt denkt, heb je ofwel zelf nooit code geschreven, of ben je ongewoon oneerlijk over wat code schrijven eigenlijk is. Fouten sijpelen per definitie door omdat ontwikkelaars ze zelf niet opmerken in hun code. Dikwijls heb je slechts een tweede stel ogen nodig om ze op te sporen.

Toen ik code schreef voor Juno, had ik de gewoonte mijn code telkens op dezelfde wijze uit te voeren... Ik had mijn eigen gewoontes, met nadruk op het gebruik van de muis. Onze geweldige, verschrikkelijk overgekwalificeerde tester had lichtjes andere gewoontes: zij was meer toetsenbord georiënteerd (en testte de interface streng op elke inputcombinatie). Dat bracht al snel een hele karrenvracht bugs aan het licht. Soms zei ze me vlakaf dat de interface niet werkte, 100% onbruikbaar, zelfs al werkte die bij mij altijd prima. Als ik haar dan de bug zag reproduceren had ik steevast een "sla je voor het hoofd" ervaring. Alt! Je drukt op de Alt-toets! Waarom heb ik dat niet getest?

2. Mijn software staat op het web. Ik kan bugs verbeteren in een seconde.

Ba ha ha ha ha! OK, webdistributie laat je toe bugs veel sneller te verbeteren dan de vroegere, in dozen verpakte software. Maar onderschat de kost van het verbeteren van een bug niet, zelfs in een web site, nadat het project is afgerond. Je kan bijvoorbeeld nog meer bugs introduceren door de éérste te verbeteren. Maar een erger probleem is dat als je even het proces nakijkt dat je gebruikt om nieuwe software te verspreiden, je je snel zal realiseren dat het best wel duur kan zijn verbeteringen via het web te verspreiden. Onafgezien nog van de slechte indruk die je maakt, wat ons leidt naar:

3. Mijn klanten zullen de software voor me testen.

Ah, de geduchte "Netscape Verdediging". Deze arme firma liep een bijna buitennatuurlijke reputatieschade op door hun "test" methodologie:

Als de ontwikkeling ongeveer halfweg is, geef de software dan zonder testen vrij op het web.

Als de ontwikkelaars zeggen dat het af is, geef de sofware vrij zonder testen.

Doe dat zes of zeven keer.

Noem één van die versies de "definitieve versie".

Maak versies .01, .02, .03 telkens er een verveldende bug opduikt op c|net

Deze firma pionierde met het idee van "wijdverspreide betas". Letterlijk miljoenen gingen deze onafgewerkte, buggy releases downloaden. In de eerste paar jaren was bijna iedere Netscape gebruiker met één of andere pre-release of beta versie bezig. Waardoor de meeste mensen denken dat Netscape software werkelijk buggy is. Zelfs als de uiteindelijke release gewoonlijk wel redelijk stabiel was, had Netscape zovelen geconditioneerd met buggy versies, dat de gemiddelde indruk er één van zwakke sofware was.

Daarnaast is er het hele idee van het vinden van bugs aan "je klanten" over te laten, waarna je ze zelf verbetert. Spijtig genoeg heeft noch Netscape noch enige andere firma ter wereld de mankracht om uit 2.000.000 bugrapporten de belangrijke punten te filteren. Toen ik bugs rapporteerde in Netscape 2.0, crashte het rapporteringssysteem geregeld en liet me simpelweg niet toe bugs te melden (die natuurlijk toch maar zouden verdwijnen in een zwart gat). Maar Netscape leert het maar niet. Testers van de huidige "inzage" versie, 6.0, hebben in nieuwsgroepen geklaagd dat de bugrapporteringssite nog steeds niet toelaat bugs te melden. Jaren later! Hetzelfde probleem!

Van de ontelbare bugrapporten durf ik te wedden dat ze toch bijna allemaal gaan over de 5 of 10 echt opvallende bugs. Begraven onder die hooiberg zitten één of twee interessante, lastig-te-vinden bugs waarvoor iemand de moeite heeft gedaan ze te melden. Maar het is vergeefse moeite want er is toch niemand die er naar kijkt.

Het ergste van deze testwijze is de opmerkelijk slechte indruk die je van je firma zult geven. Toen Userland de eerste Windows versie van hun vlaggeschip Frontier vrijgaf, downloade ik het en begon me door de tutorial heen te werken. Spijtig genoeg crashte Frontier verschillende keren. Ik volgde letterlijk hun eigen, gedrukte instructies op, maar kon niet meer dan 2 minuten met het programma werken. Ik had het gevoel dat niemand bij Userland zelfs ook maar een minimum hoeveelheid had getest, al was het maar om te zorgen dat de tutorial werkte. Die indruk van lage kwaliteit hield me erg lang weg van Frontier.

4. Iedereen die gekwalificeerd is om te testen wil het niet doen.

Dit is een pijnlijke. Het is lastig goede testers te vinden.

Bij testers, net als bij ontwikkelaars, zijn de besten een grootteorde beter dan het gemiddelde. Bij Juno hadden we één tester, Jill McFarlane, die drie keer meer bugs vond dan de vier andere testers samen. Ik overdrijf niet, ik heb het zelfs gemeten. Ze was meer dan twaalf keer productiever dan de gemiddelde tester. Toen ze vertrok zond ik een email naar de CEO zeggende "Ik heb liever Jill enkel op maandag en dinsdag dan de rest van het QA team samen".

Spijtig genoeg raken de meeste slimme mensen verveeld van dagelijks testen en dus blijven de besten gewoonlijk zo'n 3 à 4 maanden en vertrekken dan weer.

Het enige wat je kan doen is dit te onderkennen en er naar te handelen. Hier zijn een paar suggesties:

Gebruik testen als een carrièrestap omhoog vanuit technische support. Vervelend als testen kan zijn, het is stukken beter dan omgaan met woedende klanten en dit kan een manier zijn om het woelen binnen de technische support wat te verminderen.

Laat testers hun loopbaan verder ontwikkelen door ze een cursus programmeren te laten volgen en stimuleer de verstandigere om automatische test suites te ontwikkelen via ontwikkelingstools en scriptingtalen. Een stuk interessanter al dan hetzelfde dialoogvenster opnieuw en opnieuw en opnieuw te testen.

Besef dat je verloop onder toptesters groot zal zijn. Zet een agressieve wervingscampagne op om een vaste instroom mensen te garanderen. Stop niet met aanwerven omdat je toevallig een vol huis hebt, want de zeven vette jaren zullen niet blijven duren.

Zoek ook "minder traditionele" medewerkers: slimme tieners, studenten en gepensioneerden die part-time werken. Je zou een verbazend efficiënte testafdeling kunnen opzetten met twee of drie super voltijdsen en een leger jongeren van Bronx Science (een top school in New York) die vakantiewerk doen om aan geld te geraken.

Gebruik tijdelijke medewerkers. Als je ongeveer 10 interims inhuurt om je software een paar dagen lang te bombarderen, zal je een enorme hoeveelheid bugs vinden. Twee of drie zullen wellicht het testen in zich hebben, en die kan je voltijds aanwerven. Weet op voorhand dat sommige tijdelijken waardeloos zullen blijken als testers; stuur ze wandelen en ga verder. Daar dienen uitzendbureaus voor.

Hier is een manier om er niet mee om te gaan:

Geen denken aan dat je gediplomeerden uit het hoger onderwijs voor je kan laten werken door "iedereen eerst een tijdje in QA te laten zweten voor ze mogen gaan coderen". Ik heb dit al dikwijls gezien. Ontwikkelaars zijn geen goede testers en je verliest er goede ontwikkelaars door die lastig te vervangen zijn.

En tenslotte de allerstomste reden waarom men geen testers inhuurt:

5. Ik kan me geen testers veroorloven!

Dit is de domste van alle, en het makkelijkst te weerleggen.

Hoe moeilijk het ook moge zijn om testers te vinden, ze blijven nog steeds goedkoper dan ontwikkelaars. Véél goedkoper. En als je geen testers inhuurt, dan gaan je ontwikkelaars tester spelen. En als je het erg vind dat testers opstappen, wacht tot je ondervindt hoe duur het is om die sterontwikkelaar, werkend tegen 5000 EUR/maand, te vervangen omdat ie het moe werd te horen "een paar weken aan testen te besteden voor we releasen" en naar een professionele firma ging. Je kan een jaar lang drie testers inhuren met de recruteringskosten nodig om zijn vervanger te vinden.

Beknibbelen op testers is zulk een waanzinnig valse besparing dat ik simpelweg achterover val wanneer men dat niet inziet.



De originele versie van dit artikel verscheen in het Engels onder de naam Top Five (Wrong) Reasons You Don't Have Testers  

Joel Spolsky is de oprichter van Fog Creek Software, een klein softwarebedrijf in New York. Hij studeerde af aan de Yale universiteit, en heeft als programmeur en manager gewerkt bij Microsoft, Viacom en Juno.


De inhoud van deze pagina's vertegenwoordigt de mening van één persoon.
Alle inhoud Copyright ©1999-2005 door Joel Spolsky. Alle rechten voorbehouden.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky