Het verschil tussen een incident en een probleem

Dan kom je plotseling in een situatie. De fouten nemen toe en je hebt geen idee waarom. Je wilt als tester natuurlijk kwaliteit. Dus je wil er wat aan doen. Maar hoe? Want als je rondvraagt, is er geen duidelijke oorzaak. Er zijn incidenten, zeker. Zaken die is een keer fout gaan. Een Opslaan knop die een keer niet werkt. Typefouten in een ander scherm. Allemaal zaken die kunnen gebeuren. Maar wanneer wordt een incident nu werkelijk een probleem dat aangepakt moet worden? Hoe herken je dat? Wanneer is het te vroeg om aan de bel te hangen en wanneer te laat?

Voor mij ligt de magische grens bij 3 keer. Twee opleveringen achter elkaar met meer fouten dan anders, dat kan. Drie opleveringen met meer fouten dan anders, dat kan bijna geen toeval meer zijn. Het kan nog steeds, natuurlijk. Maar de kans is zo klein, dat dit een onderzoek waard is. De grootste fout die Agile teams maken, is het geloof dat het de volgende keer beter gaat. Na de eerste keer, na de tweede keer, na de derde, vierde, vijfde, zesde, zevende keer. Elke keer is de laatste keer, want elke keer had zijn eigen unieke redenen waarom het fout ging. Maak als tester niet dezelfde fout en bepaal voor jezelf een grens. Dit hoeft geen 3 te zijn, maar ga niet al te hoog.

Maak het meetbaar

Probeer voor jezelf als tester ook een kwaliteitscriterium te ontwikkelen. Bijvoorbeeld 3 bugs per storypoint of 10 bugs per story. Makkelijk te meten criteria. Als je ze niet weet, tel dan gewoon een keer hoeveel bugs je binnen een sprint hebt per story, per storypoint of een soortgelijke eenheid. En kies op basis hiervan een meetlat die goed voelt. Rond hierbij de eerste keer ruim naar boven af. Je kan hem altijd bijstellen. Maar zorg er in ieder geval voor dat je kan beoordelen of de kwaliteit van het opgeleverde werk slechter was, dan het team kan leveren.

Stel je criterium ook bij. Wanneer je team beter gaat functioneren, zal het aantal bugs ook afnemen. Stel je hebt 10 bugs per story en je team haalt al drie sprints achter elkaar max. 7 bugs per story. Stel je criterium dan bij naar 8 bugs. Slechte kwaliteit kan in de loop van de tijd veranderen. Maar stel je grens bij voorkeur niet naar boven bij. Zelfs als je de oorzaak niet aan kan pakken, zoals bijvoorbeeld een deadline, is het goed om een middel te hebben om de gevolgen vast te leggen.

En analyseer

Maar dan heb je je kwaliteitsmeetlat. En deze is drie keer overschreven. Wat dan? Vaak is er wel degelijk een oorzaak. Als je maar door de incidenten heen wilt kijken. Als je, ondanks de bomen, toch het bos wil zien.  Plan dan een uur in na een bepaalde sprint of andere logische periode en ga rekenen. Ga per oorzaak tellen en kijk waar er een duidelijke piek is in bugs.

Kijk eerst naar de volgende drie oorzaken

De ontwikkelaar kon de bug niet zelf vinden, omdat de test die hiervoor nodig was door hem niet uitgevoerd kon worden
Denk hierbij aan een interface, die voor de ontwikkelaar niet op te roepen is. Een testomgeving, die niet beschikbaar is. Een testdatabase, die niet voldoende of representatieve data bevat voor een goede test. Alles waardoor een ontwikkelaar terecht kan zeggen: "Ik kan dit niet testen". Deel deze groep niet op, zodat je losse incidenten krijgt. Dus de ene keer was de testomgeving een week niet beschikbaar, een andere keer was een interface in onderhoud. Dit valt allemaal onder testomgeving management. En als daar een probleem is, keert dit in verschillende manieren terug. Maar het is hetzelfde hoofdprobleem.

De ontwikkelaar test niet goed
Hoewel in de ideale wereld een Agile team zelf de planning bepaalt, is het in de praktijk vaak zo dat de wereld niet ideaal is. Er is een krappe deadline. Er is per sprint de behoefte om zoveel mogelijk op te leveren. Deze oorzaak is simpel om te herkennen. Als je aan een ontwikkelaar vraagt, waarom de kwaliteit zo slecht is, krijg je het volgende antwoord: ik had de tijd niet om te testen. Maar er is ook een andere variant, waardoor de ontwikkelaar niet goed test, namelijk het argument: daar is de tester voor. Bij een kwaliteitsverslechtering is er meestal sprake van een gevoeld tijdsgebrek, omdat het afschuiven van testen op de tester al vanaf het begin gedaan wordt. Maar wees er bedacht op dat beiden kunnen voorkomen.

De informatie is inconsistent
Een van de meest voorkomende problemen, is dat afgesproken wijzigingen in een lijst onder elkaar staan. Met bij voorkeur vragen, antwoorden, voorstellen en reacties door elkaar. Maar wat ook een probleem kan zijn, is dat je informatiebronnen niet consistent zijn. In je functioneel ontwerp staat een veld, wat in het design van de user-interface niet genoemd staat. Of in de story staat een veld genoemd, waarvan de gegevens in het ontwerp van de technische interface niet genoemd staat. Deze situatie is ook heel eenvoudig te herkennen. Als je een ontwikkelaar wijst op een bug, krijg je te horen: "Maar ik heb gebouwd zoals het in document x stond" of een soortgelijke zin.

Als je met een van deze drie oorzaken de toename van je bugs kan verklaren, stop dan met analyseren. En maak dit onderwerp bespreekbaar in je team.  Belangrijk is steeds opnieuw: deel deze bovenstaande groepen niet op. Als er een probleem is in een van deze groepen, kan deze zich op allerlei wijze tonen. Maar het grote probleem blijft gelijk: testomgeving management, verkeerde verhouding testen ontwikkelaars v.s. tester of informatie management. Maak het grote probleem op tijd bespreekbaar en laat je niet meepraten naar "maar dit is anders" argumenten. Hoe verleidelijk soms ook. En hoe logisch het soms ook klinkt.

Gewoon een kwestie van tellen

Als een van de drie nu niet de oorzaak is, dan is het gewoon een kwestie van tellen. Neem in een sprint de bugs en kijk vervolgens naar de volgende aspecten:

• Welke ontwikkelaar
• Welk onderdeel in de applicatie
• Welke laag in de applicatie (database, technische interface, user interface, business logica, enz.)

Kijk vervolgens ook naar het aantal story's of bij voorkeur storypoints per ontwikkelaar, onderdeel en applicatielaag. Als een bepaalde ontwikkelaar, onderdeel of laag duidelijk meer bugs per story of storypoint heeft, kijk dan eerst of er een eerste logische oorzaak is. Denk hierbij vooral aan tijdsgerelateerde zaken. Bijvoorbeeld een story die ruim zwaarder was dan de anderen. Of een in storypoints ruim onderschatte story. Wanneer dit niet het geval is, is de kans groot dat je de belangrijkste oorzaak gevonden hebt.

Hoe verder

Als er sprake is van een onderdeel of een laag waarin zich veel fouten voordoen, bespreek ze dan met het gehele team. Mijn ervaring is, dat het team meestal vrij snel aan kan geven wat het probleem is. Kennisgebrek en zelfoverschatting zijn de meest voorkomende, maar worden door de ontwikkelaars zelf vaak vrij snel onder ogen gezien. Kan je als team de oorzaak niet achterhalen, spreek dan af om story's in dit onderdeel als team beter te bewaken.

Is er sprake van een ontwikkelaar, die duidelijk meer fouten maakt, bespreek dit dan onder vier ogen. Maak er geen zondebok kwestie van. Mijn basishouding naar ontwikkelaars is altijd: elke ontwikkelaar wil goed werk leveren. En hoewel deze echt niet altijd juist blijkt te zijn, is die ruim voldoende waar om als startpunt te houden in mijn communicatie met een ontwikkelaar. Ook hier zal de ontwikkelaar vaak zelf de oorzaak aangeven. En ook dit komt vaak neer op kennisgebrek en zelfoverschatting. Als deze dat niet kan, vraag dan samen hulp aan een andere ontwikkelaar. Een die dezelfde programmeertaal spreekt en bij voorkeur meer ervaren is.

En dan is er de kans dat je de oorzaak niet vindt. Ga dan door en tel de volgende sprint weer. Mogelijk ontstaat na twee of drie of vier sprints wel een beeld van de oorzaak. En blijf het kwaliteitsprobleem bespreken met het team als geheel. Want hoe uitgebreid mijn lijst ook is, mogelijk weet jij of iemand anders in je team een oorzaak die hier niet in genoemd staat. Maar die wel voor jouw project een groot probleem vormt voor de kwaliteit. Het tellen blijft gelijk. En het onderscheiden van incident en probleem ook. Blijf beseffen dat teveel incidenten echt wijzen op een probleem en niet op heel veel pech.

Agile testen voor beginners

Echt goed exploritory testing is moeilijk en vaak voor gevorderden. Testtechnieken zijn vaak moeilijk om te leren en om toe te passen in een Agile omgeving. Dus wat doe je met iemand zonder testervaring, die in het Agile testvak wil beginnen?

Waar het bij Agile testen om gaat, is vaak om een testmethode te hebben, die flexibel is. Die geen tot weinig voorbereiding vraagt en in allerlei situaties toegepast kan worden. Dat maakt exploritory testing ook zo populair. Maar er zijn ook manieren van testen, die snel te leren zijn, weinig voorbereiding vragen en toch flexibel zijn. Drie die ik zelf veel gebruik, zal ik hier beschrijven.

De CRUD test (Create Read Update Delete)

Deze officiële techniek werkt simpel. Je creëert iets, bijvoorbeeld een medewerker, en controleert of de gegevens goed zijn. Je past het aan en controleert of de gegevens goed zijn. Je verwijdert het en controleert of de verwijdering juist heeft plaatsgevonden. Kijkend naar een website of applicatie is het bijna een kwestie van het vinden van de Nieuw, Opslaan en Verwijder knoppen om deze testen uit te voeren. Dat maakt dat er nauwelijks voorbereiding nodig is. En het leertraject is vrij snel.

Een voorbeeld:
Stel je hebt een website waar een persoon een rekening kan openen, wijzigingen kan doorgeven (b.v. aangeven hoeveel je rood mag staan) en de rekening kan opheffen. Dan heb je vervolgens 1 testcase, waarbij je een rekening opent (Create). Je opent een rekening en vervolgens vraag je de rekening opnieuw op en controleer je of alle gegevens correct zijn. (Read). Hierna wijzig je b.v. het bedrag dat je rood mag stan (Update). Dan vraag je opnieuw de gegevens van de rekening op (Read) en controleer je of het bedrag dat je rood mag staan goed is weergegeven. Als laatste hef je de rekening op (Delete) en kijk je of de rekening nog op de website getoond wordt (Read).

De checklist

Vaak is er op een of andere manier sprake van een lijst met eisen. Als de lijst werkelijk een opsomming is, heb je meteen een checklist die je kan gebruiken. Is er sprake van een stuk tekst, dan is dit wat moeilijker. Je kan van de stuk tekst dan een opsomming maken. Maar je kan ook gebruik maken van een marker. Markeer de stukken tekst die je getest hebt of die je niet hoeft te testen. Als de volledige tekst gemarkeerd is, dan is de test afgerond. Kan het simpeler en sneller?

De gegevens test

Dit is geen officiële techniek, maar heel eenvoudig toe te passen. Op bijna elk scherm staan invoervelden of gegevens die data bevat. Als er geen invoerveld is, maar er staan wel gegevens op het scherm, dan kunnen deze gegevens ergens gewijzigd worden. Voor alle invoervelden en andere gegevens kan je eenvoudig de volgende testen uitvoeren

• Elk gegeven moet minimaal twee waarden hebben gehad
  Dit is om te testen of een bepaald veld steeds dezelfde standaard waarde toont. Ja, ik heb echt meegemaakt dat een vrouw werd opgeslagen en veranderde in een man.
• Elk gegeven moet minimaal een waarde met de maximale lengte hebben gehad
  Hiermee controleer je of de maximale waarde ook wordt aangehouden bij de invoer, maar daarnaast of dit gegeven op andere schermen netjes wordt weergegeven. Gaat bijvoorbeeld de tekst niet over een andere tekst heen als de maximale lengte van een veld wordt gebruikt. Als er sprake is van een keuzelijst, kies dan de langste waarde.
• Elk gegeven moet minimaal een keer leeg gelaten zijn
  Hiermee controleer je soms verplichte gegevens goed gecontroleerd worden. Maar bij niet verplichte gegevens controleer je of de applicatie goed omgaat met lege velden. Echte fouten die ik ben tegengekomen, zijn:
  - Twee spaties tussen voor- en achternaam, omdat tussenvoegsel leeg was.
  - Een technische veldnaam de de locatie waar anders het gegeven had gestaan
• Elke lijst moet minimaal getest zijn met 0, 1 en 3 waardes
  Dit is eigenlijk een variant van de bovenstaande testen, maar dan voor een lijst. Controleer of de applicatie goed omgaat met lege lijsten. Controleer of de lijst 1 waarde goed toont. En controleer of de lijst goed omgaat met meerdere waardes.

Alleen het leeg laten zal niet altijd mogelijk zijn, omdat sommige invoervelden verplicht zijn. Daarom zal je sommige gegevens op sommige schermen niet leeg kunnen tonen. Voor de rest is alles bruikbaar voor elk scherm.

Uitwerking:
Stel je hebt een applicatie waar je de straatnaam in kan voeren. De straatnaam mag maximaal 50 karakters bevatten. In dit geval gebruik je bijvoorbeeld de volgende waardes:

Twee waardes: Johan de Graafplein, Pieter Poter Plofkade
Maximale lengte: 12345678901234567890123456789012345678901234567890
Leeg: Waarschijnlijk is dit een verplicht veld, dus je zal hier controleren of er een melding verschijnt

Dit is slechts een start

De beschreven testen zijn slechts een start. Ze zorgen al vrij snel voor een bruikbare test van een applicatie of website. Terwijl de leercurve en voorbereiding laag is. Er missen nog zaken, zoals ketentesten en het goed testen van beslisschema's. Maar met deze testtechnieken kan je elke beginnende tester vrij snel waardevol inzetten. Zonder Agile testen te maken tot een ouderwets keurslijf of een taak alleen geschikt voor ervaren testers.

Test je testtools

Voor testen gebruik je al vrij snel hulpmiddelen en applicaties. Vaak om je testen te automatiseren, maar ook om je bij het testen te ondersteunen. Steeds vaker gebruiken we dan wat anderen ook gebruiken. Wat we op internet kunnen vinden bovenaan de Google lijst. We gaan ervan uit dat deze tools werken. En dat de tools voor ons zullen werken. Mijn ervaring: dit is niet altijd het geval. De oplossing: test je testtools, voor je ze invoert.

Mijn ervaring met testtools is zeer positief en zeer negatief tegelijkertijd. Bij het testen voor mobiele telefoons is het zoveel eenvoudiger om simulatoren en emulatoren te installeren dan om echte telefoons te kopen. Totdat een knop op een mobiele telefoon niet werkt. En de knop deed het toch echt op de simulator. Of in een andere situatie: je komt er tot je verbazing achter dat een tool plotseling resultaten niet meer toont. Omdat jij een weergave wil in tekst en het tool voor je besluit dat HTML een betere optie is (ja, echt gebeurd). Maar ze kunnen je flink tijd en geld besparen. Een simulator kan vrij risicoloos gebruikt worden om het testproces te versnellen, omdat je deze op elke laptop beschikbaar kan maken. Mits je ook besluit aan het eind op een echte mobiel te testen. En als je 95% van de tijd je gewenste tekstweergave krijgt, kan je voor die 5% HTML wel een iets mindere ideale oplossing vinden.

Om nu grote problemen bij gebruik te voorkomen, is het verstandig om te weten waar je een tool voor wil gebruiken. Neem bijvoorbeeld de volgende vragen:

• Hoe betrouwbaar moet het zijn? Wil je een nauwkeurige test of gaat het vooral om een indruk te krijgen?
• Is het als hulpmiddel bedoelt, ter aanvulling van een bestaande testwijze? Of moet het echt een andere testwijze gaan vervangen? Dit kan weer effect hebben op de benodigde betrouwbaarheid.
• Wil je de test eenmalig uitvoeren om de kwaliteit te bepalen? Of is het tevens een controle middel om de kwaliteit te bepalen over langere tijd, zoals een regressietest? Bij de tweede keuze zijn de eisen voor het vastleggen van gegevens hoger dan bij de eerste.
• Wat zijn je eisen? Welke browsers, programmeertalen, operating systems, databases, enz. moet het kunnen ondersteunen?
• Hoe flexibel moet de tool ingezet kunnen worden? Vaak te lezen als: hoe groot is de kans op verandering in de organisatie? Hoe flexibeler je tool moet zijn, hoe meer je organisatie verandert, hoe verstandiger het is om de eisen ruimer te trekken dan b.v. de programmeertalen die je nu gebruikt of de browsers die je nu ondersteunt.

Dan komt de werkelijke test: probeer je tool uit. Bedenk een eenvoudige testsituatie, die wel overeenkomt met een test die je vaak tegenkomt. En misschien moet je er zelfs meer bedenken. Kijk met behulp van deze testsituatie of je tool aan de eisen voldoet. Vertrouw niet op teksten als "Deze applicatie is zowel in IE als in Firefox te gebruiken". Als dit voor jou belangrijk is, gebruikt het dan zowel in IE als Firefox. Mogelijk zijn de aangeboden functies in een van beide minder uitgebreid.

Om dit duidelijk te maken, een kleine voorbeelduitwerking. Stel je hebt vaak websiteprojecten. Hierbij is performance een belangrijke graadmeter. Performance testen heeft zeker de voorkeur, maar dit kan vaak pas aan het eind en kost vrij veel tijd. Nu heb je gehoord van standaarden als PageSpeed, die via regels en berekeningen een performancescore geven van een pagina op de website. Deze standaard wordt door verschillende tools ondersteunt en ze lijken allemaal even goed.

Omdat Performance voor jou belangrijk is, wil jij een tool dat werkelijk kritisch is. Nu zou je denken dat, uitgaande van een standaard, de score, ongeacht tool, gelijk zouden zijn. Hier kan je blind van uitgaan of je kan dit controleren. Onderstaand het resultaat van een test die ik zelf heb uitgevoerd t.b.v. deze blog. De waardes zijn dus niet verzonnen, maar werkelijk gemeten met behulp van de gekozen website.

Als je weet dat de pagina bij een hogere score als een pagina met een betere performance wordt beschouwd. En je eis is om een zo kritisch mogelijk tool te kiezen. Welke van de bovenstaande hulpwebsites zou je dan niet kiezen?

Waar het op neer komt: vertrouw niet blind op verkooppraatjes, reviews, tips of standaarden. Probeer zelf de tools uit en kijk hoe ze voor jou werken. En kijk hierbij vooral naar datgene wat voor jou belangrijk is. Want wat een goede keuze is voor een ander, kan voor jou de verkeerde keuze zijn.