zondag 14 februari 2021

'Dit is geen bug' of 'Hoe je problemen kan ontkennen'

Je zou denken, dat als iedereen vindt, dat een applicatie iets doet, wat niet zou moeten gebeuren, er weinig reden is tot discussie. Er is sprake van een bug. Gelukkig werkt dat vaak ook zo. Maar soms niet. Soms grijpt men terug naar een oud gebruik: de schuld is niet de applicatie. Nee, de schuld ligt bij de gebruiker of bij de klant.

Wat er hier gebeurt? Een gebruiker kan iets doen in de applicatie, wat niet mogelijk zou moeten zijn. En als gevolg hiervan, doet de applicatie iets ongewenst. Dit kan iets kleins zijn, als een verkeerde tekst tonen. Maar de applicatie kan ook een belangrijk proces blokkeren. Hoe dan ook, je kan hier op twee manieren mee omgaan. Je kan vinden, dat de applicatie dit moet voorkomen. Of je kan vinden, dat de gebruiker gewoon de applicatie goed moet gebruiken.

Even wat nuance en context. Ja, het is vast duidelijk dat ik in basis vind dat de applicatie moet voorkomen dat een gebruiker fouten maakt. Maar hier zijn grenzen aan te stellen. Niet elk invoerveld hoeft bijvoorbeeld een spellingscontrole te hebben. En je hoeft wat mij betreft ook niet hele strikte controles uit te voeren, om te voorkomen dat een adres fout wordt ingevoerd. Er zijn grenzen. En wat die grenzen zijn, moet per applicatie bepaald worden. Maar in beide gevallen ga ik er niet vanuit dat de applicatie plotseling vreemd gedrag gaat vertonen. Spellingsfouten zijn onprofessioneel, maar zullen niet snel problemen veroorzaken in het proces zelf. En een fout adres maakt het niet opeens onmogelijk een bestelling te doen. Voor dit soort zaken zijn ook vaak extra controle stappen voor de gebruiker ingebouwd, plus eenvoudige mogelijkheden dit te wijzigen. Waar het mij om gaat is die invoer, werkelijk zorgt voor een echt ongewenst resultaat. Dus ja, als door een verkeerd adres de bestelling niet opgeslagen kan worden in de database, dat soort zaken zijn bugs. Als de gebruiker zijn eigen verkeerd ingevoerde adres op een bon ziet, dat niet.

Wat ik vreemd vind aan dit onderwerp? Als ik een datumveld test en ik zou ontdekken, dat ik hier 30 februari in kan voeren, zal niemand ontkennen dat dit een bug is. Maar als ik een veld check, waar een bestaande code ingevoerd moet worden en je kan een niet bestaande code invoeren, dan zijn er twee varianten. De gebruiker had beter moeten weten. Of de gebruiker weet beter en doet het daarom niet. Een ander voorbeeld: als ik bij 'geslacht' de keuze ''Man, vrouw, hond of kat' zou zien, is dit een bug. Maar zie ik in een lijst met te verkopen artikelen een product, dat niet verkocht mag worden? Dezelfde twee varianten. Wat ik nog vreemder vind? De kans dat een gebruiker een verkeerd product kiest of een verkeerde code invoert, zie ik als een stuk groter dan dat de gebruiker een ongeldige datum of geslacht invoert.

Wat speelt hier vaak echt? In mijn ervaring is hier meestal sprake van een van de volgende problemen: tijdgebrek of kennisgebrek. Of zelfs allebei. De eerste: men neemt of krijgt de tijd niet om het werk goed af te ronden, zodat dit soort fouten niet ontdekt en opgelost kunnen worden. Snelheid is belangrijk, dus voor dit soort extra checks, zeker omdat deze vaak ingewikkelder zijn dan een datum check, is geen tijd. De andere is: men heeft geen idee hoe het moet werken. De kennis om te bepalen wat goed is en wat fout is niet aanwezig. En daarom wordt die verantwoordelijkheid gelegd bij de persoon met de kennis: de gebruiker of de klant.

Moet je deze bugs oplossen? Wat mij betreft is die discussie op te lossen met de ouderwetse prioriteiten: Blocking,  Critical, Major, Minor. Of wat bij jou de prioriteiten ook zijn. Wat is dan wel belangrijk? Benoem de werkelijke problemen. Als je niet de tijd hebt om een scherm goed af te ronden, los dit niet op door het toestaan van foute invoer geen bug te noemen. Benoem het tijdsprobleem en geef de risico's aan. En als je de kennis niet hebt, erken dit. Geef aan dat dit een risico vormt, omdat hierdoor onbekende bugs aanwezig kunnen zijn.

Waarom is dit zo belangrijk? Op het moment dat je praat over 'slechts 1 situatie' lijkt het belang niet zo groot. Maar omdat tijd en kennis problemen vaak lopen over langere tijd, nemen deze situaties steeds meer toe in je applicatie. Omdat het geen bugs zijn, worden ze niet vastgelegd. Omdat de kennis als bekend wordt beschouwd, wordt er niets vastgelegd. En zo creëer je stap voor stap een mijnenveld. En in het begin weet misschien iedereen waar de mijnen liggen. Maar op een bepaald moment niet meer. Vanaf dat moment is het wachten tot iemand op een mijn stapt.

Tijd- en kennisproblemen komen regelmatig voor. Ik ben er als tester in ieder geval niet meer van onder de indruk. Gevaarlijk wordt het pas, als je ze niet meer benoemt. En de gevolgen gaat verstoppen. Bijvoorbeeld door bugs geen bugs te noemen, Een extra probleem:  juist door dit soort gevolgen te verstoppen vererger je tijd- en kennisproblemen. Door ingebouwd, vreemd, niet vastgelegd gedrag neemt de kennis verder af. En het oplossen van 'echte' bugs of toevoegen van functionaliteit kost meer tijd, doordat niemand nog weet hoe de applicatie eigenlijk moet werken. Blijf daarom een bug een bug noemen. En een tijd- of kennisprobleem een tijd- of kennisprobleem.


Geen opmerkingen:

Een reactie posten

Opmerking: Alleen leden van deze blog kunnen een reactie posten.