De bug van de week, deel 02

Door Suzefred gepubliceerd op Friday 06 March 22:06

De bug van de week, deel 02. 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. Doe er je voordeel mee!

 

Een week voorbij, en ik werp even een blik in de bevindingentool. Wat was deze week nou een bevinding die de moeite waard is om te delen?

Ook nu een die niet al te schokkend is, maar die weer een andere manier van testen boven tafel legt. Iets om rekening mee te houden.

Ben je zelf bezig in het testvak, of ben je juist een ontwikkelaar, lees het verhaal dan eens. Laat het even bezinken, trek de lijn even door naar je eigen werk en denk er eens aan in de toekomst. Wie weet wat je ermee kunt voorkomen.

 

Voor het gemak vereenvoudig ik het verhaal even. Het betreft een applicatie met een aantal schermen. Eigenlijk het normale verhaal. Een gebruiker voert gegevens in, drukt op een Opslaan-knop, en de gegevens worden in een database opgeslagen en worden weer opgehaald en getoond in een ander scherm.

In de eerste ronde wordt er een voorbeeld gemaakt van het scherm wat de ontwikkelaars dan ook bouwen.

1cbc70ba3dbf010aeeb50af216d648d6_medium.

Een gebruiker wordt gevraagd 4 vragen te beantwoorden en klikt dan op opslaan. Vraag 2 is een vraag waarbij gekozen kan worden uit 2 keuzes, "Ja" of "Nee". Daarna is het voor deze gebruiker klaar. Later zal een scherm ontwikkeld gaan worden waarbij een andere gebruiker iets moet doen en waarbij deze informatie zal worden gebruikt.

Het programma is gebouwd en getest en goed bevonden en de gebruiker gaat ermee aan de slag. Gaandeweg wordt duidelijk dat het toch iets anders zou moeten. Als het antwoord op vraag 2 "Ja" is, dan moeten de overige vragen ook gesteld worden, maar als het antwoord op vraag 2 "Nee" is, dan zijn de overige 2 vragen juist niet van toepassing en moeten dan ook niet (meer) getoond worden.

De ontwikkelaar past zijn programma aan en biedt het aan ter test.

Wat ga je testen en wat wordt je conclusie?

Ik geef een voorzetje:

Eerst maar eens een beetje spelen met het scherm. En even de flow testen die de ontwikkelaar nieuw moest bouwen. Ik open het desbetreffende scherm, de 4 vragen staan er. Dat is alvast een OK.

Ik geef een antwoord op vraag 1, tik bij vraag 2 een “Nee” in, en inderdaad, de vragen 3 en 4 verdwijnen zoals gevraagd. Dat ziet er goed uit.

 

Nu het andere pad. Eigenlijk het pad dat in eerste instantie al was gebouwd. Kijken of er niets omgevallen is.

Ik verander het antwoord bij vraag 2 alsnog in een Ja en de vragen komen weer tevoorschijn. Ook dat ziet er goed uit.

Wat is je oordeel?

 

Ik ga nog een stapje verder, want er zit een leuk puntje in dit verhaal en ik ben benieuwd hoe dat gaat reageren...

We beginnen met de oude situatie, we vullen vraag 1 in, geven een “Ja” op vraag 2 en beantwoorden vraag 3 en 4. Daarna maken we van de “Ja” alsnog een “Nee” en constateren dat de vragen zoals gewenst weer verdwijnen. Daarna maken we van de “Nee” weer een “Ja”. De vragen komen weer tevoorschijn. Dat ziet er goed uit.

Wat opvalt, is dat de antwoorden bij vraag 3 en 4 er weer staan.

Ik koppel dit terug aan de ontwikkelaar.

“Dat klopt, dat is handig, want stel dat je per ongeluk Nee selecteert, dan ben je de invoer anders kwijt, in dit geval komt die invoer weer tevoorschijn als je er alsnog weer een Ja van maakt. Is besproken met de ontwerper en dat is inderdaad de gewenste werking".

OK. Dan is dat dus geen bevinding, maar een feature. Eindoordeel OK.

Eind goed, al goed.

Maar dat zal toch niet? Dit verhaal heet toch niet voor niets ‘bug of the week’?

Wat heb je nu nog gemist? Wat valt er nog te testen?

 

Ergens in dit verhaal gaat een ‘Hé, da’s raar!’ schuil. En dat is precies het punt waarop je alert moet zijn. Het is makkelijk om te denken 'nou ja, het zal wel', maar juist als tester zijn dit de momenten waarop je moet denken 'wacht eens even, wat dan als...?'.

De antwoorden van vraag 3 en 4 die weer tevoorschijn kwamen bij het alsnog terugzetten naar “Ja”. Het correcte gedrag, volgens de ontwerpen en de ontwikkelaar...

Nu doen we nog een keer dat scenario, maar testen (uiteraard) ook even de opslaanknop.

We voeren in,

  • antwoord 1,
  • Ja,
  • antwoord 3,
  • antwoord 4.

Dan maken we van de Ja een Nee en nu staat er nog op het scherm een “antwoord 1” en een “Nee”.

We drukken op de opslaan-knop en controleren de opslag.

 

En wat denk je? Inderdaad. Opgeslagen is

  • Antwoord 1
  • Nee
  • Antwoord 3
  • Antwoord 4

Precies die combinatie die vanaf dit stuk software juist niet meer voor moet komen, want de vragen 3 en 4 waren juist niet meer van toepassing als je voor Nee had gekozen.

Moraal van het verhaal: Als vragen onder bepaalde situaties tevoorschijn komen of verdwijnen, controleer dan niet alleen of deze vragen ook inderdaad tevoorschijn komen en verdwijnen, maar controleer dan juist de opslag, zeker in het geval dat de vragen verdwijnen terwijl je de antwoorden al gegeven had.

 

En ik sluit weer af met de vraag, wat denk je, Waterval of Agile? En waarom?

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

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. f265424c006d53ff72bd832c4886be91_medium.

San Francisco Depot

Het ezelsbruggetje

Agile, deel 1

Het teamoverleg

Bug van de week

deel 01

Reacties (3) 

Voordat je kunt reageren moet je aangemeld zijn. Login of maak een gratis account aan.
Twijfel heel erg tussen Agile en Waterval.
Agile is als ik het goed heb ... zonder verspringingen zeg maar. (mijn woorden) Waterval is uiteraard een vorm waarin je zeg maar van level naar level springt.

Zal het wel mis hebben, maar zeg toch Agile.
Ik denk dat je het goed hebt voor wat betreft wat wat is, maar vanuit het verhaal zou ik juist kiezen voor waterval. Hier wordt duidelijk iets besloten en gebouwd en daarna komt test een keer om de hoek kijken met een soort 'geheimgehouden test' als een soort kwaliteitsbewaking, een soort bewaker om aan te geven of iets door mag of niet. De informatie die de ontwikkelaar had ('ja, dat is handig als die invoer blijft staan, want als je per ongeluk had gekozen etc', bleek bij de ontwikkelaar bekend te zijn omdat dat besproken was met de ontwerper, maar niet bij de tester. De tester is duidelijk 'op z'n eigen eilandje' testgevallen aan het bedenken zonder deze vooraf bij de ontwikkelaar aan te geven, zonder dus eigenlijk met z'n allen duidelijk te hebben wat nu precies gevraagd of verlangd wordt. Zou je juist de andere aanpak nemen, dan zou je van te voren met de ontwikkelaar en klant samen hebben gezeten en zouden de testgevallen juist geen verrassing meer moeten zijn, en zouden de testgevallen eigenlijk een gevolg zijn van de duidelijke wensen. In dit geval zou vooraf bijvoorbeeld al worden gevraagd 'maar wat nou als ik vraag 3 en/of 4 al invul en daarna nee kies en dan opsla, wat moet er dan gebeuren? Dan zou de klant hier over nagedacht hebben en hebben geantwoord (misschien wel een 'dan moet er een foutmelding komen en moet de gebruiker eerst de antwoorden van vraag 3 en 4 wissen') en dan zou de ontwikkelaar meteen weten dat hij dat dus ook moest bouwen.
(maar eerlijk is eerlijk, dat is mijn mening om het hier waterval te noemen, want agile is wel meer dan dat alleen ;-)
Wel leuk dat je er al zo snel over nagedacht had (en op gereageerd had!)
Vind het boeiend.