Posts

Testbash Testpeople
”Namens Testpeople was ik uitgenodigd om Testbash 2018 op vrijdag 13 april bij te wonen. Dit leek mij een mooie kans om zo eens kennis te maken met andere mensen binnen het testvak en om mijn kennis uit te breiden. Daar was Testbash dan ook erg geschikt voor; het is een evenement dat jaarlijks door en voor testers wordt georganiseerd. Dit jaar werd het in Utrecht gehouden, op een mooie locatie in het centrum.

De vrijdag begon officieel om 9 uur, maar ik was iets te vroeg aanwezig. Hier hebben de mensen achter Testbash ook aan gedacht; er werd een ‘Lean Coffee’ georganiseerd voor de vroege vogels. Hier kon je onder het genot van een koffie samen met andere testers in een agile-omgeving problemen of successen binnen je carrière bespreken. We werden in groepjes van ongeveer 7 personen gedeeld en vervolgens mocht iedereen een onderwerp aandragen die hij of zij graag wilde bespreken. Per onderwerp kregen we drie minuten de tijd om dit te bespreken. Er kwamen erg boeiende onderwerpen voorbij en het is altijd interessant om te horen waar andere testers tegenaan lopen of op welke manier zij juist succes ervaren hebben in hun loopbaan.

Na de Lean Coffee begaven we ons richting de zaal voor het officiële evenement. Op de vrijdag werden er in totaal 9 lezingen georganiseerd waarbij iedere lezing zich richt op een ander aspect binnen het testen. Ik heb een drietal lezingen uitgekozen om te bespreken: Bij “Go Old School – Why Test Techniques Aren’t Dead” door Sue Atkins en “Kill the Mutants!” door Nico Jansen en Simon de Lang, heb ik gerichte handvatten aangereikt gekregen die ik zou kunnen toepassen binnen het testvak. Een andere lezing, “Lessons From Famous Detectives For Testers” door Geoffrey van der Tas, vond ik erg leuk in elkaar gezet en deze lezing is mij ook goed bijgebleven. Alle lezingen waren interessant, maar in dit blog wil ik wat dieper ingaan op de bovenstaande lezingen.

Go Old School – Why Test Techniques Aren’t Dead

In de lezing “Go Old School – Why Test Techniques Aren’t Dead” door Sue Atkins, haalde Sue twee testtechnieken aan die ook tegenwoordig nog goed van pas kunnen komen bij het testen, aangezien er tegenwoordig veel nadruk wordt gelegd op testautomatisering. Een van deze technieken is ‘State Transition Testing’. Dit is een techniek waarbij de tester het gedrag van een applicatie analyseert, terwijl er verschillende testwaardes in een bepaalde volgorde worden ingevoerd. De tester voert zowel de positieve als negatieve testwaardes in en bekijkt vervolgens hoe het systeem hierop reageert. Deze waardes kan je invoeren in een tabel, waarbij de status van het systeem aan de linkerzijde wordt geplaatst en de gebeurtenissen aan de bovenkant worden geplaatst. Vervolgens kan je in de hokjes aflezen wat de status is van het systeem nadat een bepaalde gebeurtenis heeft plaatsgevonden.

Een andere techniek die Sue besprak is het zogenaamde ‘Pairwise Testing’ aan de hand van ‘orthogonal arrays’. Deze techniek kan worden gebruikt wanneer er veel testwaardes getest moeten worden aan de hand van gecombineerde waardes. Het voordeel van deze techniek is dat het aantal testgevallen behoorlijk omlaag gebracht kan worden en dat deze testgevallen alle combinaties van de verschillende variabelen wel meepakt. De productiviteit wordt verhoogd doordat er minder testgevallen zijn om te testen. Volgens Sue hebben testtechnieken een negatief imago, doordat zij als ouderwets en onhandelbaar worden beschouwd. Maar wanneer deze technieken op de juiste momenten worden toegepast kunnen zij juist een toegevoegde waarde zijn.

Kill the Mutants!

De tweede lezing waar ik kort op in wil gaan is “Kill the Mutants!” door Nico Jansen en Simon de Lang. Deze lezing is weer meer gericht op geautomatiseerd testen en op welke manier geautomatiseerde testen geoptimaliseerd kunnen worden. Hiervoor gebruiken zij de zogenaamde ‘mutatietesten’. Dit is een manier van testen waarbij er bugs of mutanten in de code worden geplaatst. Als de test faalt, dan is de mutant gedood en als de test slaagt, dan heeft de mutant het overleefd. Hoe meer mutanten er zijn gedood, hoe effectiever de testen zijn. Er zijn verschillende frameworks beschikbaar voor de talen Javascript, Java en Python. Voor de testers onder ons die werken met geautomatiseerde testen, kunnen mutatietesten een nuttige toevoeging zijn.

Lessons From Famous Detectives For Testers

De laatste talk die ik hier wil bespreken is “Lessons From Famous Detectives For Testers” door Geoffrey van der Tas. Deze talk is vooral gericht op het verkennende deel van het testen. Details over het waar en wanneer, het onderzoeken van relevante informatie en weten hoe om te gaan met tijdsdruk zijn belangrijke factoren bij het testen. Hetzelfde geldt voor detectives, vandaar dat er in deze talk de link wordt gelegd met Sherlock Holmes. Volgens Geoffrey werkt Sherlock via een bepaald model, dat ook relevant is voor testers: hij ontdekt iets en neemt de tijd om de waarheid te achterhalen. Dit doet hij onder andere aan de hand van feiten. Vervolgens absorbeert hij de informatie op een manier zodat hij alles beter kan onthouden. Dit doet hij door alle informatie in kleine stukjes te hakken. Daarna leidt hij informatie af aan de hand van opgedane kennis en door terug te redeneren. Dit is vergelijkbaar met Gherkin dat testers gebruiken: Given – when – then, waarbij ‘then’ het effect voorstelt en ‘given’ de oorzaak. Door naar het effect te kijken is de oorzaak vaak te achterhalen. Het beschreven model is ook van toepassing op het verkennende testen van een systeem; bij verkennend testen is het ook belangrijk om te beschikken over genoeg achtergrondinformatie en om genoeg kennis op te doen van het systeem, zodat je die kennis kan gebruiken bij het testen van een systeem.

Ik denk dat ik niet alleen voor mijzelf spreek als ik zeg dat Testbash 2018 een groot succes was. Ik zou iedereen in het testvak dan ook aanraden om dit evenement een keertje bij te wonen.”

-Renate van Munster, Software tester bij Testpeople

Renate van Munster Testpeople

”AT, PP, SAP, FRISS, CVS, ADN. Dit zijn zomaar een paar termen waarmee ik gedurende de eerste weken werd geconfronteerd en die mij, als beginnend junior test consultant, eigenlijk niets zeiden. Dit had misschien ook wel te maken met mijn achtergrond; ik heb een master behaald in de Engelse literatuur en vervolgens heb ik een opleiding gedaan tot docent Engels.

Toch zat ik niet op mijn plek als docent Engels en hierdoor was ik in de tussentijd bezig met het volgen van verschillende online cursussen over computerwetenschappen. Mijn interesse in de IT-branche was meteen gewekt, ook al wist ik stiekem wel dat mijn passie hier altijd heeft gelegen; als klein meisje vond ik computers al erg interessant en ik kon het destijds ook niet laten om in DOS allemaal verschillende ‘commands’ uit te proberen. Dit tot de frustratie van mijn vader die tot de ontdekking kwam dat al zijn bestanden ineens gewist waren. Het willen ontdekken en uitproberen zijn twee eigenschappen die later goed van pas zouden komen tijdens mijn eerste weken als junior test consultant.

Op 1 februari mocht ik samen met twee andere junior test consultants, Luuk en Sjors, starten bij Testpeople. De eerste drie weken hebben we samen hard gestudeerd om onder andere het SCRUM-examen te halen. De examens bleken nog erg pittig te zijn, maar we hebben ze uiteindelijk gehaald. Daarnaast had ik samen met Luuk tijdens de tweede week al een intakegesprek bij een verzekeraar. Dit vonden wij natuurlijk erg spannend, maar het ging gelukkig goed en ik mocht eind februari al starten bij deze verzekeraar, slechts vier weken nadat ik bij Testpeople was aangenomen.

De eerste weken verliepen eigenlijk zoals ik aan het begin beschreef. Ik kende de vaktermen nog niet en was bovendien niet echt thuis in de verzekeringswereld. Het was allemaal nogal overweldigend: veel nieuwe mensen, nieuwe termen, een groot kantoorgebouw en dan ik, de junior. Ik werd gelukkig erg goed opgevangen door mijn collega’s, en dan met name door Daniëlle, en ik kon met elke vraag bij hen terecht. Daniëlle praatte mij elke dag weer een beetje bij over het verloop van het project waar me op dit moment volop mee bezig zijn en hierdoor werd het steeds makkelijker om precies te begrijpen hoe het project en de vaktermen nu precies in elkaar steken en zich tot elkaar verhouden. Daarnaast heb ik de eerste twee weken bij mijn opdrachtgever vooral veel uitgeprobeerd en op die manier ontdekt hoe het programma dat wij moesten testen precies in elkaar stak.

Het gaat nu, drie maanden na mijn start bij Testpeople, erg goed met mij. Ik zit helemaal op mijn plek bij Testpeople en ik vind het erg fijn dat ik elke dag weer iets nieuws leer. Zo hield ik mij aan het begin vooral bezig met het aanmaken en beheren van bugs in Quality Center en Bugzilla, maar inmiddels krijg ik steeds meer verantwoordelijkheden en ben ik ook bezig met het testen van conversie en het uitvoeren van regressie- en acceptatietesten. De eerste fase zijn we inmiddels bijna voorbij met het project en ik ben dan ook erg benieuwd naar de volgende fase. Verder zijn de termen die ik aan het begin van deze blog noemde mij inmiddels helemaal duidelijk en ik hoop er de komende tijd nog veel bij te leren.”

Renate van Munster, Software Tester bij Testpeople

Thomas de Graaf Testpeople

Als we straks allemaal een elektrische auto hebben die we na het werk willen opladen, zou het net daar niet tegen kunnen. Vervanging van het net is evenwel enorm duur. Een slimmere optie is de behoefte te nivelleren. De meeste auto’s hoeven immers pas de volgende ochtend te zijn opgeladen.

De standaard die de organisatie wil neerzetten, staat beschreven in een dik boek met specificaties, dat regelmatig werd bijgewerkt door het designteam. Dit team was geen onderdeel van het scrum team waarin ik zat, maar leverde wel de product owner voor ons team en de user stories. Ons teamhet bouwteam bestond uit een architect, een scrum master, 6 ontwikkelaars en in eerste instantie 1 en later 2 testers. Doel van ons team was het bouwen van een referentieimplementatie.

Mijn ervaring tot dan toe lag vooral in backofficeapplicaties in de financiële sector met 99,9.. % up time. In mijn referentiekader was daarom de eigenschap productiewaardig naadloos verbonden met de definitie van een backofficesysteem. Toen ik in het project kwam was er een test achterstand van een paar sprints. Het testen van het werk van 6 ontwikkelaars in combinatie met de test achterstand leek daarom op het eerste oog een onmogelijke opgave. Hoe zou jij dit hebben aangepakt?

Een referentie-implementatie

Er lag een duidelijke nadruk op de definitie van referentie-implementatie toen mij werd verteld wat we aan het bouwen waren. Dit triggerde mij gelukkig om door te vragen: Wat is een referentie-implementatie in jullie ogen en wat is het doel? Hier kwam gelukkig een zeer helder antwoord op terug:

  • De referentie-implementatie moet de specificaties toetsen;
  • De referentie-implementatie moet gebruikt kunnen worden om simulaties te kunnen draaien t.b.v. onderzoek;
  • De referentie-implementatie moet gebruikt kunnen worden als uitgangspunt voor partijen die de standaard willen implementeren in JAVA.

Na verder te hebben doorgevraagd over deze doelen kon ik bepalen wat de consequenties waren voor de testaanpak.

Toetsen van de specificaties

De specificaties bestaan hoofdzakelijk uit procesbeschrijvingen en interfacespecificaties. Met een review kun je fouten uit specificaties halen, maar als specificaties als standaard je belangrijkste deliverable is, wil je dat elk detail klopt. Pas als je er mee aan de slag gaat, kijk je goed naar details. Een soortgelijke situatie herken ik vaak bij grooming/refinementsessies; je denkt alles helder te hebben, maar loopt tijdens de voorbereiding toch tegen vragen aan.

Hoe heb ik dit vertaald naar een testaanpak?

De waarde van de specificaties is dusdanig groot, dat je als tester niet alleen de individuele stukken functionaliteit moet begrijpen, maar ook waar deze stukken in het proces passen. En dat je dit als proces moet toetsen. Het variëren in mogelijke flows door het proces is daarnaast belangrijker dan het testen van foutsituaties binnen stukken functionaliteit.

Om te beginnen heb ik functionele testen opgezet om vervolgens snel een procesgerichte test op te zetten. Omdat het proces over meerdere rollen loopt, heb ik dit als integratietest aangeduid en om de test elke sprint te kunnen uitvoeren, heb ik dit net als de functionele testen geautomatiseerd in SoapUI. (In een volgende blog zou ik hierop in kunnen gaan, als daar behoefte aan is.)

Simulaties draaien t.b.v. onderzoek

Het nivelleren van de energiebehoefte gaat niet vanzelf, daarvoor wil de standaard marktwerking gebruiken. Omdat het lastig is te voorspellen hoe een nog niet bestaande markt zal functioneren, en waarbij verschillende partijen verschillende belangen hebben, is het belangrijk simulaties te kunnen draaien. Tijdens de simulatie moet aan knoppen kunnen worden gedraaid, om te zien wat het effect is. Dit moet bij voorkeur versneld kunnen worden uitgevoerd, zodat niet meerdere dagen hoeft te worden gewacht op concrete resultaten.

Hoe heb ik dit vertaald naar een testaanpak?

Tijdens een simulatie wil je ervan uit kunnen gaan dat de applicatie een happy flow goed verwerkt. Syntactische fouten zijn niet relevant, omdat men zich daar aan de beschreven standaard dient te houden. Wél relevant is de performance. Als initieel uitgangspunt is een performance requirement neergelegd. Toen snel bleek dat deze eis niet reëel was, hebben we gekeken waar de limieten van de applicatie lag. Performance in deze context is niet iets waar je tegenaan wilt lopen gedurende een simulatie, maar het kon zowel door performance-verbetering worden voorkomen als door het managen van verwachtingen van de mensen die hiermee simulaties willen maken.

Uitgangspunt bij implementatie

Deliverable van het bouwteam is feitelijk de sourcecode met scripts om een omgeving op te kunnen zetten. Daarnaast zijn simpele stubs gemaakt op de punten waar een klant een link moet leggen met zijn eigen back end-systeem en interactie vereist is.

Dit zou geschikt moeten zijn voor een partij om een volwaardige implementatie te maken. Belangrijk hierin is dat de applicatie functioneel helemaal in lijn is met de specificaties. Eisen aan de productiewaardigheid dienen door de betreffende partij zelf aangebracht te worden, evenals de koppeling met back endsystemen van die partij.

Hoe heb ik dit vertaald naar een testaanpak?

Dit doel was het lastigste te begrijpen en vertalen naar een concrete aanpak. Waar ik gewend was een complete oplossing te testen, moest ik nu een deeloplossing testen die enkel als voorbeeld diende.

Om te beginnen, is duidelijk dat het functioneel testen van de happy flow belangrijk is, net als het testen van het proces. Het testen van aanpasbaarheid van de applicatie is een ander verhaal. Vanuit een ontwikkelperspectief was dit al wel snel duidelijk: Als code je deliverable is, en niet een gecompileerd object, moet de code goed leesbaar zijn. Coding-standaarden en code reviews moesten ervoor zorgen dat de code goed leesbaar was (alsof ze door 1 persoon was geschreven).

Vanuit een testperspectief werd dit pas duidelijk toen we daadwerkelijk met de testen waren begonnen. De stubs die standaard waren gebouwd, waren vaak niet afdoende om alle relevante paden in het proces te dekken of om een goede uitgangssituatie te creëren voor functionele testen van stukken functionaliteit aan de achterkant van het proces. Een optie in zo’n geval is om de testdata aan te passen, maar een alternatief was de meegeleverde stubs aan te passen.

Omdat we als testers met enige programmeerervaring blanco naar een stub konden kijken en beoordelen of we deze konden aanpassen, waren we in feite precies hetzelfde aan het doen als een externe partij zou doen. Daarbij werd geaccepteerd dat als wij, als testers, de applicatie konden aanpassen, andere ontwikkelaars dat ook moeten kunnen. Bijkomend voordeel was dat we functionele testen verderop in de keten deden op basis van door de hele keten gegenereerde data, niet door de database handmatig aan te passen.

Het testen of je van de applicatie een productiewaardig systeem kan maken, hebben we bijvoorbeeld gedaan door te testen of de applicatie database-onafhankelijk is. We hebben H2 database als uitgangspunt genomen, een database waarvan niet wordt aangeraden om deze in een productie-omgeving te draaien. We hebben aangetoond dat de applicatie ook met Maria DB valt te configureren.

Tot slot

Belangrijke les voor mij was om als tester niet enkel het correct functioneren van het systeem als vanzelfsprekend te zien, maar ook eisen rondom een systeem als productiewaardigheid. Ik ben benieuwd naar jullie ervaringen!”