mijn kijk op

Mijn visie op: verband paradoxen en illusies met testen

"Wat kunnen software testen, paradoxen en illusies nou werkelijk met elkaar te maken hebben?" Naar mate je echter langer in het vakgebied van software testen hebt gewerkt, weet je steeds beter dat deze soms heel erg nauw aan elkaar gerelateerd kunnen zijn. Dit heeft alles te maken met ons menselijk brein en wat als 'de waarheid' kan worden beschouwd. Dan blijkt soms dat iets dat als een logisch en overduidelijk feit wordt beschouwd opeens meerdere perspectieven heeft. Het is dus goed mogelijk dat er in een informatiesysteem tegenstrijdigheden voorkomen.

Wat is optisch bedrog?

Optisch bedrog is eigenlijk het verkeerd interpreteren van visuele waarnemingen, m.a.w. onze hersenen verwerken informatie die we met onze ogen binnenkrijgen verkeerd.

Wat is een paradox?

Een paradox is een schijnbaar tegengestelde bewering en lijkt tegen onze verwachtingen in te gaan, omdat het vaak berust is op een denkfout of een foutieve redenering. Een bekend voorbeeld van een logische paradox is: "deze zin is niet waar".

De verbanden

Een voorbeeld van een paradox in het werk kan zijn: "Ik test de software vaak volgens vaste procedures, met de wetenschap dat het volgen van andere wegen sneller en effectiever kan zijn". Toch wordt er vaak aan deze procedures gehouden omdat dit verwacht wordt. Stellingen zoals: "Deze zin is niet waar", kunnen net zo goed in programmeercodes geschreven worden als in schriftelijke taal. Zo kan het dus zijn dat er tegenstrijdigheden in software geprogrammeerd worden. Niet alleen kan in het programmeren een paradox ontstaan, ook de methode of manier van testen zelf kan zorgen voor een paradox. In het software testen staat dit bekend als de 'pesticide paradox'. (Als dezelfde testen steeds opnieuw herhaald worden zullen dezelfde testgevallen niet meer dezelfde fouten vinden).

Wat is dan de samenhang tussen optische illusies en software testen? Software wordt vaak gebruikt voor het vastleggen van gegevens over bijvoorbeeld smaak, mening, of voorkeur van zaken. Dit kan in enquêtes, forums, of speciaal daarvoor ontwikkelde software. Het is echter niet mogelijk om per individu na te gaan of hij/zij de aangeboden tekst of plaatjes inschat op dezelfde manier als de makers het bedoeld hadden. Perceptie speelt een grote rol. Zo kan het dus zijn dat bepaalde groepen gebruikers een functie als gemakkelijk ervaren en de software intuïtief vinden, terwijl andere personen het ontzettend lastig vinden om de juiste flow of volgorde te vinden. Paradoxen in software kunnen zowel in code als in functionaliteit bestaan. Om een voorbeeld te geven: zo kan bij accessmanagement bijvoorbeeld de ene rol toegang vereisen voor een gebruiker waarbij een andere rol juist toegang verbiedt. Dit is dan conflicterend wanneer een gebruiker beide rollen toegewezen krijgt.

Precies dit soort gegevens kunnen ervoor zorgen dat verschillende personen met niet dezelfde functies binnen het project, zoals een programmeur of een software tester, in discussie raken over het belang van het oplossen van een bug. Het kan dan zijn dat zij niet hetzelfde plaatje voor zich hebben, maar het bekijken vanuit hun eigen perspectief ("het glas is half vol, het glas is half leeg"). Het is in de eerste plaats belangrijk om elkaar de ruimte te geven om de visie toe te lichten. Zelfs dan kan het nog zo zijn dat beiden ongelijk hebben en er een derde optie is (of juist dat beide stellingen waar kunnen zijn (maar men dit van elkaar niet inziet), zoals in het geval met de welbekende kleur van de jurk die een tijd geleden zelfs het journaal haalde).

De bottom line is: als je in software goede fouten wilt vinden dan is het nodig dat je soms inventief moet zijn en ver door moet kunnen denken over zaken. Een andere goede tip is: zodra je op een softwarefout bent gestuit, kijk dan vooral om deze bug heen, probeer de (nieuwe) opening te gebruiken om nog grotere fouten in de buurt te vinden. Softwarefouten hebben de neiging om zich bij elkaar te groeperen (dit heeft bijvoorbeeld te maken met zaken als 'de dag waarop een programmeur zich ziek voelde' en in een bepaalde module veel fouten maakte. En soortgelijke redenen, maar in ieder geval fouten hebben sterk de neiging om zich te concentreren).

Conclusie

Hoe graag sommige mensen ook willen dat software testen iets academisch is waarvan de methoden, technieken en meetmanieren zaken zijn die vaststaan en altijd op dezelfde manier worden toegepast, is dit allerminst het geval. Net zoals er paradoxen en optische illusies bestaan in het echte leven, spelen deze ook een rol wanneer software getest wordt. Ze zorgen ervoor dat je extra goed en soms out-of-the-box moet nadenken over testgevallen en uitkomsten van testen. Een gefaalde test betekent niet per definitie foute software, net zoals een geslaagde test niet altijd garant staat voor succesvolle software.

Lees verder

• De kracht van functionele testers
• Mijn visie op: de moeilijke aspecten in het software testen
• Software testen in Scrum
• Software testen in ITIL
• Beter software testen in Scrum