Testing, 1… 2… (deel 2)

Ik heb voor mezelf een structuur bedacht waarin ik dit blog in de komende weken ga voortzetten. Op vrijdag zal ik trouw een nieuwe episode uitbrengen van mijn strubbelingen en ervaringen als hartpatiënt, om op maandag over andere onderwerpen die ik wél leuk vind te vertellen. Vorige week heb ik al een korte inleiding gegeven op het testvak en hoe anderen daar tegenaan kijken (hint: niet zo positief).
Vandaag: een stoomcursus testen voor dummies.

Software Testing for Dummies

Zoals ik al zei is het op verjaardagen niet bijster interessant om te vertellen dat je tester bent. Als ik het dan toch een keer vertel, reageren mensen meestal met “oh, okee” om vervolgens niet door te vragen. Laat ik even het beeld schetsen wat er bij gemiddelde digibeet leeft als het om testen gaat. Over het algemeen denken mensen dat testers mensen zijn die ’s ochtends achter hun PC’tje kruipen, een programma opstarten, vervolgens willekeurig op wat knopjes rammen en klagen dat het niet werkt.

De grote vraag is natuurlijk: klopt dit beeld? Ja en nee.
Ik – en mijn collega’s met mij – kruipen ’s ochtends inderdaad achter een scherm om bepaalde dingen te testen. Maar wat is “testen” nou precies? Een goeie vraag. Zo goed zelfs, dat zelfs de grootste goeroes er het er nog niet helemaal over eens zijn. Laten we voor het gemak maar even kijken naar de definitie die het almachtige Wikipedia erover geeft:

“Het testen van software is het vaststellen in hoeverre de software aan de eisen voldoet. Hierbij is het van belang te weten wat er getest gaat worden (het testobject), de eisen, (de testbasis), wanneer er getest gaat worden en hoe er getest gaat worden (methode).”

Ha, moeilijke woorden. Waarschijnlijk raak ik nu een heleboel trouwe lezers kwijt, maar dat is onvermijdelijk. In het kort is het dus zo dat er een ding is dat getest wordt, en dat ergens staat opgeschreven wat dat ding nou precies moet doen. Testobject en testbasis. Neem bijvoorbeeld een computerprogramma als Microsoft Word, iets dat we allemaal wel kennen. Als je Word opstart, dan gebeurt er het volgende: je ziet een opstartschermpje dat laat zien dat Word opgestart wordt, wat na een paar seconden (of minuten, als je het vanaf mijn werklaptop zou doen) weer verdwijnt en dan verschijnt het echte programma voor je neus. In oudere versies van Word kreeg je dan meteen een vel wit papier voor je met een knipperende cursor, zodat je meteen kon gaan typen. In de nieuwste versie moet je eerst kiezen of je een nieuw document wil maken of een bestaand document wil openen.
Waar het hier om gaat is dat er ergens in een groezelig keldertje in de Verenigde Staten iemand heeft opgeschreven dat Word na het opstarten dat lege vel papier moet tonen. Dat wat die persoon heeft opgeschreven noemen we het ontwerp (of, mits goed uitgewerkt, de eisenset). Het ontwerp dient in dit geval dus als de testbasis.
Wat je vervolgens als tester moet doen is controleren of je bij het opstarten ook daadwerkelijk dat lege vel papier ziet. Als je dat op papier zou zetten, ziet het er als volgt uit:

Actie Verwacht Resultaat OK / NOK
Start Microsoft Word op. Microsoft Word wordt opgestart en toont een leeg vel papier met een knipperende cursor.

 

Dit, beste mensen, is de meest versimpelde vorm van een zogenaamd testprotocol. Naast een duur woord is een testprotocol in feite niets meer dan opschrijven hoe een test eruit moet komen te zien. Elke test bestaat grofweg uit een aantal basisdingen:

  • Een of meerdere acties. Dit is iets wat je als tester moet uitvoeren. Voorbeelden zijn het opstarten van een programma, het klikken op een bepaalde knop, een aantal seconden wachten, etc.
  • Een verwacht resultaat. Dit is wat je verwacht dat er gebeurt als je een bepaalde actie uitvoert. Als je op een knop klikt, dan verwacht je bijvoorbeeld dat er een schermpje geopend wordt. Als je op het kruisje klikt, dan verwacht je dat het programma wordt afgesloten. Als je een woord intikt op je toetsenbord, dan verwacht je dat dat woord op het lege vel verschijnt. Als je met een klauwhamer op je duim slaat, dan verwacht je dat je een serie vloeken uitkraamt.
  • Het laatste onderdeel is de beruchte OK/NOK kolom. Hier komt de tester kijken met zijn rode potlood. Hij zet een vinkje in de kolom als het werkelijke resultaat gelijk is aan het verwachte resultaat. Dat wil zeggen: klopt de theorie met de praktijk? Als het verwachte en het werkelijke resultaat NIET aan elkaar gelijk zijn (bijvoorbeeld: er verschijnt geen schermpje als er op de knop wordt gedrukt of er gebeurt iets heel anders dan dat de bedoeling is) dan zet de tester een kruisje – niet akkoord.

In een notendop is dit het grootste deel van de dagelijkse werkzaamheden van een tester: testprotocollen uitwerken, en deze vervolgens ook uitvoeren. Ik hoor jullie nu denken: “Maar Niels, is dat niet een enorme hoeveelheid overbodig werk? Iedereen weet toch dat het programma moet afsluiten als je op het kruisje klikt. Je kunt toch ook gewoon achter je computer gaan zitten en zelf een beetje gaan klikken en met je gezonde verstand zien wat er gebeurt?” Klopt helemaal. Sterker nog, dit is zelfs een bestaande en veel toegepaste testvorm: error guessing, oftewel “het raden van fouten”. Bij sommige bedrijven is dit zelfs de enige toegepaste vorm van testen, maar er kleven een aantal nadelen aan:

  • Als je niks opschrijft, dan zijn de testen niet reproduceerbaar. Weer een moeilijk woord, maar het komt hier op neer: als je vanachter je scherm gewoon maar op wat knopjes gaat rammen, zul je bij een programma in aanbouw vroeg of laat wel ergens een foutje tegenkomen. Je ziet dit voor je, en je roept de programmeur erbij om je beklag te doen. Deze vraagt je vervolgens om alle stappen die je gedaan hebt nog eens te herhalen zodat hij kan meekijken. Zul je altijd zien dat je dan vergeten bent op welke knopjes je allemaal gedrukt hebt en in welke volgorde. Gevolg: je wéét dat er een fout is, maar mensen kunnen hem niet oplossen omdat ze niet weten hoe die ontstaat. Behoorlijk frustrerend voor je collega’s.
  • De testen zijn niet gedocumenteerd. Vooral voor kwaliteitsmanagement is dit een belangrijk dingetje. Als je dingen die je gedaan hebt vastlegt in een dossier, kun je later aan je klant laten zien welke testen je hebt uitgevoerd en wat het resultaat ervan was. Op die manier schep je veel meer vertrouwen in het eindproduct.
  • Regressietesten zijn veel lastiger uit te voeren. De moeilijke woorden houden maar niet op. Regressie betekent letterlijk “teruggang”. Verwar dit niet met recessie (achteruitgang) maar letterlijk met teruggaan naar testen die je al eerder hebt uitgevoerd. Waarom zou je dit dan doen? De voornaamste reden hiervoor is dat een computerprogramma – als het steeds groter wordt – langzaam uitgroeit tot een soort van huis waarin alles met alles in verbinding staat. Stel je eens voor dat je een dag in de keuken aan het sleutelen bent geweest, en dat je dan na afloop ineens merkt dat je badkamer blank staat en je nóg een dag moet klussen om dat probleem weer op te lossen. Wat je met regressietesten dus doet is voortdurend naar je badkamer lopen om daar wat testjes uit te voeren zodat je zeker weet dat deze niet onderloopt. Dit is veel makkelijker als je van tevoren opschrijft wat je precies gaat testen.

Kortom: het opschrijven van testprotocollen is één van de belangrijkste taken van een tester. Een goed en duidelijk testprotocol kan de kwaliteit van het eindproduct enorm verbeteren. Het nadeel is dat het opstellen van de protocollen tijd kost. Véél tijd. Sterker nog, het opstellen van het protocol kost vaak veel meer tijd dan het uitvoeren ervan. Dat is dan ook de meestgehoorde klacht onder managers als het om testen gaat: het kost zoveel tijd en geld. Waarom is dat nou zo? In mijn volgende blog vertel ik daar meer over, als ik kom op het volgende hoofdstuk in mijn stoomcursus testen: hoe schrijf je een test?

Testing, 1… 2… (deel 2)

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *