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.
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,
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
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:
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. |
San Francisco Depot Het ezelsbruggetje |
Agile, deel 1 Het teamoverleg |
Bug van de week deel 01 |
Reacties (3)
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.
(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!)