"Dat doen onze gebruikers niet" - Het belang van betrouwbaarheid bij testen

De meeste testers zijn wel voor goed geprioriteerd testen. En dat mag zeker op basis van een goede risico-analyse. En zeker geen onbelangrijk onderdeel van zo'n risico-analyse is: Hoe vaak wordt deze functie op deze manier gebruikt? Veel tijd besteden aan het testen van een functie, die nauwelijks gebruikt wordt, zal vaak onverstandig blijken. En uitgebreid gegevens invoeren, die in werkelijkheid nooit ingevoerd zullen worden, is vaak ook niet het meest nuttig. Wel moet je hierbij stilstaan bij een factor: er is een groot verschil tussen niet testen en minder testen.

Ik heb zelf regelmatig als tester te horen gekregen, als ik een fout vond: "Maar dat doen onze gebruikers niet." Wat inhield dat ik mijn tijd aan het verspillen was. Want hoeveel fouten ik ook zou vinden, hoe ernstig ze ook zouden zijn, ze zouden toch niet worden opgelost. De gebruiker zal ze niet tegenkomen, dus er zullen geen klachten over komen, dus men kan de tijd wel beter besteden. Ik kon mijn tijd wel beter besteden.

Testen heeft meerdere doelen. Maar het doel om de applicatie te laten werken, zoals je gebruikers dat nodig hebben, is zeker een hele belangrijke. Juist als functionele tester, wil ik eigenlijk altijd een stapje verder gaan. Bij mij is betrouwbaarheid altijd een zeer zwaar meetellende factor. Als een gebruiker plotseling een uitzonderingssituatie invoert, moet de gebruiker niet opeens grote fouten tegengekomen. Als er een nieuwe gebruiker is, die net even anders werkt, moet de applicatie niet opeens onwerkbaar blijken te zijn. En als een nieuwe klant of afdeling ook de applicatie gaat gebruiken, moet deze niet opeens onder je vingertoppen omvallen. Hoe je de applicatie ook gebruikt, er mogen eigenlijk geen grote fouten inzitten. De gebruiker moet altijd op de applicatie kunnen vertrouwen. Dus als iets oplossen of testen de moeite niet waard is, omdat onze gebruikers dat toch niet doen? Dan heb ik liever dat je die functionaliteit of situatie verwijdert, dan dat je er een grote fout in laat zitten.

Het doel van een goede functionele test is het streven naar goede kwaliteit. Kwaliteit, die zo min mogelijk afhankelijk is van nu, van de huidige gebruikers, van de huidige klanten en/of afdelingen. Je testen moeten daarom ook zeker niet alleen gericht zijn op de meest voorkomende situaties. Maar juist ook op de "nu misschien nog niet, maar je weet maar nooit" situaties. Hier hoeft niet 90% van je testtijd in te zitten, maar 0% is te weinig. Een goed evenwicht vinden, dat is en blijft het streven.

Agile Review - Wanneer is het logsich? Wanneer weet iedereen het?

De ouderwetse review van documenten was duidelijk: alles moest erin staan. Als je iets miste, voegde je het toe. Niemand deed het graag, maar er was nauwelijks discussie mogelijk. Toen kwam Agile en daarmee de reden om minder te documenteren. Argumenten die vroeger bij een review niet van toepassing waren, worden nu opeens belangrijk. Nu hoor ik bij een review vaak argumenten als: "Maar dat is toch logisch?" en "Maar dat weet iedereen toch?". Hoe Agile deze argumenten ook klinken, te vaak heb ik meegemaakt dat juist deze argumenten kunnen leidden tot niet werkende software. Omdat wat de schrijver logisch vond, voor de bouwer onlogisch was. En wat bij de schrijver bekend was, bij de bouwer niet bekend was. Juist binnen Agile is een goede review door een objectief persoon van groot belang. Maar ook een stuk moeilijker. Want wat voor criteria kan je gebruiken om te bepalen wat bekend is en wat niet?

Ervaring van het team

Ervaring van het team is de meest logische om mee te nemen in je review. Wanneer je een team hebt, wat al jaren aan de software werkt, dan kan je rustig van heel veel kennis uitgaan. Standaard berekeningen zullen bekend zijn. En standaard uitzonderingen zullen automatisch worden meegenomen. Zo zal iemand werkend aan verkoop binnen de vervoerssector waarschijnlijk uit zijn hoofd de meeste vervoersabonnementen op kunnen noemen. Met de meest belangrijke kenmerken voor de prijsberekening. Dit vermelden zal dan vaak niet nodig zijn. Heb je echter een team met veel mensen die de software nog maar kort kennen, zal je meer moeten vastleggen. Ze zullen geholpen moeten worden, door alle belangrijke situaties en uitzonderingen te noemen. Want zelf zullen ze er niet zo snel bij stilstaan.

Achtergrond van het team

Je staat er soms niet bij stil hoeveel kennis als Nederlander vanzelfsprekend is. Een postcode heeft vier cijfers en twee letters. Een telefoonnummer bestaat standaard uit 10 cijfers. Volwassenen zijn 18 jaar of ouder. Ouderenkorting is bijna automatisch 65+. In een Nederlands team kan je dit rustig als bekende informatie beschouwen. Maar in een internationaal team, wat steeds vaker voorkomt, zijn dit zaken waar je bij stil moet staan. Is bij iedereen in het team een volwassenen dezelfde groep personen? En worden de invoercontroles bij een adres niet te ruim of juist te krap vastgelegd, als je die niet hebt vastgelegd?

Frequentie van aanpassing

Wat echter zeer regelmatig vergeten wordt, is de frequentie van aanpassing. RFS's en/of story's worden regelmatig door mensen geschreven die dagelijks, en anders zeer regelmatig, te maken hebben met een bepaald scherm, een bepaald rapport of een bepaald proces. Zelfs als dit niet het geval is, heeft de schrijver vaak al weken een bepaald onderdeel bekeken en geanalyseerd. Zijn kennis van dit onderdeel is zo groot, dat wat voor hem logisch is en algemene kennis is geworden, voor anderen zeer onbekend kan zijn. Dit gebeurt dan ook vooral bij onderdelen in de applicatie, die bij bedrijven zeer vaak of zeer intensief gebruikt worden, maar nauwelijks worden aangepast. 

Denk bijvoorbeeld aan het invoeren van uren door medewerkers in het bedrijf. Dit proces zal bij iedereen in het bedrijf zeer bekend zijn. Urenregistratie is echter ook vaak een proces, wat niet zo vaak verandert. Ontwikkelaars hebben misschien al jaren niet meer aan dit onderdeel gewerkt. Dus dan kan het zijn, dat "Voer een extra controle in voor de manager" voor de schrijver automatisch betekend, dat zowel de tweestapscontrole als de driestapscontrole met een stap moet worden uitgebreid. Terwijl de ontwikkelaar niet eens weet dat er ook een driestapscontrole is.

En misschien is er nog meer...

Wat het belangrijkste is bij een review, zeker nu, is dat je de lezers kent. Dat je hun kennisniveau en hun achtergrond kent. Dat je weet hoe ze werken en bij voorkeur hoe ze lezen. Als het even kan, weet je ook precies hetzelfde van de schrijver. Zodat je ook de verschillen weet tussen de kennis van de lezer en de kennis van de schrijver.

Juist het verschil in kennis tussen lezer en schrijver wordt steeds belangrijker, wanneer je niet meer alles tot in de puntjes vastlegt. Wat voor verschillen dit ook zijn. Het maakt de review misschien een stuk moeilijker. Maar tegelijkertijd ook een stuk uitdagender.