Open brief over AH zelfscan

Beste Albert Heijn,

Een aantal weken terug was ik in de lokale Albert Heijn aan het zelfscannen. Tegen de tijd dat ik moest afrekenen, zat de hele kar vol. Ik had alles ge-zelfscand, dus het afrekenen ging super snel. Totdat het lampje ging branden en ik een controle kreeg. De AH-persoon die mij ging controleren, liep echter naar de verkeerde paal – waar ook een lampje brandde – met de verkeerde kar met boodschappen. Luttele seconden later zei de AH-persoon dat de eigenaar van die kar met boodschappen gecontroleerd moest worden. Ik zag dat die eigenaar zeer verbaasd keek en wierp het idee op dat niet die boodschappen, maar mijn boodschappen gescand hadden moeten worden. En de 5 boodschappen die gecontroleerd waren, zaten natuurlijk niet in mijn kar, en die had ik dus ook niet gescand. Dus kreeg ik een volledige controle, terwijl ik niets had fout gedaan. Vijftien minuten laten – na meerdere verontschuldigingen – ging ik met mijn hele kar vol boodschappen én een bosje bloemen naar huis. Ik kon niet klagen.

Maar…

Ik zie wel meerdere mogelijke verbeteringen, en die wil ik jullie graag vertellen.

Ten eerste: de AH-persoon heeft geen melding gekregen over dat er twee lampjes tegelijk aan het branden waren, waardoor dit heeft kunnen gebeuren. Een push notificatie met: “Let op! Er branden twee lampjes. Scan de bonuskaart van de klant ter controle.” zou dit hebben kunnen voorkomen. Het apparaat kan de bonuskaart al scannen, alleen zit die stap nog niet hier in het proces. Dit toevoegen lijkt mij dan ook niet heel veel moeite.

Ten tweede: mocht er toch een fout worden gemaakt door een AH-persoon, dan kan dat niet ongedaan worden, zo zei de AH-persoon die in mijn geval de fout maakte. Dit vind ik een kwalijke zaak: het is niet mijn fout, ik sta nu geregistreerd als ‘bijna-diefstal’ of iets dergelijks, en daar ben ik de dupe van. Mocht ik ooit per ongeluk iets vergeten te scannen, is dat niet mijn eerste foutje, maar al mijn tweede! Straks word ik nog een keer als dief aangezien dankzij een fout van een AH-persoon. Dit oplossen zou echter niet eens heel moeilijk moeten zijn, namelijk door een ander AH-persoon het te laten bevestigen. Oftewel: na een foute controle moet er aangegeven kunnen worden dat het een menselijke fout aan de AH kant betreft, waarna er een ander AH-persoon moet bevestigen dat het inderdaad een menselijke fout aan de AH kant is. Die bevestiging sluit uit dat de diefstal is opgezet door de AH-persoon en de klant (drie mensen die in het complot zitten, lijkt mij vrij lastig, terwijl twee nog wel doenbaar is). Eventueel zou de bevestiging moeten komen van iemand met een hogere functie.

Ten derde: de volledige controle duurde vrij lang, namelijk vijftien minuten. Hoewel niet onoverkoombaar, lijkt het mij niet moeilijk om die tijd in te korten. Dit zou simpelweg kunnen door één normale kassa vrij te houden voor de volledige controles, en dan het liefst die kassa die het dichtst bij de zelfscan zit. Het gaat nu door producten één voor één uit de tassen te halen, en ze daarna weer één voor één terug te doen. Ik kon als klant niet helpen. Ik had het geen probleem gevonden om alle boodschappen voor een keertje op een normale band te leggen.

Ik wens jullie veel succes met deze verbeteringen implementeren en zie het resultaat graag tegemoet.

Met vriendelijke groet,
Renze Droog

Categorie: Kritiek | Tag: | Plaats een reactie

Over software testen: kwaliteiten van een tester

Mijn uiteindelijk doel met deze serie is om meer mensen geïnteresseerd te krijgen in testen. Ik vind het heel leuk om te doen, en er zijn genoeg baankansen in. Maar wat zou een tester nou moeten kunnen? Welke kwaliteiten moet een tester bezitten? Daarom een lijstje van alle kwaliteiten die heel nuttig zijn als tester, en waarvan sommige zeker noodzakelijk zijn. Anderen zijn ook weer aan te leren, of in ieder geval op te poetsen als het niet je sterkste punt is. Niemand bezit ze allemaal, en dat wordt natuurlijk ook niet van je gevraagd.

Affiniteit met IT is iets dat je zeker nodig hebt. Heb je niks met de IT? Dan zal je testen ook niet leuk vinden.

Analytisch zijn is één van de belangrijkste kwaliteiten die een tester moet hebben. Door je analytische vermogen kan je als tester bepalen wat voor test cases het meest nut hebben in zo min mogelijk tijd. Je kan dankzij je analytische vermogen een bug snel lokaliseren en omzetten in een test resultaten die zo makkelijk mogelijk te gebruiken is door een developer.

Communicatieve vaardigheden zijn nodig om de test resultaten op een goede manier aan de developers over te brengen. Je wil als tester niet té negatief overkomen, want uiteindelijk doet een developer ook gewoon zijn werk, en je kan nou eenmaal niet foutloos programmeren. Als tester heb je ook goede communicatieve vaardigheden nodig om je test resultaten te verdedigen. Soms zal een developer zeggen dat wat jij hebt gevonden op de huidige manier moet werken. Als tester wil je daar tegenin gaan, of op een andere manier documenteren dat je het hebt gevonden en dat het een verbeterpunt is.

Creativiteit vind ik heel belangrijk. Je wil out-of-the-box kunnen denken als tester, zodat je niet alleen de standaard test cases bedenkt, maar ook de ietwat ingewikkeldere test cases, of juist iets dat heel onlogisch lijkt behalve in die ene uitzonderingssituatie die jij net hebt bedacht.

Empathisch vermogen heb je als tester ook nodig. Je wil je niet alleen kunnen inleven in je teamgenoten, maar óók in een bepaalde groep gebruikers (nieuwe gebruikers, hele ervaren gebruikers, gebruikers die de software het liefst kapot maken, …). Je wil je in zo iemand verplaatsen zodat je vanuit dat perspectief nieuwe test cases kan bedenken, zodat je de kwaliteit zo goed mogelijk kan bewaken.

Flexibel. Af en toe komt het voor dat er ineens iets heel belangrijks tussendoor komt. Jij als tester zult daar flexibel in moeten staan en dat gelijk moeten oppakken als klanten wachten op de functionaliteit. Misschien moet je dan iets minder goed testen, en misschien heb je er een iets minder goed gevoel bij, maar de klant is en blijft koning. En klanten snappen ook dat iets niet perfect is als het op korte termijn gemaakt moet worden.

Gestructureerd werken is als tester zeer belangrijk. Als je “maar wat doet”, moet je dat nog steeds op een gestructureerde manier doen. Je wil niet uit het oog verliezen dat je één knop al 100 keer hebt aangeklikt en dat de kans klein is dat je daar nog een bug in vindt. Bovendien kan je te maken krijgen met vooropgestelde test cases die je gestructureerd moet afwerken.

Gevoel. Niet echt een kwaliteit, maar wel belangrijk. Op een gegeven moment zal je uit ervaring moeten kunnen bepalen of iets ‘goed genoeg’ getest is, of je er genoeg vertrouwen in hebt dat alles werkt zoals het zou moeten werken (op je test resultaten na).

Inzicht in IT is heel handig, maar niet noodzakelijk als je alleen manueel test (voor automatisch testen is het wel noodzakelijk). Als tester is het heel handig om te snappen hoe programmeren werkt, hoe een developer denkt, waar gevaren voor bugs zitten. Aan de andere kant is dit ook iets dat vrij makkelijk te leren is, makkelijker dan soft skills.

Kritisch. Als tester ben je kritisch op wat er gemaakt is, en ga je nogmaals af of dit wel echt de meest logische manier is. Moet de volgorde niet toch anders? Mist er niet deze of die functionaliteit? Alles kan je als tester benoemen. Of het ook daadwerkelijk veranderd, is nog een tweede. Dat je samen met het team bewuste keuzes maakt over wat er wel en niet verandert is, staat namelijk los van je werk als tester.

Onafhankelijk, want als tester werk je alleen of heb je in ieder geval een grote mate van zelfstandigheid. Het komt niet veel voor dat een tester echt intensief samenwerkt met andere testers, en dat je samen één ding test. Meestal test elke tester een bepaald onderdeel, waardoor je ook niet direct feedback krijgt op hoe je test. Je zult daar zelfverzekerd genoeg in moeten zijn zodat je op een onafhankelijke manier kan testen.

Perfectionistisch ben je als tester sowieso. Staat dat ene lettertje niet goed? Gewoon vertellen. Het kost een paar seconden om te verbeteren en het zal daarna nooit meer iemand irriteren.

Precisie, of oog voor detail is als tester heel belangrijk. Je wil namelijk zoveel mogelijk zien. Elke pixel die verkeerd staat, merk jij als tester op. Je wil zo precies mogelijk elke bug opsporen.

Prioriteren is belangrijk op een dagelijkse basis. Als tester zul je nooit maar één ding kunnen doen. Dus waar kies je voor: eerst 10 dingen testen die een paar minuten kosten, of beginnen met die grote functionaliteit waar je de hele dag mee bezig bent? In elke situatie zal dat anders zijn. Bovendien is het prioriteren van test cases ook belangrijk: vaak wil je de belangrijkste test resultaten zo snel mogelijk bij de developer krijgen, zodat die er al mee aan de slag kan gaan. En dus wil je de test cases met het hoogste risico zo snel mogelijk uitvoeren.

Rapporteren, en dan met name voor het maken van test cases en het opstellen van de test resultaten. Deels komt hier ook je analytisch vermogen om de hoek kijken. Uiteindelijk moet je die analytische skills ook kunnen omzetten in een rapport-achtig-iets waarmee je kan laten zien wat je gedaan hebt, waarom, wat er mis gaat (test resultaten), en hoe. Oftewel: de standaard 5 W’s en 1 H (wat, waarom, wie, waar, wanneer, hoe).

Teamplayer zijn is als tester zeer belangrijk. Je bent uiteindelijk niet in gevecht met een developer. Je wil namelijk samen de software zo goed mogelijk krijgen! En daar hoort geven en nemen bij. En daar horen ook complimentjes naar developers bij. Als jij alleen maar je bak met kritiek naar de andere kant gooit, zal de andere kant ook niet welwillend zijn om iets voor jou op te pakken.

Dus: bezit jij de meeste van deze kwaliteiten? Of ben je bereid om eraan te werken? En lijkt je testen leuk? Heb je HBO of WO denkniveau? Word dan vooral Software Tester! Er zijn genoeg traineeships te vinden waar je niet eens een opleiding voor afgerond hoeft te hebben mits je het niveau bezit, en nog meer traineeships waar je zo inrolt met een afgeronde opleiding.

Categorie: Beta | Tag: | 2 Reacties

Over software testen: automatisch testen

Het automatische gedeelte van testen kan je op dezelfde vier niveaus doen als manueel testen: op het unit-, module-, integratie- en systeem-niveau. De eerste twee niveaus zijn echter niet bedoeld om als Software Tester te testen, omdat die niveaus typisch te testen zijn zonder dat je de software voor je ziet, dus niet in een browser, applicatie of app. De laatste twee zijn de niveaus die je als Software Tester daadwerkelijk automatische tests voor kan maken.

Bij automatisch testen maak je *iets* dat wordt omgezet in code en dat automatisch een deel van de software test. Dat *iets* is bewust zo vaag, omdat automatisch testen tegenwoordig meestal wordt gedaan door middel van “behavior driven development” waarin je geen echte code schrijft, maar gebruik maakt van keywords die door mensen te lezen zijn. Een test is dan direct door mensen te lezen, en ook door mensen die niets van programmeren weten. Aan de andere kant kan je voor dat *iets* ook echte code gebruiken in een reguliere programmeertaal (Java, C#, Python, enzovoort). In principe maakt het niet uit wat je gebruikt, zolang je er maar een afweging in maakt. Een voorbeeldje met keywords uit behavior driven development:

*** Test case ***
Inloggen
Ga naar inlogpagina
Voer gebruikersnaam in   $gebruikersnaam
Voer wachtwoord in   $wachtwoord
Klik op inlogknop
Verifieer dat inloggen is gelukt

Het idee hiervan is door iedereen te begrijpen: je opent een pagina, voert de gegevens in (en wat die gegevens precies zijn, kan je zelf bepalen), klikt op de inlog-knop en dan zou je ingelogd moeten zijn, dus dat verifieer je. Als dat verifiëren gelukt is, en er ondertussen niets is misgegaan, dan is de test case geslaagd! Achter deze keywords zitten uiteraard nog meerdere lagen, die vaak minder goed te begrijpen zijn door niet-IT’ers. Bijvoorbeeld: “Verifieer dat inloggen is gelukt” zegt wel wat het doet, maar niet precies hoe. Misschien kijkt hij wel naar of er staat “U bent ingelogd als …”, of dat de inlog-knop er niet meer is, of dat je op een ander scherm zit dat je alleen als ingelogde gebruiker te zien krijgt, of nog iets anders, of allemaal! Dat is maar net hoe uitgebreid je de test case maakt, en hoe de software zou moeten reageren. Want zo’n verifieer stap is precies het gedeelte dat je écht test: daar test je of wat je zou verwachten overeenkomt met wat er gebeurt.

Ook voor automatisch testen geldt hetzelfde principe als voor manueel testen: je kan niet alles testen, dus je wil testtechnieken gebruiken. Helaas zijn er bij automatisch testen nog wat meer belemmeringen: het kost veel tijd om één complete test case te draaien. Daarom zal je minder kunnen testen dan je manueel kunt doen. Maar doordat ze automatisch zijn, kan je ze wel elke dag een keer draaien. En dat gaat helemaal automatisch. En zo krijg je elke dag een overzicht van welke test case gelukt is, en welke niet. Door alle belemmeringen van automatisch testen wil een falende test case niet per direct zeggen dat er iets mis is. Het kan ook een incident zijn, bijvoorbeeld veroorzaak door een eerdere (terecht) falende test case. Maar als een test case meerdere keren achter elkaar niet goed draait, dan kan je er bijna vanuit gaan dat er echt iets mis is. Ofwel met de test case (die veranderd moet worden), ofwel met de functionaliteit van de software (die kapot is).

Het lastige aan automatisch testen is dat het veel onderhoud vergt. Er verandert nou eenmaal vaak veel aan de software. En als jij een verifieer stap hebt gedefinieerd die niet meer van toepassing is, gaat de test case fout, maar werkt de software nog wel. De test case kan ook fout gaan als een ding (knop, invoerveld, tekst) van plek verandert, want de achterliggende keywords gebruiken allerlei “selectors” om te bepalen op welke plek iets moet gebeuren. Een selector is precies wat de naam zegt: het selecteert iets (een knop, een stukje tekst, een deel van de pagina, enzovoort). En die selectors kunnen vrij snel veranderen. Als je twee knoppen hebt, en jouw selector is “de eerste knop op de pagina”, en de twee knoppen verwisselen van plek, dan gaat het mis.

Aan de andere kant heb je er ook enorm baat bij als je eenmaal genoeg automatische test cases hebt draaien. Als je elke dag weet dat de functionaliteit (met grote zekerheid) het nog doet, dan hoef je ook bestaande functionaliteit minder vaak manueel te testen. En eenmaal zo’n test geschreven, dan kan hij elke dag automatisch draaien.

In de praktijk zal je altijd een combinatie van manueel én automatisch testen nodig hebben. Je kan nou eenmaal niet alles afdekken met automatisch testen, omdat het daarvoor té tijdrovend is. Bovendien is er ook een kwestie van vertrouwen nodig: hoe weet je zo zeker dat die automatisch test cases echt alles zien wat jij als mens ook ziet? Dat is nooit zo, dan zou je teveel moeten verifiëren (staat elk knopje nog wel precies goed, zijn alle kleuren goed, …). Maar het grootste gedeelte, het gedeelte wat het meest belangrijk is, daar is automatisch testen heel geschikt voor. En zeker als je daar intern (in de code) veel veranderingen aan doet die extern (in de webapplicatie of app) niets veranderen. De automatisch test cases zouden het dan nog allemaal prima moeten doen. Elke dag weer.

Categorie: Beta | Tag: | 1 Reactie

Over software testen: manueel testen

Als je als tester de software voor je neus krijgt, ga je de software testen. Maar hoe dan? Normaal gesproken doe je dat manueel, dus je klikt er zelf doorheen. Het kan ook automatisch, maar daar later meer over. Manueel testen dus.

Testen kan je grofweg gezegd op vier niveaus doen:

  • ‘Unit’-niveau: het kleinst mogelijk gedeelte van de software, bijvoorbeeld op een knop drukken op een rekenmachine.
  • ‘Module’-niveau: de samenkomst van de units, bijvoorbeeld de berekening achter het ‘+’-teken op een rekenmachine.
  • ‘Integratie’-niveau: de samenkomst van de modules, bijvoorbeeld één configuratie op een rekenmachine (de standaard Windows rekenmachine kan je zetten op ‘standaard’, ‘wetenschappelijk’, ‘programmeren’ en ‘statistieken’).
  • ‘Systeem’-niveau: het complete systeem.

Als je een hoger niveau test, test je ook alle onderliggende niveaus. Om zoveel mogelijk bugs te vinden en ze ook te lokaliseren op het juiste niveau, wil je in je test proces het liefst op elk niveau tests uitvoeren. De laagste twee niveaus, unit en module, zijn geschikt om bijna compleet te automatiseren. De hoogste twee niveaus, integratie en systeem, zijn daar minder geschikt voor, omdat het te veel tijd kost om ze te maken, onderhouden en uit te voeren. Je wil op die niveaus het liefst wel automatisch testen, maar dan met een niet-complete dekking.

Sowieso is een complete dekking met testen onmogelijk. Een rekenvoorbeeldje:

  • Stel één module berekent de leeftijd van een persoon.
  • Leeftijd bestaat uit twee datums: vandaag en de geboortedatum.
  • Je neemt aan dat mensen niet eerder geboren zijn dan 150 jaar geleden.
  • Je wil testen of het de komende 100 jaar werkt.
  • Er zitten 365 dagen in een jaar.
  • Komende 100 jaar: 100 jaar * 365 dagen per jaar = 36.500x ‘vandaag’.
  • Afgelopen 150 jaar plus komende 100 jaar: 91.250 geboortedatums.
  • 36.500 * 91.250 = 3.330.625.000 triljoen mogelijkheden.
  • Stel een computer kan per milliseconde bereken of de leeftijd klopt.
  • 3,3 triljoen * 0,001s = 39 volle dagen.

Het kost dus 39 volle dagen om alleen al dit te berekenen. En dat is nog een gunstige berekening: zou je niet ook de leeftijd van oudere dingen willen berekenen? Kost één berekening slechts één milliseconde, want dat is heel erg snel? Willen we niet ook datums testen die niet bestaan (29 februari 2017, of 32 december, …). Daarnaast is dit slechts één module, laat staan als je het verschil in leeftijd tussen twee dingen zou willen berekenen (3,3 triljoen * 3,3 triljoen * 0,001s = 128.391.931.604 volle dagen). Met andere woorden: je moet áltijd een selectie maken van mogelijke test cases. En daar zijn een heleboel nuttige en interessante manieren voor, maar dat is wat té theoretisch, dus laten we aannemen dat je het meer dan significant kan terugdringen.

Met dat terugdringen zal je altijd bepaalde delen niet kunnen testen. En dat is eigenlijk geen probleem, want met testen wil je de kwaliteit bewaken, en niet de kwaliteit garanderen. Je wil dus in zo min mogelijk tijd, met zo min mogelijk inspanning, zo zeker mogelijk zijn over de kwaliteit. Dat zal altijd een afweging zijn. Als er software gemaakt wordt voor een bedrijfskritisch proces, zal je meer tijd besteden aan testen. Als er software gemaakt wordt voor intern gebruik, is de kwaliteit minder belangrijk.

In het proces van het terugdringen van alle mogelijke test cases heb je een heleboel verschillende technieken, genaamd “testtechnieken”. Dat zijn uiteraard allemaal hele slimme manieren die gebruik maken van verschillende al dan niet bewezen theorieën. Bijvoorbeeld: “boundary value analysis”. Waarom alle dagen van het hele jaar testen, als je vooral problemen verwacht bij boundaries (1e en laatste dag van de maand cq. het jaar, 29 februari, als iemand vandaag jarig is, …)? Als alle boundaries werken, kan je er vrij zeker van zijn dat alles ertussenin ook werkt. Of een ander: “exploratory testing”, waarin je op basis van al jouw kennis niet vooraf allerlei test cases opschrijft, maar gelijk met de software aan de slag gaat en doet wat voor jou (als tester, maar ook als welwillende gebruiker, en ook als niet-welwillende gebruiker) logisch lijkt. Als dat allemaal goed werkt, is de kans klein dat er nog iets anders kapot gaat.

Het liefst gebruik je meerdere testtechnieken, omdat geen van allen perfect is en ze allemaal gebaseerd zijn op aannames die niet altijd kloppen. Uiteindelijk zal je op een gegeven moment het gevoel hebben dat je ‘alles’ ‘goed genoeg’ hebt getest, en kan je doorgeven dat je helemaal tevreden bent met de kwaliteit. Of niet, en dan kom je met je lijstje met test resultaten aanzetten.

Categorie: Beta | Tag: | Plaats een reactie

Over software testen: bugs

Zoals ik in het vorige deel al heb genoemd, staan er in de ‘issue tracker’ ook ‘bugs’. Over bugs in software kan je boeken vol schrijven, en er kunnen daadwerkelijk mensen aan doodgaan. Een voorbeeld hiervan is de Therac-25 [1]: een bestralingstherapiemachine die teveel straling uitzond doordat mechanische checks uit oudere machines (Therac-6 en Therac-20) vervangen werden door checks in de software in de nieuwste machine (Therac-25), en die bleken niet foutvrij te zijn, waardoor minimaal vier mensen zijn overleden. Uiteraard zijn veruit de meeste bugs niet zo gevaarlijk, want bugs kunnen alleen tot dit soort tragische gevallen leiden in gezondheidskritische software, zoals in de medische wereld, ruimtevaart of auto-industrie. Normaal gesproken kunnen bugs hooguit leiden tot informatie of geld in de verkeerde handen: nog steeds een probleem, maar wel een iets minder groot probleem.

Maar wat is een bug nou eigenlijk? Algemeen gezegd is een bug een fout in de software. Een bug kan je tegengekomen in elke software: ook wat je nu gebruikt om dit te lezen (besturingssysteem, browser, …). Een bug uit zich in de software doordat er iets gebeurd wat niet de bedoeling is, of juist niets gebeurd terwijl er iets zou moeten gebeuren. Lekker vaag allemaal.

Om met een voorbeeld te beginnen: stel je wil twee getallen optellen op een rekenmachine, maar ‘2+3’ wordt ‘6’. Dan heb je een bug gevonden. Die bug kan heel veel verschillende oorzaken hebben: misschien is ‘+’ wel stiekem ‘*’, of misschien telt hij overal wel ‘1’ bij op, of misschien was je vorige antwoord ‘1’ en telt hij dat er bij op, of misschien komt er elke keer een random getal bij. Als tester wil je de oorzaak eigenlijk zo precies mogelijk vaststellen. Je wil weten wat er fout gaat, zodat je beter kan beschrijven wat de bug is en eventueel zelfs hoe een developer hem kan oplossen. En je wil natuurlijk de zekerheid hebben dat het echt een bug is, en niet dat jij per ongeluk iets verkeerd deed. Voor dit geval (‘2+3’ wordt ‘6’) zou je bijvoorbeeld de vier mogelijke oorzaken kunnen testen met ‘3+3’ zoals deze tabel aangeeft:

Tabel met test casesMocht er iets uitkomen wat de tabel zegt, dan heb je (zeer waarschijnlijk) het probleem gevonden! Mocht er iets uitkomen dat je niet had verwacht, dan zal je verder moeten nadenken over wat er mis zou kunnen zijn. Uiteindelijk houdt dat ook wel een keer op: als tester is je verantwoordelijkheid niet om met 100% zekerheid te zeggen waar het probleem zich bevindt, zolang je een goed ‘reproductiepad’ kan geven. Een reproductiepad is namelijk een pad waarmee de bug optreedt: “als je stappen 1, 2, 3 en 4 uitvoert, dan verschijnt ‘6’ in plaats van ‘5’” bijvoorbeeld. Door die stappen te noteren, kan een developer makkelijk de bug reproduceren, waardoor hij zelf (in theorie) heel makkelijk de bug kan oplossen.

Naast het reproductiepad heeft een bug in de issue tracker nog wat meer informatie nodig: een goede titel (wat er mis gaat – en niet de oplossing), een beschrijving (al is vaak een reproductiepad al genoeg), misschien een paar screenshots, een prioriteit (moet de bug vandaag opgelost worden of mag het ook over een jaar?), en allerlei extra bedrijfsspecifieke informatie. Je wil het liefst zoveel mogelijk informatie verschaffen, maar je moet je ook altijd bedenken dat teveel informatie niet nodig is (en dus voor jou tijd kost om de extra informatie te verzorgen, en voor de developer tijd kost om de extra informatie te begrijpen).

Met zo’n bugreport kan vervolgens iets gedaan worden: ofwel kan hij opgelost worden – waarna jij als tester hem weer voor de ogen krijgt en zo kan vaststellen dat de bug inderdaad weg is. Ofwel kan worden besloten om hem niet op te lossen, bijvoorbeeld omdat het gewenst gedrag is (“de rekenmachine onthoudt altijd het vorige antwoord, tenzij op de ‘C’-knop gedrukt wordt”), omdat hij niet te reproduceren is (voornamelijk als er te weinig informatie is aangeleverd) of omdat een ander bugreport precies hetzelfde beschrijft.

Al die bugreports helpen bij het bepalen wat de status is van de software. Mochten er meer bugs worden opgelost dan dat er nieuwe worden gevonden, kan je merken dat de software steeds stabieler wordt. Mocht het andersom zijn, bijvoorbeeld dat er 20 bugs worden opgelost en 30 nieuwe bugs worden gevonden, kan je merken dat er te weinig tijd wordt besteed aan bestaande bugs. En ook dat kan een afweging zijn: als alle nieuwe bugs slechts hele kleine dingen zijn (een spellingfout of iets dat alleen optreedt met Internet Explorer 6 op Windows XP als je linkshandig bent) terwijl de opgeloste bugs de grotere dingen zijn (‘+’ is inderdaad ‘*’), dan kan dat juist een bewuste keuze zijn.

Als tester zou je doel niet moeten zijn om zoveel mogelijk bugs te vinden, want dan ga je juist op zoek naar kleine dingen. Als tester wil je de kwaliteit bewaken en zorgen dat er geen (of zo min mogelijk) bugs in de software zitten die een hoge prioriteit zouden hebben. Dat er een spellingfout instaat is natuurlijk niet heel erg. Dat ‘+’ inderdaad ‘*’ is, is in een rekenmachine juist een heel groot probleem. Je wil als tester aan de andere kant ook juist de kleine dingen vinden, zodat de software uiteindelijk zo perfect mogelijk is. En daarmee zorg je ervoor dat de kwaliteit zo hoog mogelijk wordt. Precies wat de bedoeling is.

Tijdens het testen van een nieuwe feature vind je in eerste instantie nog geen bugs. Een bug is in principe pas een bug als de software opgeleverd is en in gebruik bij eindgebruikers. Daarvoor noem je ze ‘test resultaten’ (of welke andere naam je er ook voor wil gebruiken), omdat ze normaal gesproken nog opgelost worden voordat de software is opgeleverd. Af en toe komt het voor dat er besloten wordt om een test resultaat toch pas later op te lossen, waardoor het dan pas een bug wordt.

[1] Leveson, N. G. & Turner, C. S., “An Investigation of the Therac-25 Accidents”
(1993), IEEE Computer, Volume 26, Number 7, July 1993, pp. 18-41

Categorie: Beta | Tag: | Plaats een reactie

Over software testen: wat is testen eigenlijk?

Een half jaar geleden ben ik begonnen als Software Tester (bij BlueConic). Zo’n beetje iedereen die niet in de IT werkt en hoort dat ik werk als tester, vraagt zich af wat testen eigenlijk is. Het klinkt zo simpel: testen. Aan de andere kant klinkt het ook als een groot en vaag begrip.

De verantwoordelijkheid van een tester is duidelijker in een andere benaming: Quality Assurance. Als Software Tester krijg je software voor ogen en is het doel om de kwaliteit van de software te bewaken. Dat doel voer je uit door het te testen. Quality Assurance is dus het doel en Testen het middel.

De kwaliteit bewaken klinkt al meer als iets iedereen wel begrijpt. Als tester wil je er zeker van zijn dat de software doet wat het zou moeten doen (“werkt de ‘+’-knop op deze rekenmachine?”), maar zeker ook niet doet wat het niet zou moeten doen (“kan ik inloggen als administrator terwijl ik dat niet ben?”). Beide zijn duidelijk functionele kenmerken, maar er zijn ook genoeg niet-functionele kenmerken te bedenken: of de software snel genoeg is, of de software ook werkt als je hem met meerdere mensen tegelijk gebruikt (2, 10, of misschien wel een miljoen), of de software niet om de havenklap stopt met werken, enzovoort. Uiteindelijk komt het erop neer dat er (impliciet) een aantal karakteristieken zijn vastgesteld waaraan de software moet voldoen, en als tester bewaak je dat de software daar ook daadwerkelijk aan voldoet.

Dat je als tester de ‘software voor ogen krijgt’ klinkt natuurlijk veel simpeler dan het daadwerkelijk is. Binnen elk bedrijf zal dat proces ook verschillen, al is de basis wel hetzelfde. Software ontwikkelen begint met ‘requirements’: de karakteristieken waaraan het moet voldoen. Die requirements staan ergens beschreven, en dat is meestal in een ‘issue tracker’ (zoals Jira), waarin een issue wordt aangemaakt per ‘feature’ en ‘bug’ – simpel gezegd. Per feature worden de requirements vastgesteld, waarna ze omgezet worden tot software doordat developers het programmeren. Als de feature in de software zit, moet het nog bij de tester komen zodat de tester ook daadwerkelijk aan de slag kan. Het kan zijn dat de tester dit zelf regelt, dat de developer nodig is, of dat het automatisch gaat maar even tijd kost. Dat verschilt per situatie en per bedrijf.

Vervolgens kan de tester met de software aan de slag en velt hij uiteindelijk een oordeel. Dit komt neer op: “de test is geslaagd” of “ik heb gevonden dat de feature nog niet helemaal goed werkt, omdat [..]”. Uiteindelijk bepaal je daarna met de developer, de persoon die de requirements heeft gemaakt en/of een manager wat er uiteindelijk met jouw punten gebeurt. Soms moeten ze per se gelijk worden opgelost, maar soms kan er ook worden gezegd dat het voor nu goed is en dat ze later worden opgelost. Mochten er nog punten worden opgelost, zal je als tester weer opnieuw naar de software moeten kijken om zeker te weten dat de kwaliteit nu wel goed is. En misschien vind je dan nog nieuwe punten, waarna je weer in dezelfde cirkel terecht komt. Mocht de kwaliteit nu wel goed genoeg zijn, dan kan de software worden goedgekeurd en uiteindelijk terechtkomen bij de eindgebruiker! En die heeft dan uiteraard een stukje software voor handen met een hele hoge kwaliteit.

Categorie: Beta | Tag: | Plaats een reactie

Opgeven is een optie

Niet alleen bij kanker,
niet alleen bij ziekte.
Niet alleen als iedereen
oordeelt over jou.
Niet alleen als je lichaam
of geest het niet meer aan kan.

Ook als je wil opgeven.
Ook als je genoeg hebt van doorgaan.
Ook als de voordelen op zijn,
en de nadelen overheersen.

Naar aanleiding van Huib Kloosterhuis’ laatste boodschap.

Categorie: Psychologie | Tag: | Plaats een reactie

Ik ben niet goed voor mijn eigen lichaam

Voor wie het nog niet weet: ik eet niet gezond. Mijn dieet bestaat uit brood, brood en nog meer brood. Af en toe friet, pannenkoeken en poffertjes, maar daar blijft het eigenlijk wel bij. Ik weet dat dat niet gezond is, dat ik eigenlijk meer gevarieerd moet eten, maar helaas gaat dat niet. En ik weet ook dat het voor andere mensen lastig is om te begrijpen, ook omdat ik het heel lang niet goed kon uitleggen. Bij deze een nieuwe poging met de uitleg die ik de laatste paar jaar eraan geef.

Als eerste: hoe het komt. Mijn zintuigen zijn heel sterk (oftewel gevoelig). Mijn smaak is daarin het extreemste geval. Mijn zicht, gehoor en reuk is ook wel sterk, maar niet zó extreem dat ik er last van heb. Wat er zo extreem is aan mijn smaak? Ik word heel snel misselijk van smaken en structuren. En dat word ik al helemaal als het verschillende smaken en structuren door elkaar zijn. Precies dat wat er overal aan eten te krijgen valt. Zelfs op een boterham zitten al drie smaken: brood, boter en beleg. Laat staan in een volwaardige avondmaaltijd waar veel meer uitgesproken smaken zitten.

Wat ik wel kan eten, ligt eigenlijk best simpel: de smaak moet zo goed als neutraal zijn, en anders wordt het al lastig. Als de smaak niet neutraal is, dan mag hij wel zoet en/of zout zijn, want daar kan ik wel tegen. De structuur moet het liefste hard en/of droog zijn, en eigenlijk moet het een bite hebben. Fruit? Niet droog (en vaak ook niet hard). Vlees? Geen van beide. Kaas? Ook niet, maar dat kan ik nog nét aan, omdat de smaak van de kaas die ik eet, niet zo uitgesproken is. En omdat ik er langzaamaan steeds meer gewend aan ben geraakt.

Het probleem van dit probleem is dat elk soort eten overal weer net wat anders is. Vroeger kon ik daar echt niet goed tegen en deed ik altijd zo simpel mogelijk. Tegenwoordig gaat het al wel iets beter, maar ik vermijd toch wel heel veel dingen, omdat ik vaak bij voorbaat al weet dat het niet iets is waar ik tegen kan. Thuis koop ik precies de dingen die ik wél lust, en één verandering daarin kan er al voor zorgen dat ik het niet lekker vind. Al is het bij een boterham alleen al het soort brood, het soort boter of een ander merk van het soort beleg. En dat is natuurlijk bijna onbegrijpbaar voor anderen. Ik begrijp het alleen omdat ik het ervaar, en omdat ik weet dat ik écht wel meer wil eten, maar dat lukt gewoon niet.

Als ik elke dag nieuwe dingen zou proberen, zou ik er wellicht sneller aan gewend raken. Maar de consequentie daarvan is dat ik veel vaker misselijk ben. Ik word al misselijk als ik nét teveel kaas op heb, of nét één klein hapje teveel kibbeling (één van de meest uitgesproken smaken die ik lust). Tegenwoordig voel ik dat gelukkig aankomen, maar het is wel heel lastig. Voordat ik ga eten voel ik het niet, ik voel het zeg maar een paar happen van te voren.

Als ik elke dag nieuwe dingen zou proberen, zou ik ook heel veel tegen mijn zin proberen. Ik weet dat ik niet zo vaak zin heb om nieuwe dingen te proberen, omdat het heel vaak een teleurstelling wordt. En als dat steeds maar weer gebeurd, dan wordt het een negatieve spiraal, en daar ga ik uiteindelijk juist minder van eten. Hier komt ook nog eens bij dat ik geen oneindige bankrekening heb, want elke keer iets nieuws kopen, dat kost (veel) geld op de lange termijn.

Het lastigste is nog wel dat het bijna onbegrijpbaar is voor iedereen die het niet ervaart, tenzij je een hele tijd met mij meeloopt en merkt wat ik eet en erachter kom dat ik het níet voor mijn plezier doe. Zelfs mijn vriendin heeft meer dan een half jaar gedacht dat het tussen mijn oren zat. Totdat ik een keer écht misselijk werd van eten. En dat gebeurde op een totaal onverwachts moment. Zonder voorafgaande aankondiging. En toen was ik een dag ziek. Dan ga je mij natuurlijk wel geloven, want dat fake ik natuurlijk niet en dat is écht niet iets dat ik wil.

Dat ik langzaam aan smaken gewend kan raken, staat voor mij wel vast. Zo kon ik een jaar of 5 geleden netaan één tosti eten. Inmiddels kan ik er drie achter elkaar eten doordat ik het een jaar lang heb geoefend. Ik bouwde het op door steeds vaker één tosti te eten, een keer ‘s middags en ‘s avonds een tosti te eten, daarna een keer twee tosti’s achter elkaar te eten, enzovoort. De eerste keer dat ik er drie at, kostte de laatste paar happen mij wel extreem veel moeite. En zo gaat het met elke nieuwe stap. Ik heb ook geregeld momenten dat ik minder kan eten dan mijn limiet is, omdat mijn zintuigen soms ook nog eens overgevoelig zijn, bovenop wat het normaal al is.

Maar er zijn ook extremere voorbeelden: neem nou gerookte zalm. Er was eens een dag dat ik dat wel eens wilde proberen. Dus deed ik het. Eén dun plakje tussen een stuk stokbrood in. En het ging, verbazingwekkend genoeg. Ik had verwacht dat ik er over meerdere keren gewend aan moest raken, maar ik kreeg al gelijk een (klein en dun) plakje op. Dus ik lust het. Máár: het moet wel met een overdaad aan brood zijn, het plakje moet heel dun zijn én de gerookte zalm moet geen hele uitgesproken smaak hebben. Een heel broodje gerookte zalm zou dan ook nog niet gaan. Daar zit meestal genoeg brood bij voor mij om netaan de helft van de zalm op te krijgen. Maar er zit ook nog allerlei groente op, en vaak ook nog iets van een saus, en dat gaat (nog) niet. Dus ik lust nu wel gerookte zalm, maar het zal nog een hele tijd duren voordat ik dat op een normale manier ergens kan eten.

En zo gaat het eigenlijk met alles. Het kost veel moeite om iets nieuws te proberen. Het kost veel moeite om iets nieuws te lusten. Het kost veel moeite om iets nieuws op zo’n manier te lusten dat ik het ergens buiten mijn eigen huis kan eten. En al die stappen zijn op zichzelf al amper te begrijpen voor anderen, laat staan in combinatie. Dus dat jij, beste lezer, het nog niet begrijpt, neem ik je niet kwalijk. Inmiddels weet ik dat dat voor zo’n beetje iedereen geldt. Gelukkig kan ik er zelf wel goed mee omgaan, want over de jaren heb ik precies geleerd wat ik wel kan eten, en wat niet. En wat ik wel moet zeggen tegen anderen, en wat niet. Vroeger zei ik gewoon dat ik weinig lustte, maar daar neemt eigenlijk niemand genoegen mee. Nu ik zeg dat mijn zintuigen heel sterk zijn, snappen mensen al sneller wáárom ik niet zoveel lust. Gelukkig maar, want ik zou het écht graag anders zien, maar dat kost gewoon héél veel tijd, moeite, zin en geld.

Categorie: Persoonlijk | Tag: | 2 Reacties

Vluchten

De laatste jaren van mijn leven heb ik gespendeerd met studeren. Tijdens het studeren kom je andere studenten tegen. Studeren is dé periode in je leven om nieuwe dingen uit te proberen. En dat doen studenten dan ook praktisch met z’n allen.

Maarrr… In mijn ogen is het niet nodig om álles uit te proberen. Om precies te zijn twee dingen: drugs en alcohol. Met de eerste zijn veel mensen het wel eens, maar bij lange na niet iedereen. De tweede is tegenwoordig zó normaal dat het echt abnormaal wordt gevonden als ik zeg dat ik geen alcohol drink (en het ook nooit gedronken heb).

Als je drugs gebruikt, doen de meeste mensen dat om één van de volgende paar redenen: 1) ze willen langer actief kunnen zijn dan dat hun lichaam normaal gesproken kan (stimulerende middelen), 2) ze willen minder voelen (verdovende middelen) of 3) ze willen buiten de normale grenzen van perceptie treden (hallucinogene middelen). En hoewel alcohol normaal gesproken niet in één adem wordt genoemd met drugs, is het het natuurlijk wel gewoon (in categorie 2).

Voor mij zijn alle categorieën een vorm van vluchten uit de realiteit. De eerste categorie zorgt ervoor dat je echt over de grenzen van je lichaam heen gaat, zonder dat je het door hebt. Natuurlijk merk je dat op zo’n moment zelf niet, maar uiteindelijk kán dat gewoon op geen enkele manier goed zijn voor je lichaam. En dat je dan heel veel plezier haalt uit zo’n moment, dat vind ik persoonlijk totaal ondergeschikt.

De tweede categorie is de lichtste categorie, maar dat is misschien wel de duidelijkste manier van vluchten. Door je emoties te verdoven, vlucht je er letterlijk van weg. Zeker bij alcohol hoor je dat vaak: mensen die zich niet goed voelen, drinken sneller dagelijks een glas of gaan een keer flink los in de kroeg.

Van de mensen die ik ken die (enigszins) tegen drugsgebruik zijn, hoor ik vaak dat de derde categorie nog wel een beetje kan, omdat je daar niet echt verslaafd aan kunt raken. Maar zelfs als je ergens niet lichamelijk of geestelijk verslaafd aan kan raken, kan het gebruiken van zo’n middel er nog steeds voor zorgen dat je psychologisch gezien het nog een keer wil gebruiken, en nog een keer, en nog een keer. En als het niet psychologisch gezien is, dan kan het ook nog zijn vanuit groepsdruk of gewoonte.

Natuurlijk doet elk mens wel eens aan vluchten, want dat hoort er wel een beetje bij. Je kan niet altijd en op elk moment overal voor openstaan, zelfs ik niet*. En daar is op zich niet zoveel mis mee. Waar ik alleen een probleem in zie, is als je er iets voor nodig hebt dat gewoon niet goed is voor je lichaam. Waarom zou je zoiets moeten gebruiken? Omdat het leuk is? Omdat het fijn is? Dat vind ik geen goede redenen om je lichaam schade toe te brengen. Je weet immers nooit wat de schade op de lange termijn is, of wat er op de korte termijn mis kan gaan.

Aan de andere kant vind ik ook weer dat iedereen zelf moet weten wat ze doen in en met hun leven, zolang ik er geen last van heb. Voor dat laatste heb ik (deels) zelf gezorgd door niet in kringen te komen waar ik wel last van zou hebben. En dat eerste zorgt ervoor dat ik nooit alcohol- of drugsgebruikers aanspreek op hun gedrag, en al helemaal niet als het voor af en toe is. Of tenminste, dat nooit is nooit behalve met deze blog, om iedereen iets meer bewust te maken van wat ze doen. En of je er nou iets mee doet of niet, dat mag je uiteindelijk natuurlijk helemaal zelf weten.

* = dat ‘zelfs’ bedoel ik natuurlijk niet serieus.

Categorie: Kritiek | Tag: | Plaats een reactie

Contactloos betalen

Inmiddels kan je alweer een hele tijd contactloos betalen. Zelf kwam ik het pas de afgelopen paar maanden tegen: in een aantal verschillende winkels werd tegen mij gezegd dat ik ook contactloos kon betalen. Dat probeerde ik na een paar keer eens een keer uit. En wat bleek? Het kon echt. Mooi, zou je denken.

Maar waarom kan ik contactloos betalen terwijl mij daar nooit iets over gezegd is en ik niets heb ingesteld? Waarom wordt het opgedrongen? Dat dacht ik niet meteen, maar ik stond wel gelijk stil bij de talloze mogelijkheden ervan. Als je je pinpas nergens meer in hoeft te doen, wordt skimmen nog makkelijker.

Een tijdje later vond ik dat ik er wat aan moest doen, en dus zette ik contactloos betalen lekker weer uit. Dat deed ik nadat ik wat meer informatie had gezocht over contactloos betalen, en wat is er aan de hand? Skimmen is inderdaad nog veel gemakkelijker geworden. Je hoeft geen pinpas meer te stelen, je hoeft geen pincode meer af te lezen: alles kan zonder dat jij het door hebt.

De Consumentenbond heeft er een filmpje over gemaakt. Je kan sowieso bij iedereen die contactloos betalen heeft aanstaan tot 25€ per keer en tot 50€ per dag skimmen, als je het benodigde apparaatje hebt. Daarvoor hoef je alleen het apparaatje langs de pinpas te halen. En dat werkt ook als hij in een normale portemonnee, tas of broekzak zit.

Daarnaast kan je meer skimmen als je de pincode van iemand weet. Dit kan je vaak vrij makkelijk afkijken, of je zorgt voor een ander apparaatje dat de warmte kan scannen van de toetsen van waar je je pincode in toetst. Door de warmte te zien, kan je zien wat iemands pincode is. Als je de pincode weet, zorg je dat jouw apparaatje de pinpas van een ander kan scannen, en dan kan je de juiste pincode intoetsen en tadaaa, het geld staat op je rekening! (Of op die van een katvanger.)

Maar wat zeggen banken op al hun website? Dat je áltijd boven de 50€ per dag je pinpas moet invoeren. En dat is gewoon niet waar. Banken zeggen ook dat ze al het geld dat onterecht afgeschreven wordt, terug overmaken. En of dat waar is, dat zou ik niet willen proberen. En het is helemaal niet nodig. Wat is er onhandig aan een pincode intoetsen? Het kost een seconde of 15 inclusief wachttijd, lekker belangrijk! En het is vele malen veiliger dan per se contactloos willen betalen.

Wat kan je ertegen doen? Natuurlijk kan je heel gemakkelijk contactloos betalen uitzetten, en dan ben je er gelijk helemaal vanaf. Je kan limieten lager zetten, maar dan kan je nog steeds geld kwijt raken tot dat limiet. En als laatste kan je je pinpassen in een aluminium behuizing doen. Maar dat kost geld. En als je pasjes gestolen worden, ben je nog steeds 49€ kwijt. Of als iemand je pasjes even ‘leent’ zonder dat jij het door hebt.

Ik vind het vooral kwalijk dat banken er zo makkelijk over doen, en ook de Betaalvereniging Nederland. “Doorlopen mensen, niets aan de hand” en “wij van wc-eend, vinden contactloos betalen héél leuk, makkelijk en handig!”

Categorie: Kritiek | Tag: | Plaats een reactie