De bug van de week, deel 01

Door Suzefred gepubliceerd op Sunday 01 March 20:52

Iedereen die mij een beetje kent, weet dat ik tester ben en dat ik dat vak met liefde beoefen. Hieronder een stukje kennisdeling. De bug van de week. Gewoon het verhaal achter een bevinding waar ik afgelopen week mee te maken had. Want als er iets is wat je met bevindingen kan, dan is het wel ervan leren.

7c6b2bec961f57bddac583d444203dd5_medium.

Hoe zie je dat nou? Vroeg iemand ooit eens aan me, toen ik een bevinding meldde. Een leuke vraag.  Zelf sta ik daar niet zo snel bij stil, ik ‘doe gewoon mijn werk’.

Toch zou het goed zijn om daar toch eens wat vaker bij stil te staan, en misschien zou je zelfs eens met een stel testers bij elkaar moeten zitten om daar juist eens wat vaker over te discussiëren. Wat doe je, waar let je op, waarom doe je specifiek dat, en wat doen je juist bewust niet, waar ligt je focus en waarom nou eigenlijk?

Voor mij is het duidelijk, bepaalde fouten worden gewoon sneller gemaakt dan andere en daarom is het soms ‘snel scoren’ om die fouten meteen maar even te vinden en te melden. Maar de meeste voldoening krijg je misschien nou juist weer uit het vinden van de pareltjes die niemand anders wist te vinden?

Bij het nadenken hierover besloot ik zojuist om toch maar eens wat vast te leggen. Gewoon wat kennis van een ‘ervaren tester’, bedoeld voor de minder ervaren tester die wat meer wil, of misschien juist wel voor de andere ervaren tester die mij weer even op mijn plek kan zetten met een ‘leuk, maar je vergeet…’.

Interesseert het je niet? Geen probleem, ga gerust wat anders doen. Interesseert het je wel? Lees dan lekker verder. Ik kan niet garanderen dat je er wat aan hebt, maar je weet maar nooit. (en geef gerust terugkoppeling hierover, dat geeft mij wellicht weer input voor een beter/nuttiger volgend artikel.

Het is zaterdag als ik dit begin en eigenlijk zou ik nu alle bugs van de afgelopen week even moeten bekijken om tot een eerlijk oordeel te komen, maar ik denk dat ik er wel een heb die voor mij nuttig was.

Bug van de week.

Eigenlijk niet eens zo’n heel spannende, de schade die opgelopen zou worden in praktijk zou niet zo groot zijn, maar ik kreeg de complimenten van de ontwikkelaar van dit stuk en daarmee heb ik hem aan het denken gezet en dat maakt het voor mij al een waardevolle bevinding.

Situatieschets: (versimpeld weergegeven).

Een systeem waarbij gebruikers taken op hun naam krijgen, de gebruiker opent deze taak en gebruikt de informatie die op het scherm getoond wordt in zijn oordeel en bepaalt daarmee wat hij invult en wat de vervolgacties zijn.

De flows zijn getest, de invoervelden zijn getest (verplichte velden worden leeggelaten, juiste foutmeldingen verschijnen), happy-flows zijn getest, alternatieve paden worden getest, verschillende testtechnieken worden aangewend en het ziet er allemaal goed uit.

Totdat.

Totdat ik me ook even richt op de bijzondere tekens. En het is misschien niet heel aannemelijk dat een gebruiker in een veld “@#^%$%*ëïöü β€£¥©≤≠͌¿” zal gaan tikken, maar de kans dat hij in een tekstveld zal tikken “Hans & Theo, kunnen jullie deze taak even verder afhandelen?”, is wel aanwezig. En zie daar meteen het ‘rare teken’. Het empersant-teken.  Een normaal ‘en-teken’ voor gebruikers die gewoon wat tikken, maar ook meteen een bekende in de wereld van test.

En ja hoor. Juist dit teken leverde meteen een foutmelding op. Het was niet mogelijk om de input op te slaan.

Analyse. Ja, het &-teken is de boosdoener, deze moet op een andere manier worden doorgegeven aan de achterliggende systemen. Een snelle oplossing, weinig aan de hand. Maar wel een indicatie dat ditzelfde wellicht ook op andere plekken zit. Reden dus om dat na te gaan.

De schade die voorkomen is met het vinden van deze bevinding: minimaal. (Tenminste, hierbij doe ik een paar aannames die ik niet kan staven,

  1. zaken als sql-injecting was wellicht mogelijk geweest maar is niet te verwachten in de gebruikerspopulatie.
  2. Doordat de invoer tegengehouden werd, kon er geen ‘garbage’ in het systeem komen. Erger zou het zijn als de ‘garbage’ juist wel geaccepteerd werd en in het systeem tot onjuiste zaken zou leiden.
  3. De gebruiker zou de bevinding constateren en netjes melden zodat het alsnog opgelost zou zijn. Potentiële imageschade neem ik dus niet mee in mijn oordeel, maar dit zou juist wel eens een heel belangrijke geweest kunnen zijn.

 

foute aanname van de week.

En na de bug van de week ook nog maar even een foute aanname van de week, want ik mag dan ervaren zijn, dat wil niet zeggen dat ik zelf geen fouten maak.

De situatie (versimpeld voor het verhaal).

Een applicatie met 2 schermen. Op scherm 1 wordt wat input gevraagd en op scherm 2 ook. Als je klaar bent met de input op beide schermen, moet je op scherm 1 voor ‘Opslaan’ kiezen.

Als alles goed gaat, komt er een melding ‘Succesvol opgeslagen’ op het scherm.

In scherm 1 zit een invoerveld ‘naam’ en die gebruik ik meteen maar om een kreet in te zetten die ik in de database weer makkelijk terug kan vinden (want er kan wel een melding komen dat het succesvol is opgeslagen, maar dat controleren we uiteraard ook).

Ik begin hier maar eens met “Testgeval 01, Scherm 2 inputveld 1”. In de database verwacht ik dit terug te zien en het geeft meteen ook een stukje tracking van wat ik aan het doen was (iets met scherm 2, invulveld 1).

Dit testgeval ging goed, dus ga ik (middels exploratory testing ) verder met een aantal andere invoervelden op scherm 2. De input die je ingevoerd had bij opslaan blijft staan, dus in dit geval is het simpel om steeds meer aan te vullen. Veld 1 was al ingevuld, ik doe dat ook met veld 3 en veld 8 (de eerste, eentje tussenin en de laatste, wat mij ook meteen meer informatie geeft).

Tegelijkertijd vul ik de naam in scherm 1 aan met “, 3 en 8” waardoor er nu komt te staan “Testgeval 01, Scherm 2 inputveld 1, 3 en 8”.

Ook dit testgeval gaat goed, en ik vervolg de test met nog wat andere input in de desbetreffende velden.

Totdat ik op een punt kom waarbij er bij het opslaan plots een vage foutmelding op het scherm komt.

Ik analyseer nog wat, maar het blijft fout gaan en ik haal de ontwikkelaar erbij om ook meteen even mee te kijken.

Hij bekijkt de foutmelding nog wat beter en wat blijkt…

De naam op scherm 1 is te lang geworden. De lengte van dit veld bij opslag is 50 en blijkbaar wordt nergens afgevangen dat de input, die ik steeds aanvulde, langer is geworden dan die 50. Het scherm accepteert het en de SET’ter op de achtergrond geeft hem netjes door voor de opslag, maar daar komt de fout, want de opslag kan er maar 50 aan.

Zit ik daar dus te analyseren waarom de test op scherm 2 plots fout gaat terwijl het juist komt door de aanvulling die ik steeds doe op scherm 1.

Learning all the time.

Leerpunten:

  • Als je te maken krijgt met een foutmelding, staar je dan niet blind op het onderdeel wat je denkt te testen, maar bedenk wat je nog meer aan het doen bent wat de oorzaak zou kunnen zijn. Heb je inmiddels al 9 keer iets opgeslagen en is dat ook het maximum? (Bijvoorbeeld omdat bij opslag ook een versienummer opgehoogd wordt en dit versienummer te klein gedefinieerd is), of heb je, zoals in mijn geval, ook op een ander scherm iets gedaan wat de verstoring kan veroorzaken en zo zijn er nog tal van andere mogelijkheden te noemen. Zoek de oorzaak in dat wat je deed, maar sluit niets anders uit;
  • Vergeet niet ook op grenswaardes te blijven testen. Het is verleidelijk om overal ‘Test’ in te vullen, maar de kans dat dat fout gaat is gering (de ontwikkelaar zal ook wel zoiets al getest hebben). Maar wat nu als je Test_aaaaaaa invult en je de a ingedrukt houdt (er zijn meer manieren om zinvolle lange teksten te maken). Wat gebeurt er dan? Verschijnt er een melding als je voorbij de 50 komt? Of heb je al iets van 200 tekens ingevuld en verschijnt er nog steeds geen melding? Wat gebeurt er als je opslaat? Hoe lang is het veld in de database eigenlijk, probeer die lengte dan eens. En probeer hem dan ook nog eens met 1 langer. Het zijn de fouten die snel gemaakt worden, maar ook de tests die snel ‘vergeten’ worden (want het invoeren van ‘Test’ gaat nu eenmaal sneller dan “TEST 7 9 12 15 18 21 24 27 30 33 36 39 42 45 48 51 54 57 60 63 66 69 72 75 78 81 84 87 90 93 96 100 104 108 112 116 120 124 128 132 136 140 144 148 152 156 160 164 168 172 176 180 184 188 192 196 200 204 208 212 216 220 224 228 232 236 240 244 248 252 256 260 264 268 272 276 280 284 288 292 296 300 304 308 312 316 320 324 328 332 336 340 344 348 352 356 360 364 368 372 376 380 384 388 392 396 400 404 408 412 416 420 424 428 432 436 440 444 448 452 456 460 464 468 472 476 480 484 488 492 496 500Z” (Wil je weten waarom nou juist deze tekstreeks? Laat maar horen, dan besteed ik daar ook nog eens wat aandacht aan)

 

Tot zover de bug van de week en de foute aanname van de week.

En dan sluit ik af met een vraag. Als je het bovenstaande verhaal bekijkt, wat denk je dan? Agile of Waterval? En waarom?

 

Reageren kan hier alleen als je lid bent, maar in facebook kan het ook, bij dit Facebook-bericht:

Ben benieuwd naar de reacties.

09e00e2808c23813a6008833164a4b1e_medium. Fred Steenbergen is beroepsmatig Testspecialist. Zijn vrije tijd gaat grotendeels op aan het vrijwilligerswerk voor Stichting Dierenopvang Bosnië Hiermee gaat hij meerdere keren per jaar naar Bosnië om daar te helpen met het steriliseren van zwerfhonden.
Wilt u ook helpen? Helpen kan gratis!
U kunt bijvoorbeeld een verschil maken met Douwe Egberts Punten.
En wanneer deed u voor het laatst iets met uw Air Miles?
Ik flikker hem nog liever in de sloot!!!” Waar dat op slaat? Dat leest u hier.

Anderen lazen ook:

8bb3b1830562671cec7b6dbfd80dc9aa_medium. b5e864d1cb867ef6794a99a0114c8347_medium.

San Francisco Depot

Het ezelsbruggetje

Agile, deel 1

Het teamoverleg

Stap over naar Oxxio

Help deze website en onze schrijvers, stap over naar Oxxio als energieleverancier.

Reacties (3) 

Voordat je kunt reageren moet je aangemeld zijn. Login of maak een gratis account aan.
Vind het heel boeiend. Snapte sommige begrippen niet direct, maar gaandeweg beter.

Van mij mag je met een artikel komen over die testreeks. Heb van alles lopen te bedenken, maar kom niet verder dan dat je bij een getal van 2 cijfers telkens met 2 verhoogd en bij een getal van 3 cijfers met 4 verhoogd.
Neem gemakshalve aan dat, mocht het bestaan, je bij een getal van 4 cijfers met 5 verhoogd.

Agile of waterval? Heb je Agile artikelen wel gelezen en denk dat dit Agile is, maar kan het mis hebben. Denk het omdat Agile wat ik me herinner met ontwikkeling van software te maken heeft en dit daarin wordt toegepast.
Leuk zeg dat je het gelezen hebt, maar er zelfs ook echt over nagedacht hebt! En je helpt me over de streep, ik was al begonnen met tikken van het antwoord, maar weet je wat, ik besteed er gewoon wat meer tijd aan en maak er inderdaad een artikel van. (ik denk dat je technisch zelfs gelijk hebt met het verhogen, maar er zit een andere reden achter. Wordt vervolgd, ik ga denken hoe ik dat over kan brengen in een volgend artikel.
Dank voor je reactie!
Graag gedaan.
Zit foutje in bij mij.
een getal van 2 cijfers telkens met 2 verhoogd.
Moet zijn met 3 verhoogd. -))