Besluiten op basis van het "Vier wielen argument"

Hoe neem je een goed besluit? Je wilt een auto, maar niet meer vier wielen. Want vier wielen betekent een 4x zo grote kans op een lekke band. Dus wil je minder dan 4 wielen. Logisch toch? Of je vindt stabiliteit van een auto belangrijk, dus moet de auto minimaal vier wielen hebben. De auto, waar je nu naar kijkt heeft vier wielen. Een duidelijk pluspunt. Logisch toch? Nee, natuurlijk niet. Toch zie ik regelmatig in het testvak dat soortgelijke redeneringen worden gemaakt. Een auto vinden zonder vier wielen zal vast wel lukken, maar maakt de zoektocht onnodig moeilijk. Het allergrootste deel van de auto's heeft nu eenmaal vier wielen. Dat weten we. En daar ligt vaak het probleem: dit soort redeneringen gebeuren alleen als we van een onderwerp eigenlijk te weinig kennis hebben om goede besluiten te nemen. Bij testen voornamelijk op het gebied van ...... testautomatisering en testtools. Wat er zoal gebeurt? Kiezen voor een tool waarbij meteen alles geautomatiseerd wordt: testtechnieken, testscriptbeheer, testautomatisering. Want dit scheelt tijd. Terwijl je nu als bedrijf niet de tijd en/of kennis hebt om handmatige regressietesten te schrijven en te beheren. Dan ga je zeker niet de tijd en/of kennis hebben om alles automatisch te beheren. Niet kiezen voor een automatiseringstool, omdat bij de record-and-play functionaliteit, de opgenomen test later bij Play niet vlekkeloos verloopt. Tja, record-and-play staat bekend om dat soort problemen. Dat is een algemeen probleem, niet specifiek voor een bepaald tool. Kiezen voor een bepaald tool dat de kwaliteit van de website niet alleen meet, maar ook goede verbetersuggesties geeft. Maar deze adviezen worden eigenlijk door de meeste soortgelijke tools gegeven, omdat ze een deel zijn van de gekozen meetmethode, niet van de gekozen tool. En veel tools gebruiken dezelfde standaard meetmethode, dus inclusief bijbehorende suggesties en adviezen. Deze voorbeelden heb ik zelf in de praktijk meegemaakt. Dus ze komen voor. En ik denk dat velen wel andere voorbeelden kunnen aandragen.

Wat is het probleem?

Er blijft nu eenmaal altijd wel ergens een bedrijf dat met testautomatisering begint. Of een bedrijf wat op een ander gebied een tool gaat inzetten om het testen te vergemakkelijken. Daar is natuurlijk niets mis mee. Maar op een of andere wijze hebben dit soort belangrijke keuzes te vaak dezelfde kenmerken. Er is slechts 1 optie Zeggen we ja of nee tegen keuze A? Het idee is namelijk afkomstig van een leverancier, die belde met een goede optie. Of iemand in het bedrijf heeft goede ervaringen met deze mogelijkheid bij een vorig bedrijf. Of het is gewoon de keuze die het best bekend staat in de markt. Geen kennis aanwezig of ingehuurd Er is geen tijd of geld om een externe deskundige in te huren, die op basis van kennis en ervaring een gefundeerde keuze kan maken. Daarom moet je het doen met de middelen/testers, die je tot je beschikking hebt. Mensen die soms nauwelijks kennis hebben van het onderwerp en/of de tools die hiervoor beschikbaar zijn. De keuze moet snel gemaakt worden Tijd besteden aan zaken, die niet direct geld opleveren; men doet het liever niet. Daarnaast wordt de verandering als belangrijk gezien, dus hoe eerder hoe beter. Tijd om meerdere opties te bekijken of om je uitgebreid te verdiepen is daarom nauwelijks beschikbaar.

Wat is de oplossing?

Als de praktijk eenvoudig was, zou de oplossing zijn: vergelijk altijd meerdere tools en neem de tijd ervoor. Of de volgende: huur altijd een expert in. Maar de praktijk is niet altijd eenvoudig, omdat je hierbij afhankelijk bent van factoren waar je geen of weinig invloed op hebt: management en beleid. Dat maakt wel dat het "Vier wielen argument" niet altijd te voorkomen zal zijn. Maar er zijn wel mogelijkheden om de kans flink te verkleinen. Mogelijkheden die weinig tijd en geld kosten. Lees artikelen over het algemene onderwerp Ga via Google op zoek naar artikelen en blogs, die het algemene onderwerp bespreken. En daarbij de problemen, die hierbij naar voren komen, onder de aandacht brengen. Let er wel op dat het onderwerp los besproken wordt. Dus een artikel dat gaat over de problemen, die je tegen kan komen bij het gebruik van Selenium bij testautomatisering, is niet geschikt. Een artikel dat gaat over problemen bij testautomatisering daarentegen wel. Dit helpt je, om na te gaan welke problemen je waarschijnlijk in elk tool tegen zal komen. Omdat ze eerder bij het onderwerp horen, dan bij het tool. Lees vergelijkingen of review sites Om een beeld te krijgen van goede argumenten om wel of niet voor een tool te kiezen, kan je gebruik maken van experts, ook als je ze niet inhuurt. Er zijn op elk gebied wel experts, die in een blog of artikel verschillende tools met elkaar vergeleken hebben. En over bijna alles kan je tegenwoordig wel reviews vinden, vaak geschreven door mensen die wel de gelegenheid hadden meerdere tools te bekijken. Je kan deze gebruiken om het oordeel over 'jouw' tool te lezen. Maar ook om te kijken welke voor- en nadelen hier genoemd worden. Deze kunnen een goede basis vormen voor de keuze, die jij zelf moet maken. Want als deze mensen deze argumenten gebruiken om te vergelijken, is de kans groter dat jij dat zelf ook veilig kan. Vergelijk met een ander gratis tool of tool met een proefperiode Als je wel wat meer tijd hebt, maar niet het geld, kan je toch een vergelijking maken. Veel tools hebben tegenwoordig een gratis uitprobeerperiode. En daarnaast zijn van veel tools tegenwoordig ook goede, gratis en ook meerdere varianten te vinden. Zo kan je zonder extra kosten toch twee tools uitproberen. Dat maakt dat de voor- en nadelen, die jij ondervindt al vergeleken kunnen worden met de voor- en nadelen van het andere tool. Ook als deze tool helemaal geen optie is, zorgt het in ieder geval voor een betere afweging voor de keuze die je wel moet maken. "Ik ben dit probleem ook tegengekomen in tool B, dus de kans is groot dat meerdere tools dit probleem hebben" of "Tool B kan dat ook, dus dat is waarschijnlijk niet de beste afweging om voor A te kiezen".

Ideaal v.s. praktijk

Streef natuurlijk altijd naar het ideaal: meerdere tools met genoeg tijd. Maar als dit niet kan, ben je dan in ieder geval goed bewust dat de voor- en nadelen best wel eens niet specifiek voor deze tool kunnen zijn. Probeer dit op te vangen door te lezen en, als het kan, toch naar andere tools te kijken. Voorkomen is dan misschien niet mogelijk, maar de kans flink verkleinen is vaak wel een realistische optie.

100% dekking bij testen heeft zo zijn gevaren

100% code coverage. Alle eisen hebben een testcase. Er zijn verschillende manieren om na te gaan of iets 100% gedekt is tijdens het testen. En het is een van de meest eenvoudige methodes om na te gaan of de test betrouwbaar is geweest. Alleen is de vraag of de test ook werkelijk betrouwbaar is. Je kan een 100% dekking hebben van iets, maar tegelijkertijd kan de test weinig tot niets toevoegen aan je kwaliteitsgarantie. Hieronder wil ik twee voorbeelden verder uitwerken. Niet met het doel een 100% dekking als onbelangrijk af te doen. Maar wel om mensen verder te laten kijken dan alleen "Heb ik alles getest". Belangrijker is "Heb ik alles goed getest".

Het gevaar van 1 waarde

Stel je hebt een applicatie waarin persoonsgegevens worden beheert. Elke aangemaakte persoon krijgt als standaard geslacht de waarde "Man". En stel dat je nu een test bedenkt of programmeert waar een persoon wordt aangepast. En deze test bevat de volgende regel:

GESLACHT = MAN

Je wil bij deze test dus het geslacht wijzigen naar man. Daarom maak  je snel een persoon aan en ga je daarna de gegevens wijzigen. Dus van de nieuwe persoon wijzig je het geslacht van man naar man. Anders gezegd: je test eigenlijk niets. Want als de wijziging niet opgeslagen wordt, is het geslacht man. Maar als de wijziging opgeslagen wordt ook.

Waar het om gaat is, dat als je een gegeven in al je testen slechts een waarde geeft, de waarde per ongeluk  de juiste waarde kan hebben. Dit is op twee manieren te voorkomen:

1. Controleer voor de wijziging of het betreffende gegeven een een andere waarde heeft

GESLACHT <> MAN

2. Geef  het gegeven tijdens je testen twee verschillende waardes en controleer dit ook tweemaal. Dit verkleint de kans dat de gegevens per ongeluk elke keer opnieuw toch de gewenste waarde hadden.

Het gevaar van condities

Stel je hebt een applicatie waarmee je kortingen berekent. Een van de voorwaarden voor korting is de volgende

LEEFTIJD > 18 OR WOONPLAATS = UTRECHT

Een persoon krijgt dus volgens de code alleen korting als hij ouder is dan 18 en woont in Utrecht. Maar stel nu dat de persoon ook 18 jaar mag zijn, hoe haal je dit dan uit de test? En stel dat de korting eigenlijk alleen uitgevoerd mag worden als de de leeftijd 18 jaar en ouder is, maar ook de woonplaats Utrecht is?

LEEFTIJD >= 18 AND WOONPLAATS = UTRECHT

Met de volgende testcase in ieder geval niet

LEEFTIJD = 20

WOONPLAATS = UTRECHT

 Je hebt nu alles getest. De korting is toegekend. Maar de fouten zitten er nog in.

Stel nu dat je slim bent en je wilt de randgevallen testen. Randgevallen zijn in ieder geval die twee waardes die er net voor zorgen dat de uitkomst anders is. In het geval van 18 jaar en ouder zijn dat dus de leeftijden 17 en 18. De leeftijd 17 geeft geen korting, de leeftijd 18 wel. Nu komt er wel een fout naar boven. Als de leeftijd 17 is, dan krijg je alsnog korting. Verder testen zou aantonen dat ook de leeftijd 16, 15 14 en 13 alsnog korting zouden geven. Dus er moet nog uitgebreider getest worden.

Als er voorwaarden zijn, die de woorden "en" of "of"bevatten (door ontwikkelaar eerder AND of OR genoemd), is het regelmatig handig om hier meerdere testen aan te besteden. Mijn favoriete methode is het aantal condities + 1. Op de volgende wijze uitgewerkt

A AND B AND C

A = TRUE, B = TRUE, C = TRUE => Resultaat = TRUE

A = FALSE, B = TRUE, C = TRUE => Resultaat = FALSE

A = TRUE, B = FALSE, C = TRUE => Resultaat = FALSE

A = TRUE, B = TRUE, C = FALSE => Resultaat = FALSE 

Wat bij de onderste drie testcases gebeurt, is het volgende: ze verschillen slechts 1 waarde met het TRUE resultaat. Hierdoor kan je ervan uitgaan, dat als deze twee testcases het gewenste resultaat geven, het resultaat door de conditie met het verschil veroorzaakt wordt. Daarmee is die betreffende conditie 100% gedekt getest en niet alleen de volledige verzameling condities als geheel. En dat maakt de test een stuk betrouwbaarder.

En de andere variant

A OR B OR C

A = FALSE, B = FALSE, C = FALSE => Resultaat = FALSE

A = TRUE, B = FALSE, C = FALSE => Resultaat = TRUE

A = FALSE, B = TRUE, C = FALSE => Resultaat = TRUE

A = FALSE, B = FALSE, C = TRUE => Resultaat = TRUE 

Als je de grensgevallen en de AND/OR testen combineert, kom je dan op de volgende testcases uit:

LEEFTIJD = 18 AND WOONPLAATS = UTRECHT => Gewenste resultaat is korting

LEEFTIJD = 17 AND WOONPLAATS = UTRECHT => Gewenste resultaat is geen korting

LEEFTIJD = 18 AND WOONPLAATS = AMERSFOORT => Gewenste resultaat is geen korting

Wanneer alle drie slagen, dan kan je ervan uitgaan dat je de eis qua condities voldoende hebt getest.

Hoe voorkom je de "Wet van Murphy"

Soms zijn er van die momenten en dan gaat alles fout. Is net het ene fout gegaan, gaat vlak daarna het andere fout. Als tester kom je de ene na de andere fout tegen. En als de ene fout opgelost is, is er een nieuwe fout ontstaan. Zo niet meerdere fouten. Ik denk dat er bijna geen tester is, die niet een keer in zo'n periode heeft gezeten.

Hoe voorkom je dat alles wat fout kan gaan ook werkelijk fout gaat? Een van de belangrijkste oorzaken van deze situatie is tijdsdruk. Iets moet afgerond zijn voor een bepaalde datum. Dit kan het eind van een sprint zijn of een deadline. Maar het werk is eigenlijk teveel om voor deze datum af te ronden. Dus gaat iedereen op zoek naar manieren om het werk sneller op te leveren. De tijd voor het testen wordt teruggebracht, het lezen van de vastgelegde eisen gaat sneller of wordt overgeslagen. Maar om de planning te halen, moet het wel in een keer goed. Anders haal je het niet.

Voor mijzelf heb ik dit de "Happy flow planning" genoemd. Dit is een geplande werkwijze, waarbij je ervan uitgaat dat alles goed gaat. Daarom is testen en voorbereiden bijna niet nodig. En is er geen tijd nodig om problemen op te lossen. Dit vaak onder de noemer dat een zo ervaren team toch in staat moet zijn om deze klus zonder problemen op te pakken.

Maar de reden dat een ervaren team in staat is om zo'n klus zonder problemen op te pakken, is vaak dat ze niet uitgaan van een foutloos traject. Ze controleren hun eigen werk en laten het door anderen controleren. Ze lezen en bespreken, om te kijken of ze het goed hebben begrepen en hebben onthouden. Dit lijkt in eerste instantie vaak meer tijd te kosten. In de praktijk gaat dit echter sneller of even snel als de "Happy flow planning". Want bijna nooit gaat alles in een keer goed. Waardoor men een nog krappere "Happy flow planning" moet afstemmen. Met nog meer risico en stress. En vaak nog meer fouten. Resultaat: de afgesproken datum wordt niet gehaald met de afgesproken inhoud.

Wat dan? Want soms is er nu eenmaal een einddatum. En soms is er te veel werk. Nu, het belangrijkste is een goede prioritering. Plan datgene wat het belangrijkste is het eerst, maar voer deze activiteiten wel goed uit. Hierbij kan je denken aan onderdelen van een applicatie, bijvoorbeeld eerst zoeken op naam, daarna zoeken op postcode. Maar je kan hier ook denken aan het prioriteren van activiteiten. Denk dan wel aan activiteiten, die de kwaliteit niet in gevaar brengen. En ja, vaak zijn dit toch testactiviteiten. Is het sneller om handmatig te testen, dan automatisch? Test dan handmatig. Is het sneller om de tester te laten testen, dan om een ontwikkelaar te laten testen? Laat de tester testen. Is het sneller om een ontwikkelaar te laten testen, dan een tester te laten testen? Laat een ontwikkelaar testen. Kan je even zonder documentatie, stel het uit.

Het beste is en blijft de functionaliteit zo afspreken dat de einddatum geen probleem is. Maar als dit niet kan, bezuinig dan niet op activiteiten die juist helpen om te garanderen dat de afgesproken einddatum gehaald wordt. Ook al lijkt dit overbodige tijd. Blijf je eigen werk minimaal 1 keer controleren. Laat je werk minimaal 1 keer door iemand anders controleren. En blijf nagaan of je alles goed begrepen hebt. Houdt altijd minimaal deze eisen aan en kijk waar je kan bezuinigen op de rest.

En laat deze situatie een uitzondering blijven. Want als dit vaker voorkomt, kan je doen wat je wil. Maar de "Wet van Murphy" zal uiteindelijk toeslaan. Ook de uitgestelde activiteiten hebben tenslotte hun meerwaarde. Dus op de lange termijn gaat het problemen geven als je ze blijft overslaan. En dat worden uiteindelijk vanzelf heel veel grote problemen heel veel achter elkaar.