Het verschil tussen het testen van specificaties en het testen van kwaliteit

De software voldoet aan de vastgestelde specificaties. Maar toch zijn de klanten ontevreden. Niet omdat ze wat anders hadden gewenst, dat is een ander onderwerp. Nee, omdat de software gewoon niet goed werkt. De kwaliteit is niet voldoende. Misschien kent niet elke tester deze situatie, maar hij komt zeker voor. De situatie van een test die 100% slaagt, maar de werkelijke kwaliteit niet kan constateren.

Wat je hier tegenkomt is vaak het verschil tussen het testen van specificaties en het testen van de kwaliteit. Bij het testen van de specificaties is datgene wat letterlijk op papier is gezet ook getest. En dat werkt. De tester heeft het goedgekeurd en de klant heeft het goedgekeurd. Wat niet is getest, is datgene wat niet op papier is gezet. Maar wat achteraf toch van belang blijkt te zijn.

Nu kan je als tester zeggen: "Tja, dan had je het maar in de specificaties moeten opnemen". Maar een echte Agile tester weet dat dit niet terecht is. Het is juist de bedoeling om de hele grote, volledig uitgeschreven documenten terug te brengen. Juist omdat deze uitgebreide documenten misschien wel volledig waren, maar net zo min correct. En zeker niet geschikt om flexibel te wijzigen. Waar dit probleem nu veroorzaakt wordt door iets wat niet in de specificaties stond, werden dit soort problemen daarvoor veroorzaakt doordat informatie anders of zelfs tegenstrijdig in de specificaties stond. Of omdat mondelinge overleggen allang de officiële specificaties hadden gewijzigd, maar die informatie weer niet goed was vastgelegd.

Natuurlijk zijn er grenzen aan wat  je kan testen, als het niet is vastgelegd. Maar naar mijn mening moet je juist als Agile tester (waar iedereen verantwoordelijk is voor het volledige eindproduct) je verantwoordelijk voelen voor de kwaliteit, ongeacht of deze automatisch volgt uit de specificaties of niet.

Wat staat er dan niet in de specificaties?
Specificaties beschrijven meestal minimaal wat de klant of wat het bedrijf zelf wil, gedacht vanuit de verschillen tussen de huidige situatie en de nieuwe, gewenste situatie. Wat staat er dan niet altijd beschreven? Wat maakt het verschil tussen de specificaties en de kwaliteit?

1. Standaard functies
   Knoppen als Nieuw, Opslaan, Verwijderen en Annuleren hebben functionaliteit, die vaak als bekend wordt beschouwd. Ze kunnen dan ook in specificaties afgedaan worden met: De knop X is aanwezig. Als ze al genoemd worden. Maar elk van deze knoppen heeft zijn eigen specifieke testen, om na te gaan of ze goed werken. En dat moet ook getest worden, ongeacht of dit officieel vermeldt staat.
   
2. Foutafhandeling
   Hoe de wijziging moet werken staat meestal wel goed beschreven. Wat de applicatie moet doen, als de gebruiker iets fout doet, niet altijd. Dit is echter ook belangrijk. Het opvangen van foute invoer of verkeerde handelingen, inclusief testen op goede en duidelijke foutmeldingen, kan een heleboel problemen bij de gebruiker voorkomen.
   
3. Andere schermen met dezelfde functionaliteit
   De wijziging wordt vaak beschreven vanuit een bepaald scherm, namelijk het scherm waar de wijziging gewenst is. Maar met grote regelmaat komt dezelfde functionaliteit ook in andere schermen voor. Zo kan het aanmaken van een werknemer bij het invoeren van een contract beschreven worden. Tegelijkertijd wordt een werknemer ook aangemaakt in een algemeen onderhoudsscherm voor werknemers. Als voor het contract bij de werknemer extra gegevens worden toegevoegd, moeten deze ook in het algemene onderhoudsscherm worden toegevoegd. Dus is de vraag: heeft de beschreven wijziging effect op soortgelijke functionaliteit in andere schermen?
   
4. Andere varianten van dezelfde businessrules
   Je businessrules kunnen soms heel ingewikkeld worden. Een beroemd en berucht voorbeeld hiervan is de berekening van een totaalbedrag in de factuur. Er kunnen heel veel varianten zijn om tot een bepaald bedrag te komen, afhankelijk van instellingen en ingevoerde gegevens. Als hier een wijziging wordt voorgesteld, kan dit effect hebben op de andere varianten. Het kan zijn dat een situatie een uitzondering moet zijn op de nieuwe regel. Het kan zelfs zijn dat een andere variant niet meer mogelijk is, door de nieuwe wijziging. En je kan gewoon per ongeluk iets kapot maken in de bestaande situaties, door je huidige aanpassing.
   
5. De wijziging in het gehele bedrijfsproces
   Stel je wijzigt het adres door het adres veld op te splitsen in straat en huisnummer. Dit kan een niet zo'n grote wijziging lijken, totdat je verder het gehele bedrijfsproces bekijkt. Dit adres wordt getoond op heel veel rapporten en vaak ook op andere schermen. Bij elke wijziging is het daarom van belang, zeker als je gegevens wijzigt, na te gaan of deze wijziging ook effect heeft op stappen verderop in het proces.

Ervaren testers kunnen waarschijnlijk nog meer groepen noemen. Maar op basis van mijn ervaring zijn dit de meest belangrijke.

Test kwaliteit, niet specificaties

Probeer altijd als een testers te helpen bij het opleveren van een goed product en kijk daarom niet alleen naar de specificaties. Kijk of de wijziging effect heeft of zou moeten hebben op niet genoemde onderdelen in de applicatie. En kijk of je meer moet testen, dan er letterlijk beschreven staat. Dit zal niet altijd makkelijk zijn, maar enkel al het streven kan een hele grote verbetering zijn.