Door het oog van de tester

Vaak wordt er gevraagd naar een tester op het moment dat de kwaliteit tijdens een project blijkt tegen te vallen, of dat te veel zaken verkeerd gaan in de live omgeving. Maar wat wordt er dan eigenlijk gevraagd? In ieder geval niet om ‘handjes’ die testgevallen inkloppen, maar juist om een bepaalde kijk op de (ICT) wereld. Hieronder een poging om die ‘kijk’ te omschrijven.

Hij of zij kijkt naar de situatie en stelt de typische ‘moeilijke’ vragen.

  • Wat is de achterliggende reden dat dit systeem of deze wijziging gebouwd is? Zorg voor een frisse, objectieve kijk. Soms lijkt iedereen het al te weten, totdat jij met de vraag komt. Stel vragen over alle variaties en over toekomstig gebruik. Ken de business en zorg dat je precies weet wat er nodig is en waarom. Wees daarmee toekomstige requirements voor. Bovendien identificeer je zo gaten in het ontwerp.
    .
  • Welke (verborgen) startvariabelen zijn er? Waar komen die vandaan? Zijn ze correct en komen ze goed door? Zoals: “De medewerkers in het personeelsbestand mogen de cursus aanvragen.” Ook iedereen die al uit dienst is? Alleen internen en met een contract voor onbepaalde tijd? In iedere functie? Ongeacht aantal contracturen per week? En hoe kom je aan die informatie?
    .
  • Hebben we alle opties in een beslissing meegenomen? Zoals: “Het navigatiesysteem geeft de aanwijzingen voor de richting rechtdoor, linksaf of rechtsaf.” Uiteraard zijn er nog veel meer opties, zoals rotondes, afbuigingen, enzovoort).
    .
  • Wat zijn de (verborgen) gevolgen van de beslissingen? Inclusief de gevolgen van alle gevonden startvariabelen en opties. Moeten rapportages worden aangepast? Welke andere systemen krijgen deze informatie door? Wat moet er in die systemen worden aangepast, en moet de interface ook worden aangepast? Kloppen de procedures en werkinstructies nog? Verwachten we performance problemen? Zijn er security aspecten, zoals beveiliging of toegang? En mocht het fout gaan (lege waarden, tekst in datumveld, crashes), hoe handel je dit dan af? Veel van deze zaken zullen door een architect worden besloten.
    .
  • Vraag neutraal en objectief door op de details. Want juist daar gaat het vaak fout. Waarom? Hoe? Wanneer? Waarom? Hoe vaak? Hoe? Wanneer? Waarom? Hoe? Welke? Waarom? Wie? Hoe? Wanneer? Waarom? Waarom? Tot je het beeld helemaal compleet hebt. En niet alleen om de details boven water te krijgen, maar ook om de bestaande hoofdlijnen te valideren.
    .

“Wil je dit even testen” is een simpele vraag, maar goed testen betekent dus nogal wat. Gelukkig levert het ook nogal wat op!

De discussie over testdata in een notendop

Voor wie zich nog niet echt in de complexiteit van testdata heeft verdiept; hier is een simpele introductie! De algemene vraag is; hoe kom ik aan de best bruikbare data om mee te testen?

Optie 1: Je kunt testdata zelf bedenken


Het voordeel hiervan is dat het volledig voorspelbaar is wat je als invoer hebt en dus ook volledige controle hebt over wat je testuitvoer is. Een voordeel dat hieruit volgt is dat je lekker kunt variëren met invoer die je normaal gesproken niet tegenkomt. Achternamen met 51 letters, of mevrouw Des’ree Çőgürcű – Sørensen.

Optie 2: Je kunt letterlijk de data uit de live omgeving gebruiken


Het voordeel hiervan is dat je er meteen heel veel van hebt en dat er veel variatie in zit. En niet alleen de ‘leuke’ variantie; er kunnen ook vanuit historie fouten in zitten, zoals velden die vroeger leeg zijn gelaten terwijl ze tegenwoordig verplicht zijn bij nieuwe invoer. Mooi om te testen hoe stevig (ofwel robuust) je software is. En ook prettig; de live data neemt historie mee, zoals een verzekering die al 26 jaar schadevrij loopt. Dat kun je niet zomaar opvoeren, tenminste niet netjes via de gebruikersschermen. En nog een voordeel; je weet vrij zeker dat de gegevens door de hele keten van applicaties gelijk zijn.

Het nadeel is dat je met gebruik van ‘echte’ gegevens heel voorzichtig moet zijn. Niet alleen is dat een verplichting vanuit de wet, het kan ook flinke financiële schade en imago schade opleveren. Het gaat dan vooral om gegevens die naar individuele personen terug te leiden zijn en om getallen en bedragen die niet openbaar zijn. Daarom is er een derde categorie.

Optie 3: Je kunt data uit de live omgeving anoniem maken


Anonimiseren, depersonaliseren. Het zijn niet echt lekker klinkende begrippen, maar het is erg nuttig en wordt vaak toegepast. Er zijn heel veel trucs voor te bedenken, van vrij basaal (zoals alle huisnummers in de database 10 regels naar beneden zetten, zodat er een ander adres ontstaat) tot heel verfijnd (met allemaal speciale software). Op deze manier hou je de voordelen van live data en verklein je de risico’s zoals hierboven beschreven. Deze categorie noem ik graag ‘productiegelijke’ data.

Tips

  • Als je fictieve of geanonimiseerde data gebruikt, zorg dan dat je ze via de bron invoert en alle koppelingen laat lopen. Zo heb je door het hele systeem heen dezelfde data. En bovendien; het zou niet voor het eerst zijn dat geanonimiseerde data via een koppeling weer ‘netjes’ rechtgezet wordt.
  • Wees voorbereid op controles binnen je applicaties. Een combinatie van postcode en huisnummer wordt vaak gecontroleerd en afgevangen als het niet bestaat. Net als IBAN rekeningnummers, waar overigens tools voor zijn om het controlegetal kloppend te krijgen.
  • Er zijn niet alleen tools om te anonimiseren, maar ook om random data te genereren. Je klanten of gebruikers heten dan niet allemaal ‘Piet Jansen’, maar bijvoorbeeld variaties zoals Piet Jansenixyyz. Grammaticaal niet geweldig, maar Piet Jansenixyyz is wel snel gevonden als zijn foutgelopen bestelling moet worden geanalyseerd.
  • Mocht je toch vertrouwelijke productiedata willen gebruiken in de testomgeving, kijk dan niet alleen wie er toegang hebben tot de applicatie of de database zelf. Kijk ook waar exports en rapportages worden opgeslagen en kijk hoe je gegevens over de email worden uitgewisseld.

En als het na dit alles een beetje begint te duizelen, dan is dat een goed teken! Want dit soort afwegingen zijn complex en verdienen de nodige aandacht!

Testbaarheid

Op deze website wordt kwaliteit opgedeeld in 7 categorieën, om het simpel te houden. Er zijn er nog zeker 50 meer, maar vandaag wil ik het podium geven aan ‘testbaarheid.’ Dat is leuk voor ons testers, en zorgt ervoor dat we meer inzicht in de kwaliteit van de software kunnen krijgen. En daar heeft het bedrijf weer iets aan.

Vreemd genoeg gaat het TMap Next boek (uit 2006 alweer) nauwelijks in op testbaarheid en een kort rondje op internet brengt me ook niet veel verder. De hoogste tijd om testbaarheid tastbaar te maken; vandaag dus niet alleen verheldering, maar ook verdieping!

Bij testbaarheid denk ik aan:

Functionaliteit

  • Is de impact van een wijziging op de omliggende functionaliteit bekend, en goed gedocumenteerd?
  • Zijn er duidelijke en goed herhaalbare testgevallen aanwezig, met betrekking tot de gewijzigde en omliggende functionaliteit?

Infrastructuur

  • Zijn er een aparte ontwikkel-, test- en acceptatieomgeving (OTA) ingericht?
  • Als er geen volledige OTA is ingericht; zijn er duidelijke afspraken wie er welke handelingen op de testomgevingen mogen uitvoeren, en wanneer?
  • Is de technische ondergrond (fysieke en/of virtuele machines) representatief voor productie?
  • Zijn extern draaiende applicaties ook beschikbaar op de diverse omgevingen?
  • Als niet alle applicaties beschikbaar zijn; is er een minimale set aan applicaties aangewezen, die altijd actueel en goed beschikbaar moeten zijn op de diverse omgevingen? (bijvoorbeeld het CRM pakket of de middleware)
  • Als niet alle applicaties beschikbaar zijn; zijn er stubs en drivers ingericht om de werkelijke reactie van een applicatie te simuleren?
  • Is er een afspraak op welke versie de gehele keten draait, per omgeving? (wordt alles steeds naar de productiestand gebracht?)
  • Is de benodigde tooling voor testen ingericht? (bijvoorbeeld een random data generator, load generator, screenshot tools, vergrootglas, link checker, response timer, aparte logging tool)
  • Zijn er faciliteiten ingericht om te kunnen tijdreizen? En is de gehele keten hierop voorbereid?
  • Als er toestemming is om productiedata te gebruiken, zijn de rollen op die testomgeving dan ook minstens net zo streng ingericht en beveiligd als de productieomgeving?

Data

  • Zijn er afspraken welke productiedata er beschikbaar mogen zijn per omgeving?
  • Is het mogelijk om snel specifieke testsituaties klaar te zetten? (via insert queries, geautomatiseerd via de schermen, enzovoort)
  • Kan er snel een eerdere testsituatie worden klaargezet?

Procedures

  • Zijn de diverse rollen snel te mobiliseren om een gebruikerstest en beheerderstest uit te voeren? Zijn er key users en hun back ups toegewezen?
  • Zijn de juiste personen aangewezen en geautoriseerd om de testresultaten te accepteren?
  • Heeft de systeemtester toegang tot meerdere inlog accounts, om de diverse rollen en rechten te kunnen testen?
  • Als er productiedata gebruikt mag worden, zijn er dan afspraken over hoe de betrokkenen omgaan met die data? (bijvoorbeeld of dit via mail of netwerkschijven gedeeld wordt)

Een mooi lijstje om bij je eigen bedrijf eens na te lopen? En zoals altijd zijn aanvullingen welkom!

Hoeveel gaan we testen? Een simpel schema

Het is af! Sinds juni 2012 heb ik gewerkt aan het opzetten van een standaard testaanpak. De laatste weken heb ik geschreven en geschaafd aan de laatste templates. Het belangrijkste doel was om alle wijzigingen te kunnen voorzien van een testaanpak, dus van kleine aanpassingen tot ingrijpende projecten.

In totaal worden er ongeveer 15 wijzigingen per dag aangemeld. De meeste daarvan komen van de beheerders, die zelf verantwoordelijk zijn voor de kwaliteit van de applicatie die ze willen aanpassen. En dus ook voor het beperken van risico’s. Daarom is het aan die beheerders om de eerste inschatting van de testbehoefte te maken. Om hen daarbij te helpen, hanteer ik het volgende schema.

 Testzwaarte

De testzwaarte loopt dan als volgt op.

A de beheerder voert op eigen initiatief wat testjes uit
B de beheerder bespreekt de testaanpak met de testmanager (mij) en gaat daarna zelf aan de slag
C de beheerder of iemand met een expliciete testrol legt de uitgevoerde testen vast in een testrapport
D iemand met een expliciete testrol schrijft een vrijgave advies, waarin ook een vaste set aan non-functionals wordt beoordeeld
E iemand met een expliciete testrol legt vooraf in een testplan vast welke risico’s er zijn, ook op non-functionals, en koppelt daar systeemtesten en acceptatietesten aan
F iemand met een expliciete testrol gebruikt testontwerpen om vooraf een set met testgevallen op te stellen

De volgende stap is dat onze change management tool de gekozen testzwaarte vastlegt. Dat gaat de komende periode ingebouwd worden. Ik hou je op de hoogte!

Testgevallen – hou het overzicht!

Het is enorm nuttig om vooraf te bepalen wat je wilt gaan testen. En de meest gebruikelijke manier om dat te doen, is het opstellen van testgevallen. Testgevallen zijn ook nog eens een tastbare deliverable, waar een testmanager of een projectleider een ‘vinkje’ achter kan zetten. Testgevallen zijn bovendien het startpunt van testuitvoering en hét instrument om te meten hoe het ervoor staat met die uitvoering. ‘We hebben 18 van de 25 testgevallen uitgevoerd, dus we zijn al bijna klaar.’ Testgevallen zijn geweldig! Testgevallen zijn de heilige graal van het testen! Dus laten we vooral meteen beginnen met beschrijven via welke testgevallen we door de applicatie heen gaan lopen.

Natuurlijk is dit veel te kort door de bocht. Ik pak er één ding uit wat helaas vaak gebeurt, ook bij grote bedrijven waar veel testervaring beschikbaar is. En dat is de volgende schrijfwijze van een testgeval.

Testgeval 1

Handeling Verwacht resultaat Werkelijk resultaat
Klik op invoerveld ‘Achternaam’ De cursor verspringt naar het veld ‘Achternaam’ De cursor is inderdaad versprongen naar het veld ‘Achternaam’
Typ de waarde ‘Kuijpers’ in Het ‘Achternaam’ veld toont de waarde ‘Kuijpers’ Geheel volgens verwachting wordt de naam ‘Kuijpers’ getoond in het ‘Achternaam’   veld
Klik op het dropdown menu voor het veld ‘Geslacht’ Het dropdown menu voor het veld ‘Geslacht’ klapt open en toont de   waarden ‘Man’ en ‘Vrouw’ Grrrr … !!!

En dat terwijl je wilde testen of een nieuwe klant een boek kan bestellen met bezorgservice. Het tweede testgeval is dat een nieuwe klant het boek bestelt en zelf ophaalt. Dit is één vinkje verschil met het vorige testgeval en opnieuw worden alle handelingen uitgeschreven!

Dit is niet overzichtelijk en bovendien erg slecht onderhoudbaar. Als we ooit ‘Man’ of ‘Vrouw’ veranderen in ‘De heer’ of ‘Mevrouw’, moeten we alle testgevallen aanpassen. Daar zijn mooie trucjes voor om dat heel snel te doen, maar de essentie is dat dit zinloos werk is!

Laten we daarom drie dingen afspreken:

  • Testgevallen worden kort, maar duidelijk beschreven. In één of een paar zinnen. In de agile wereld zou dat een user story heten.
  • Leg één keer centraal vast hoe de navigatie door de schermen verloopt, zodat je dit tijdens de uitvoering ‘onder de testgevallen kunt schuiven’.
  • Leg één keer centraal vast welke variabelen er zijn en wat je daar moet invullen zodat de variabele NIET bepalend is voor het testresultaat.

En als je dan toch graag met deliverables werkt, neem dan het testontwerp op als deliverable. Eerst het denkwerk, dan pas testgevallen opstellen.

Succes! En als je hier zelf een praktijktip aan toe wilt voegen, hoor ik het graag.

Hoe bepaal je testprioriteiten

Ik heb veel leuke gesprekken over het simpel toepassen van testen, maar het gaat eigenlijk altijd buiten deze site om. En als er eens iemand reageert via twitter met een heel relevante vraag, dan mag daar zeker een blogje aan gewijd worden!

Eerst even het verhaal tot nu toe.

Vraag: @sander_mol bedankt voor de tips op http://sandermol.com/acceptatietesten/ … Hoe ga je om met de prioriteiten (moscow) tijdens acceptatie?

Reactie: Dank je. Je wilt met software de belangrijkste bedrijfsactiveiten ondersteunen. Ik zou daar eerst een top 5 van maken.

Vraag: @sander_mol hoort deze taak thuis bij teststrategie of de inhoud van acceptatietesten?

Reactie: Eerst bedrijfsbelangen uitsplitsen (http://sandermol.com/kwaliteit) , dan verdelen in systeem- en acceptatietest. Blogje volgt!

De dagelijkse praktijk bij Meeùs

Het leuke is dat ik precies op dit moment bezig ben met deze oefening, voor alle afdelingen bij Meeùs. Die oefening is dus het bepalen hoe we de belangrijkste bedrijfsactiviteiten ondersteunen. Al die afdelingen dragen bij aan de doelstelling van Meeùs, wat je kunt samenvatten als ‘het wegnemen van zorgen over risico’s van particuliere en zakelijke klanten’. Zo moet de Schade zorgen voor een efficiënte en klantvriendelijke afhandeling van schades. Daarvoor is er een website waar klanten zelf hun schadegegevens kunnen invullen. En is er een backoffice systeem waar taken op de agenda worden gezet.

Kwaliteitscategorieën

Voordat we onderscheid kunnen maken tussen systeemtest en acceptatietest, moeten we eerst bepalen welke kwaliteitscategorieën van belang zijn. Bijvoorbeeld:

gebruiksvriendelijkheid Gebruiksvriendelijkheid
We willen dat de klant op een gebruiksvriendelijke manier door de registratie heen wordt geholpen. De bewoording en mogelijkheden moeten sturing geven, zonder dat het beperkend voelt.
functionaliteit Functionaliteit
We willen dat de taken in de backoffice goed verdeeld worden, dat de voortgang goed wordt geregistreerd en dat er dus zéker geen taken verdwijnen door gebruikersfouten. Het moet dus robuust functioneren.
inpasbaarheid Inpasbaarheid
We willen dat het werken met agenda’s goed aansluit bij onze bestaande processen. Een voorbeeld van een bevinding zou kunnen zijn dat het systeem de taken niet op dezelfde dag kan inplannen, terwijl dit bij ons bedrijf regelmatig voorkomt.

Systeemtesten en acceptatietesten

Pas als je aan alle afdelingen hebt gevraagd naar dit soort risico’s, kun je een verdeling gaan maken tussen systeemtesten en acceptatietesten. In de bovenstaande drie voorbeeldjes zou de robuuste taakafhandeling in de systeemtest plaatsvinden. De gebruiksvriendelijke klantschermen en de inpasbaarheid van de agenda’s zijn typische acceptatietesten.

Bij Meeùs hebben we acht prioriteiten bepaald voor de schade afdeling. Op basis van complexiteit hebben we daar steeds tussen de 30 en 300 minuten aan testtijd aan gekoppeld, zodat er een (regressie)test van twee dagen ontstond.

En daarmee hebben we dus een teststrategie, completer en beter herleidbaar naar het bedrijfsdoel dan de meeste andere bedrijven. Succes!

De uitwerking: ben jij een echte Testpiet?

naamcadeauEn, heb je al wat namen ingevuld om te zien of je een persoonlijk filmpje kreeg? Hierbij de verkennende test die ik heb uitgevoerd. Dat is natuurlijk niet de enige mogelijke manier; iedere verkenning kan ergens anders uitkomen. Wél kun je met wat creativiteit tot een bepaalde dekking komen die je anders niet had gehaald.

De namentest

De test begint met de meest standaard werking; Lucas en Sophie behoren tot de meest voorkomende kindernamen en dat gaat prima; Piet spreekt beide namen uit. Dan is de vraag of het filmpje dynamisch álle namen probeert uit te spreken. Dat blijkt niet het geval; Citroenschijfje levert een naamloos filmpje op.

Dan kunnen we meer de details in. Mijn zoons Jesper en Kelvin gaan prima, dochter Evanne wordt niet herkend. Enkele kinderen uit mijn korfbalteam, Leoni en Marlous, ook niet. Buitenlandse namen als Aleksandra, Ismael en Paris gaan goed. Oudere namen zoals Cornelis en Johannes gaan ook goed, maar mijn moeder Ans heeft pech. Samenvoegingen zoals Annemarije geven geen herkenning. Bij leeglaten loopt het programma niet vast en een spatie vóór de naam of achter de naam gaat ook goed. Sterker nog, alles na het eerste woord wordt genegeerd, Sterre OIUSHDFLKJH wordt gewoon Sterre. En dat brengt ons bij een echte bevinding, Pieter-Jan wordt afgekort tot Pieter. Maar Anne-Fleur (zo’n 100 keer gegeven de afgelopen jaren) lukt dan weer wél.

En, hoeveel variatie had jij gevonden?

De acceptatietest: passen deze filmpjes in mijn dagelijkse leven

Ik zal eerlijk zeggen, mijn vrouw en ik hebben even getwijfeld om dit programma aan onze kinderen te laten zien. De reden is dat er zo’n 8 filmpjes willekeurig worden afgespeeld, steeds met een ander plot. Er zit één filmpje bij waarin Piet het cadeau kapot laat vallen (en daarna een nieuwe krijgt), drie versies waarbij Piet lang moet wachten en zegt dat er geen cadeau voor het kind is en één versie waarin het cadeau zo groot is dat het amper door de voordeur heen kan.

Dat betekent dat we ofwel geschrokken kinderen moeten troosten, ofwel een manshoog cadeau moeten inpakken. Allemaal niet echt dingen waar we op zitten te wachten. Maar dat geldt dus specifiek voor ONS gezinnetje. Dat maakt iedere acceptatietest weer anders; het gaat erom of de software aansluit bij jouw omgeving!

Oefening: ben jij een echte Testpiet?

Het zal jullie niet ontgaan zijn dat de Sint weer in het land is. En wie kinderen heeft, weet ook dat er een serie over een stel zeer klunzige Pieten op televisie is. Ze lopen elkaar in de weg, praten langs elkaar heen, doen aannames over wat de Sint eigenlijk wil. En ieder jaar is er slechts één die de juiste vragen stelt. En die de aannames controleert en bijstuurt op het hoofddoel. Juist, de Testpiet! De vergelijking met software ontwikkeling is snel gemaakt, maar dat laat ik aan jullie.
😉

Ook in het Sint thema; dit jaar is het mogelijk om je kind live getuige te laten zijn van het inpakken van zijn of haar cadeau. De link vind je hier, misschien moet je nog op ‘naar de stoomboot’ klikken. Je kunt de naam van je kind invoeren, waarna die naam een paar keer in het filmpje wordt genoemd. Heel knap in elkaar gezet, maar ook schitterend voer voor een tester. Want ook al ken ik het functioneel ontwerp niet, ik kan er best een verkennende (dus exploratory) test op loslaten. En je krijgt direct je resultaat.

Tijd voor een oefening!

Voer eens een paar namen in en kijk wat voor testsituaties je tegenkomt. En wat de resultaten zijn. En of je de test geslaagd vindt. Denk zowel aan systeemtesten als aan acceptatietesten! Laat me vooral weten wat je uitkomst is. Mijn eigen testrapport zal ik later plaatsen.

Functionaliteit testen: de basis

In juli plaatste ik een blog over hoe je naar functionaliteit kunt kijken. Met daarin een schema dat toch een beetje de vorm van een kerstboom had. Inmiddels is de kerst in aantocht en bovendien heb ik wat verbeteringen in gedachten. Hoogste tijd dus voor een nieuw plaatje. Het pad begint links met inloggen en biedt bij iedere splitsing een functionele keuze; bestaande klant of nieuwe klant, korting of geen korting, enzovoort.

Enkele kegel

Van links naar rechts lezen is het eerste voordeel; het voelt als een procesflow. Je logt in en gaat daarna allerlei handelingen verrichten. Veruit de meeste handelingen zitten in het groene gebied. Als je eindgebruikers van software vraagt om te testen, zullen ze vooral in dit gebied blijven. Het probleem is dat de ontwerper en ontwikkelaar dit stukje óók het beste hebben uitgedacht en getest. De kunst is dus om juist die uitzonderingen en variaties te vinden waar men misschien nog níet aan heeft gedacht.

Verder helpt het om te zien dat software meestal uit meerdere modules bestaan. Bijvoorbeeld zoals het plaatje hieronder. En bedenk vervolgens dat al die gevarieerde manieren om een klant op te voeren weer invloed kunnen hebben op alle volgende modules. Bijvoorbeeld omdat klant alle prijzen en berekeningen in een andere munteenheid wil zien. De mogelijke combinaties in de laatste modules zijn dus eindeloos!

keten van kegels

Gelukkig zijn er technieken om toch genoeg inzicht in de risico’s te krijgen. Eén ervan staat al op deze pagina, maar er volgt zeker nog meer. Bij vragen of suggesties hoor ik het graag.

Testonderscheidingen bij Meeùs

Zoals jullie waarschijnlijk weten, ben ik de enige bij Meeùs met een testachtergrond. De meeste testuitvoering en ook testmanagement komt vanuit de organisatie zelf. In de lente van dit jaar heb ik trainingen gegeven om mijn collega’s op weg te helpen. Er waren trainingen voor de rol testmanager (wat bij ons testtrajectmanager heet), systeemtester en acceptatietester.

De opkomst was erg goed en daar mogen de aanwezigen voor beloond worden! Niet geheel toevallig worden de trainingen binnenkort opnieuw gegeven. Zo krijgt men de kans om hun verzameling medailles compleet te maken!
😉

medailles

« Older Entries