Testen is makkelijk, toch….? Gewoon iemand achter een computer zetten en zeggen: “Zoek de fouten!” Iemand van de straat kan dat toch ook! Waarom zou je een professionele tester inhuren? Wat zijn de voordelen van een test professional voor een bedrijf? Joost Wigman en Mark Robinson proberen deze prangende vragen hier te beantwoorden.
Een aantal jaren geleden spraken de mensen over software-ontwikkelaars – of programmeurs, zoals ze vaker werden genoemd in de jaren 80 en 90 – als nu over testers. Waarom een ervaren programmeur inhuren wanneer een goedkope, enthousiaste schoolverlater kunt krijgen? Je hoorde verhalen van mensen die software in hun garage schreven en die kwalitatief gelijkwaardig zou zijn aan professionele software; denk aan Doom en Apple.
Tuinhuisje of torenflat
Laten wij deze stelling eens anders verwoorden: stel dat je een tuinhuisje wilt bouwen. Natuurlijk hebt je een grof idee van wat je wilt doen. Er is wat materiaal nodig en misschien ook nog iemand die wil helpen. Hiermee kun je iets moois maken zonder veel kennis of ervaring.
Na het succesvol bouwen van een tuinhuisje verleg je de ambities. Je wilt nu een wolkenkrabber bouwen! Werkt dan ook een aanpak als voor het tuinhuisje? Ga je het redden met het hulpje, een paar planken en een schetsje op de achterkant van een bierviltje? Het antwoord hierop is hoogstwaarschijnlijk: nee. Je realiseert je dat hiervoor veel personeel is, zoals een architecten, constructeurs, bouwvakkers, opzichters….en nog veel meer.
Het verschil tussen het tuinhuisje en de wolkenkrabber is vergelijkbaar met het ontwikkelen van software eind jaren 80 en vandaag de dag. Vroeger werd een spel door een persoon of een klein team gemaakt. Tegenwoordig vergt dit evenveel planning en mankracht als het realiseren van een Hollywood blockbuster. Voor de creatieve kant hebt je acteurs, script schrijvers en tekenaars nodig voor het maken van een verhaallijn. Zij werken continue samen met een team software architecten, ontwikkelaars, project leiders en natuurlijk testers.
Vallen over fouten
In zijn boek ‘Now, Discover Your Strengths', beschrijft Marcus Buckingham de volgende observatie: "Bij professionele golfers is het verschil tussen uitmuntend en gemiddeld beperkt. De topgolfers hebben over achttien holes gemiddeld 27 slagen nodig, terwijl gemiddelde spelers de golfbal gemiddeld 32 keer moeten raken." Voor testen geldt het zelfde: een standaard-test team zal gemiddeld goed werk doen in het vinden van fouten. Ze zullen een acceptabel aantal fouten per week vinden en rapporteren. Testen gaat voor veel bedrijven in eerste instantie over het vinden van fouten. Als een tester geen fouten vind in een aanzienlijke periode dan is hij al vlug te duur. Hij of zij voegt niets toe aan het product en demotiveert de rest van het team.
In mijn beleving kun je het ook anders bekijken, meer gemeten naar waarde waarbij het gaat om: Het aantal hoog risico fouten die testers vinden, rapporteren en beheren. Aan dit statement zitten vele aspecten.
Het is belangrijk voor alle werknemers, en dus niet alleen voor testers, dat ze een meetbaar doel hebben (‘aantal'). Het geeft een meetwaarde die aangeeft hoe goed ze hun werk doen. Voor ‘hoog risico fouten die testers vinden' geldt dat ze niet (kunnen) beslissen of een fout belangrijk is. Ze kunnen echter wel hun activiteiten richten op de gebieden die meer kritisch zijn voor de klant. Sommige testers pakken dit verkeerd op en rapporteren veel onbelangrijke fouten wat resulteert in een minder goede reputatie bij hun collega's. Testers moeten fouten die ze vinden op een professionele manier ‘rapporteren'. Dus objectief en feitelijk en zeker stellen dat de fout duidelijk is voor de ontwikkelaars. Ze moeten ook helder rapporteren aan het management, om hen inzicht te geven over de software kwaliteit. Tot slot nemen testers vaak de verantwoordelijkheid voor de lifecycle van een fout (het ‘beheer'), van indienen tot controleren en of het is opgelost (door hertesten) en het sluiten ervan.
Dit doet dus de standaard-tester. Hij is veel meer dan iemand die over fouten valt. Maar wat is dan een professionele tester? Is dat iemand zoals net beschreven….maar dan ‘groter' dan dat, iemand die meer fouten en vooral meer belangrijke fouten vindt, die op één of andere manier beter rapporteert en beheert? Ja, een professionele tester doet al die dingen en nog veel meer.
Effectiviteit maximaliseren
In een leidende rol zal een professionele tester een strategie maken voor testen. Hij focust alle testwerkzaamheden op het vinden van de hoge prioriteit fouten. Ofwel, de professionele tester maximaliseert de effectiviteit van het team wat hij of zij leidt.
Een voorbeeld: Je bent een testconsultant en wordt ingehuurd door een klant voor een bepaalde periode. Je weet dat je waarschijnlijk nooit hetzelfde niveau van domeinkennis krijgt als veel van de directe collega's bij deze klant. Wat je wel kunt bieden, is testkennis, die hun domein kennis aanvult.
Aan de basis van een goede test strategie staat een degelijke risico analyse. Dit betekent dat iedere functie van een systeem (of een deel hiervan) wordt beoordeeld, op de ‘kans' op fouten (voor een functie) en het ‘gevolg' van die fouten. De foutkans neemt toe als de functie nieuw is, ontwikkeld door een onervaren ontwikkelaar, of vaak gebruikt wordt door een klant. Gevolg: hoe serieus is het als de functie niet werkt. Dit gevolg kan, bijvoorbeeld, een software crash of verlies van data betekenen. Een gebruiker kan gewond raken of de business kan een slechte reputatie krijgen, waardoor ze klanten verliezen.
Vals vertrouwen
Nadat een goede risico analyse is gedaan, worden ‘test gevallen' geschreven die zich richten op de hoog risico gebieden en alle ‘test gevallen' krijgen een prioriteit voor de test uitvoer. Wij zijn de tel kwijt geraakt van het aantal keren dat we een enorm oud document hebben gezien met de naam ‘regressie test gevallen', die in zijn geheel uitgevoerd moesten zijn, voordat het product vrijgegeven kon worden.
Een klant maakte bijvoorbeeld een gebruikersinterface voor printersoftware die een regressie test had van twee weken. In die periode werden typisch één of twee fouten gevonden. Vaak hebben testers hierdoor geen vertrouwen in de regressie test, juist omdat er geen belangrijke fouten worden gevonden. Een dergelijke regressie test set geeft managers dan ook vaak een vals vertrouwen in de kwaliteit van de software.
Hier kan een professionele tester opnieuw het risico verminderen. Dit wordt hoofdzakelijk bereikt door de juiste prioriteit aan de ‘test gevallen' toe te kennen, maar ook door het introduceren van meer creatieve test oplossingen. Aan de ene kant meer geplande ‘test gevallen' in de vorm van geautomatiseerde testen en aan de andere kant minder geplande testen door bijvoorbeeld het gebruik van exploratory testen. Hier gaan twee testers het product gebruiken aan de hand van een vooraf gedefinieerde test charter wat in hoofdlijnen aan geeft waar te testen, maar zonder het gebruik van formele ‘test gevallen'.
Een test professional zal ook het verschil kunnen maken wanneer een test fase ingekort moet worden. Hij zal aan het management de statusrapporten leveren met daarin de opmerking dat de ‘test gevallen' met de hoogste prioriteit (dus hoogste risico) gedaan zijn, maar die met een lagere prioriteit niet. Dus, als we aannemen dat er geen hoog risico fouten meer in het product zitten, kan de klant alleen fouten met een lager risico ontdekken. Dit geeft het management een solide basis om beslissingen te nemen, in plaats van af te moeten gaan op vage opmerkingen als: "We hebben een kwart van de testen gedaan."
De wereld is veranderd
Naast deze eenvoudige voorbeelden over hoe een professionele tester een strategie opstelt voor het vinden van de belangrijkste fouten, geeftt hij/zij ook nieuw leven en energie aan testteams. De professionele tester weet dat bedrijven niet kunnen doorgaan met het testen van software op dezelfde manier als vijf jaar geleden. De wereld om hen heen is veranderd, evenzo het product dat getest moet worden. Stilstand is achteruitgang, dus verbetering van het continue testproces is noodzakelijk.
Een professionele tester onderkent dit en zoekt naar een combinatie van industrie standaarden voor testproces-verbetering en nieuwe ontwikkelingen. Voorbeelden van verbeterprocessen zijn TMM (Test Maturity Model) & TPI (Test Process Improvement). Agile en Lean development zijn voorbeelden van bovengenoemde nieuwe ontwikkelingen op testgebied. Een professionele tester zal hierin nooit blindelings een techniek volgens het boekje implementeren. Hij of zij zal er altijd pragmatisch mee omgaan, in het belang van het bedrijf en hierbij gebruik maken van de ervaring om de effectiviteit van het team te maximaliseren en om zeker te stellen dat ze nog meer hoge prioriteit fouten vinden.
Smoke test
Verder kijkt een professionele tester naar de gehele lifecycle van de productontwikkeling, om te bepalen hoe dit verbeterd kan worden in iedere fase. Dit omvat het aansporen tot goede requirements, door gebruik te maken van templates en het doen van reviews. Met een zogenaamde ‘smoke test' wordt voorkomen dat het testteam slechte kwaliteit software integreerd En natuurlijk door testen op alle niveau's uit te voeren, van statische code reviews tot aan klant evaluaties van de software.
Het meest bereikt een professionele tester echter door het aanmoedigen en motiveren van de testers om hem heen. Hij of zij doet dit door aan te tonen dat testen een vakgebied is, door het aansporen van het management voor goede opleiding voor het test team en te stellen dat het test team duidelijke doelstellingen heeft en de juiste resultaten levert.
De meest uitdagende taak van een professionele tester is om een voorbeeld te zijn voor de andere tester in het team: ‘leading by example' en uitblinken in het soms ondergewaardeerde testvak. Dit kan alleen worden gedaan door regelmatig te ervaren hoe het is om een product te testen en fouten te rapporteren. Dit natuurlijk altijd op een professionele manier die anderen inspireert.
Conclusie
Nog even terug kijkend naar de constatering van Marcus Buckingham, kunnen wij het onderstaande concluderen: Met een betere focus, goede training en betere technieken, kan een tester excelleren van iets van twintig procent naar honderd procent, ofwel een professionele tester worden. Juist dat kan het verschil maken tussen het winnen en verliezen in de markt. Daarnaast betaalt de prijs van een testprofessional zich dik terug in de tevredenheid van de klant doordat deze een product heeft met de best mogelijke kwaliteit binnen de beschikbare tijd.
Joost Wigman en Mark Robinson,
Testmanagers bij Topic Embedded Systems
Op zich een prima artikel. Ik kan mij er wel in vinden, hoewel het niet heel erg vernieuwend is. Het artikel gaat over het inhuren van een professionele tester, maar het toepassen van een professioneel testtraject zou een veel grotere meerwaarde hebben. Een professioneel tester is stap een. Het invoeren en inbedden van een op maat gemaakt testtraject is stap twee. Bij het doorvoeren van stap twee is stap een natuurlijk onontbeerlijk. De meeste bedrijven zijn echter al bij stap een. Het doorvoeren van stap twee is haalbaar door bijvoorbeeld een teststraat in te richten.
Wat in mijn mening wel onjuist is, is het stukje over regressietests in “vals vertrouwen”. Een regressieset uitvoeren kan een zeer nuttige bezigheid zijn, maar maak duidelijk wat het nut van een regressieset is. Als dit duidelijk gemaakt is, zal er meer begrip zijn voor het feit dat er juist geen bevindingen gedaan zijn.
Het probleem zoals het in het artikel geschetst wordt is onder te verdelen in twee twee aspecten:
1) Het uitvoeren van een regressieset voordat het product opgeleverd mag worden kan een zeer bewuste keuze zijn. Als er delen van een product ongewijzigd blijven in het product, dan is het niet meer dan verstandig dat hier een regressietest op los gelaten wordt. Er moet immers aangetoond (kunnen) worden dat de nieuwe wijzigingen geen effect hebben op de niet geraakte functionaliteit. Neem dit dus als productrisico op in de risicoanalyse en voer de regressietest uit als onderdeel van een van de onderkende testsoorten.
2) Het onderhouden van een regressieset is veel te vaak het kind van de rekening. Het project is afgelopen en de set blijft achter in de projectdocumentatie ipv. dat deze mee opgeleverd en onderhouden wordt. Juist daar zit bij de meeste projecten het manco. Juist dit levert bij een volgend project de conclusie op “de regressieset is verouderd en niet meer bruikbaar”.
Beide aspecten zijn zijn prima te realiseren met een teststraat. Zie ook: http://www.valori.nl/werkenmetvalori/goedopdrachtgeverschap/ondersteuning/testfactory
Ook ik ben van mening dat het artikel goed, doch een beetje “kort door de bocht” is. Het artikel is goed bedoeld en vaak ook correct, doch merk ik dat de rol van testers/testmanager zoals omschreven in het artikel niet altijd op een dergelijke wijze werkbaar is bij een klant.
M.a.w. die tester moet draagvlak hebben en faciliteiten tot zijn beschikking hebben, de tester dient zijn afhankelijkheden afgedekt te hebben en dat zijn nu net vaak de dingen die niet of onvoldoende geregeld zijn om een tester optimaal te laten functioneren. M.a.w. wat eerst word aangegeven als de beperking van de tester (kennis, pragmatisme, focus, etc..) is vaak aan de omgeving te wijten en kan niet meteen veranderd worden. Daar komt het aan op kennis verspreiden en ervaringen delen. Voorstellen doen, etc… De tester is een onderdeel in de ontwikkelketting en die ketting is zo sterk als zijn zwakste schakel. Wie of wat dat ook mag zijn… Wel is de tester vaak degene die dat kan signaleren. En daar is volgens mij nog wel een hoop winst te behalen. Conclusie:
De tester doet zijn ding zoals benoemd, maar heeft ook zeker een signalerende en communicerende functie. Maar is wel afhankelijk van zijn omgeving!
Oh ja,… en een echte tester is altijd de investering waard. De vraag is of de omgeving de waarde goed kan benutten.
Goed artikel, doch enkele onwaarheden… en/of discussiepuntjes:
Wanneer een tester geen fouten vind, demotiveert hij de rest van het team?
Dit hoeft niet aan de persoon te liggen, kan een verkeerd gebruik zijn van testtechnieken, testmethoden of testvorm.
Het zou wat erg kortzichtig zijn van projectleden om de schuld van het niet vinden van fouten direct bij de tester zelf te leggen. In de meeste gevallen zal er in de praktijk ook even naar de mogelijke oorzaken gekeken worden. Zo niet dan zijn de leden van het project wel erg kortzichtig.
Euhm, waarom ligt de focus in dit artikel toch zo op het vinden van fouten?
Wat in essentie DE rol van een tester behelst wordt in dit hele artikel min of meer in één zinnetje gekwakt:
“Ze moeten ook helder rapporteren aan het management, om hen inzicht te geven over de software kwaliteit.
Als je als tester aantoont dat jij bijdraagt in het inzichtelijk maken en verhogen van de kwaliteit van het product, dan moeten de specs en de source wel foutloos geschreven zijn, wanneer je echt geen fouten vindt 😉
Overigens wel een opvallende fout voor een artikel over softwaretesten: topgolfers doen geen 27 slagen over 18 holes dan hebben ze in ieder geval 9 hole in ones nodig. Is best lastig.