Najaarsevenement 2019 : Over testen gesproken

Korte samenvatting presentaties

gebruik ze om je keuze te maken welke presentaties je op 11 september bij gaat wonen!

Over waarnemen gesproken. Van bugs zoeken naar IT-ecologie - Eibert Dijkgraaf

Iedereen ziet wel eens vlinders vliegen, maar zie je ze allemaal? Elke gebruiker ziet wel eens een bug op het scherm verschijnen, maar ben je dan ook een tester?
De spreker neemt je mee in de wereld van het waarnemen van vlinders. Waarnemen is meer dan kijken naar. Een waarnemer ziet veel meer dan de gemiddelde burger. Hoe speur je gericht? Waarom worden sommige soorten in de winter geteld, terwijl er dan geen vlinder rond vliegt?
Een teststrategie en gebruik van testontwerptechnieken lijken in de Agile wereld vaak onder te sneeuwen, maar het maakt dat je juist effectief gaat waarnemen.
Vlinders (aantallen en soortenrijkdom) zijn ook indicatoren van de kwaliteit van complexe ecosytemen en voor klimaatveranderingen. Bugs zijn ook indicatoren, vooral bij complexe ketens of bijv. enterprise data frameworks met gebruikers als complicerende factor. Monitoring leidt tot inzicht in deze indicatoren.
Een tester ziet niet ‘zomaar’ bugs, maar is een IT-ecoloog.

Geautomatiseerde ketentest in de pipeline - Kees Blokland

De ketentest is vaak een hete aardappel die mensen in een organisatie vaak het liefst zo snel mogelijk doorspelen. De organisatie waar ik inmiddels een tijdje werk, worstelt ook al lang met de ketentest, maar nu gaat het lukken. Graag leg ik uit waarom dat zo is.
Het werkveld de ketentest ligt vol met voetangels en klemmen, zoals:
- deelnemende systemen worden ontwikkeld en getest op eilandjes
- de testdata die men gebruikt, heeft de oorsprong in productie
- testdata sluit niet op elkaar aan
- verversen van data is moeilijk/niet mogelijk
- het ‘vergeten’ van data of transacties is moeilijk/niet mogelijk
- tijdreizen is niet mogelijk / lastig
- niemand voelt zich verantwoordelijk voor de keten
En dan willen we ook nog de ketentest iedere dag helemaal, geautomatiseerd uitvoeren en t.z.t. in de deployment pipelines opnemen van de betrokken systemen. Hoe gaan we dat bereiken?
Bij de opbouw van de nieuwe ketentest passen we een aantal principes toe, zoals het ‘vergeetprincipe’, het ‘vullingsprincipe’ en het ‘reserveringsprincipe’. Systemen die deze principes ondersteunen kunnen meedoen. Andere systemen vervangen we eerst door mocks om later om te ruilen door de echte systemen. Inmiddels hebben we op deze manier een aantal ketens draaien!
De principes lossen niet alle problemen op in de voetangels-en-klemmen-lijst. Oplossingen vereisen een lange adem: zo moeten de werkprocessen op een aantal van de genoemde eilandjes flink veranderen (lees verbeteren) om op de nieuwe wijze in de ketentest mee te kunnen doen.
Ik deel alles wat we inmiddels hebben geleerd en laat zien wat we in oktober hebben bereikt!

Testproces en -tool bij de complexe ICT omgeving van de gemeente Apeldoorn – Rob van Gils & Rick Dröge

De gemeentelijke ICT kenmerkt zich door grote diversiteit en complexiteit van bedrijfsprocessen en ICT landschap. De te ondersteunen bedrijfsprocessen variëren van het verlenen van uitkeringen tot het onderhouden van wegen, van het regelen van jeugdzorg tot het verlenen van bouwvergunningen. Elke domein kent hierin zijn eigen cultuur, wensen en werkwijze.
De Eenheid Informatievoorziening heeft een grote uitdaging om samen met de business de kwaliteit bij het realiseren van de wensen op het gebied van de informatievoorziening te borgen. Het goed testen ervan speelt hierbij een belangrijke rol.

In 2016 werd er al wel getest bij de gemeente Apeldoorn, maar dit gebeurde ad-hoc en er was geen gecoördineerd testproces. Hierdoor was er te weinig grip op de kwaliteit van de live-gang. Daarnaast moest het testproces transparanter worden vanwege de diverse audits.
De gemeente Apeldoorn heeft hierin inmiddels flinke stappen gezet met het in gebruik nemen van een gecoördineerd testproces. Daarnaast zijn er 2 test coördinatoren die verantwoordelijk zijn voor de uitvoering en verbetering van het testproces.

In deze presentatie vertellen Rick en Rob jullie over hun ervaringen bij het optuigen en doorontwikkelingen van een testproces bij een grote gemeente.

Shift right als nieuwe kans voor testers - Jan Jaap Cannegieter

Shift right boezemt sommige testers nog wel eens angst in. Testen in productie? Kanaries gebruiken bij testen? Verschillende gebruikers verschillende versies van het systeem geven? Deze angst is onterecht, shift right biedt kansen voor testers om hun werkveld te verbreden en hun toegevoegde waarde te verhogen.
In deze presentatie presenteer is verschillende vormen van shift right, mijn ervaring met twee vormen daarvan en mijn mening over wat testers met shift right kunnen (moeten?). Ik de presentatie leg ik ook een relatie met DevOps.

The Product Quality Trap & The Value Driven Development Solution - Marcel Kwakernaak

Value is a keyword in agile development, yet many of us fail to grasp its meaning or significance. We usually focus on the products we own, and we are absorbed by technological innovations. We rush to develop new features and we want to deliver as much as possible. We may be aware of the importance of the quality of the product, yet we are largely blind for the value to its users. This is why we need to change our orientation from inside-out to outside-in and open our mind for end-user value. If we fail to understand why users value our products or how they benefit from them, we probably will fail to create end-user value in a sustainable way.
Value Driven Development is an approach that encourages teams to engage with real end-users. The objective is to develop products that matter to their users. A working product that is not being used is useless, a quality product that is not being used is pointless. Value Driven teams are user orientated teams. They differ from product driven teams as they first explore how users work instead of how technology works. They want to get it right before they will get it done. Value Driven teams endeavour to limit ambition and to find the minimum viable product (MVP). Users benefit earlier, which enables those teams to evolve faster. Value Driven teams need to be better balanced than product driven teams. They are open minded, explore opportunities, discover the most valuable next step, experiment to fail fast and learn fast about user value.
Testers should step forward & speak up. They have what it takes to lead their teams to become Value Driven teams. They have the skill to really listen to the stories of the users; They are experts in trying out and finding out; They can guide their teams to build valuable tests from the start of the development cycle and help to accelerate the delivery of real user value.

Dat zeg je toch niet!’ Taboeformatie binnen de testwereld - Veerle Verhagen

Taal is onderhevig aan verandering en in iedere taal treedt bij bepaalde woorden taboevorming op. Ook in de testwereld is dit zo: neem de controverse rond het woord ‘tester’, of de koude oorlog tussen testen en checken. Vanuit de historische taalkunde wil ik laten zien dat deze ontwikkelingen natuurlijk zijn. Daarna wil ik laten zien hoe verwarring rondom dit soort taboewoorden beperkt kan worden. Dit doe ik aan de hand van voorbeelden die ik in de praktijk heb meegemaakt en waar ik, langs de taal of juist dwars door de taal heen, een oplossing voor heb moeten vinden. Het is de bedoeling dat dit een luchtige en interactieve presentatie wordt – door gebruik te maken van Mentimeter voor mijn presentatie, kan eenieder met de eigen smartphone input geven op (taalkundige) vragen die ik het publiek voorleg om mijn punten te illustreren. Verder mag er ook heus wel gelachen worden! Key take-aways zijn een zekere bewustwording van waarom bepaalde termen beladen zijn. Daarnaast strategieën om je op neutraal gebied te begeven in je communicatie. Sleutelprincipe is hierin: het maakt geen reet uit hoe je iets noemt, en de semantische discussie is maar beperkt interessant – het gaat zoals bij alles om de inhoud. Tot slot: waarom we ons soms verschuilen achter die semantische discussie, en hoe je dat kunt vermijden.

Nieuwe manieren om entry & exit criteria écht te laten werken - Wim Demey

Entry en exit criteria zijn een cruciaal onderdeel van de teststrategie. Ze vormen een set van voorwaarden waaraan voldaan moet zijn om met testen te starten of naar een volgende fase te gaan
Vanuit de redenering dat wij als testers deze zgn. quality gates zo objectief mogelijk moeten maken, verliezen we ons vaak in het definiëren van ellenlange lijstjes met entry en exit criteria.
Meestal wordt onze voorspelling dan ook bewaarheid, nl. hoe meer criteria je definieert, hoe groter de kans dat ze irrelevant worden en meestal genegeerd worden door de stakeholders. Testers blijven dan gefrustreerd achter en stellen zich (terecht) de vraag wat de waarde is van deze criteria.
Maar werken we dit ergens ook niet zelf in de hand door onze drang naar formaliteit en objectiviteit?
Om entry & exit criteria écht te laten werken, is out-of-the box denken nodig. Dit houdt in dat we op zoek gaan naar alternatieve –ja, zelfs subjectieve manieren- om in consensus met alle stakeholders te beslissen of we al dan niet starten, stoppen of verder gaan met testen.
En het scala aan oplossingen is ruim. Denk aan heuristieken, agile technieken (bijv. planning poker, roman voting, agile boat retrospective, …) of gewoon buikgevoel.
Deze presentatie gaat dieper in op deze manieren en laat zien in welke context ze jou kunnen helpen om entry & exit criteria écht te laten werken.

Een succes maken van Testautomatisering - Het kan echt! - Maarten Beks

Testautomatisering is op zich niet erg ingewikkeld. Evengoed zijn er nog steeds een beperkt aantal organisatie waar het succesvol geïmplementeerd wordt. Vaak wordt er vol enthousiasme een start gemaakt, maar blijkt in de loop van de tijd dat testautomatisering toch niet de verwachte heilige graal is. Het is vreemd dat we er niet in slagen om iets relatiefs eenvoudigs, succesvol te implementeren. Hoe dit kan? Vanuit de praktijk zien we dat er keer op keer dezelfde fouten gemaakt worden. Niet alleen op technisch, maar zeker ook op organisatorisch en communicatief niveau.
De presentatie behandelt in vogelvlucht een aantal succesfactoren om Testautomatisering wel te kunnen verheffen tot de heilige graal.

F-words voor testers - Egbert Bouman

Failing Forward, Fast Frequent Feedback en Fun
Built in Quality in elke fase, snelle feedback, full stack testen, leren van je fouten, het zijn allemaal principes die de snelle ontwikkelcycli van nu kenmerken.
In deze presentatie zien we welke consequenties dit heeft voor het testproces en hoe we als testers de feedbackloop kunnen optimaliseren. Niet meer achteraf onafhankelijk zijn, maar volop participeren in het proces.
Verwacht een onderhoudend verhaal, doorspekt met beelden, anekdotes, paradoxen en doordenkers. En vooral met handvatten waar je plezier van gaat hebben in jouw praktijk als up-to-date tester anno 2019

In Amerika zijn voice assistants niet meer weg te denken en ook in Nederland beginnen ze inmiddels flink terrein te veroveren. Maar zijn we daar als testers ook al klaar voor? Waar moet je op letten als je voice applicaties gaat testen? Wat is het belang van een uitgewerkte gespreksflow? En welke acceptatierichtlijnen hanteren Google en Amazon eigenlijk zelf? Tijdens deze sessie deel ik bevindingen over het testen van voice applicaties en biedt jullie praktische tips zodat je goed beslagen ten ijs komt bij je eigen voice assistant project!

Onbevredigd over Testautomatisering? Reduceer je False Negatives!

Hoe kan het dat het ene testautomatiseringsproject wel succesvol is, terwijl het voor andere teams enorm worstelen is? Aan de kwaliteit van de testers en de test automation engineers lijkt het niet te liggen en ook de tooling lijkt niet de oorzaak van de moeizame voortgang van best wel veel teams.

In deze presentatie wordt naar het belang van een zo groot mogelijke controle over (test-) data gekeken als verklaring voor het succes dan wel de teleurstelling van test (automatiserings-) projecten. De fundamenten van informatiesystemen en softwareontwikkeling worden besproken op zeer begrijpelijke wijze. Welk effect heeft data op code paden en welk impact heeft dat op het testen? Met behulp van de concepten False Negatives en State Control krijg je inzicht in de oorzaak van deze problemen en wordt een richting aangegeven hoe het testproces te verbeteren.
 

Alexa, please automate my voice testcases -Robby Wiegmans

“Alexa, open test skill”,
“Alexa, tell test skill to start a game”
“Alexa, tell test skill I want to play”
“Alexa...”
Het ontwikkelen van voice-apps (Skills) met de slimme assistent Alexa, vind ik persoonlijk leuk om te doen. Er zijn zoveel mogelijkheden om innovatieve gebruikerservaringen te creëren: van dialogen tot quizzen. Maar testen van Alexa skills vond ik een lange en moeizame taak, waarbij ik honderden dialoogvensters handmatig moest doorlopen.
Als tester bedacht ik mij: waar moet ik beginnen met het efficiënt testen van spraakcommando’s, welke tools zijn er, en kan ik testautomation toepassen?
Graag vertel ik je mijn ervaringen met het testen van Alexa en geef ik je een concept om Alexa dialogen te testen zonder te praten en testen in slechts enkele seconden af te ronden. Als laatste geef ik je mijn ‘lessons learned’.

Hoe snel durf jij te rijden zonder remmen - Bas Dijkstra

Goede testautomatisering functioneert als de remmen op een auto. Zoals J.B. Rainsberger zich een jaar of vijf geleden al afvroeg: hoe snel durf jij te rijden zonder remmen? Vertaald naar ons vakgebied: hoe snel durf jij te releasen zonder een degelijke set geautomatiseerde tests die je inzicht geeft in de kwaliteit van je product?
Helaas worden die remmen op het development- en delivery-proces te vaak gemonteerd door monteurs die:
- Niet weten welke remmen ze moeten kiezen
- Niet weten hoe ze die remmen moeten monteren
- Die remmen niet testen of ze wel goed functioneren
Met alle gevolgen van dien…
In deze presentatie licht ik toe, aan de hand van de ervaring die ik de afgelopen 14 jaar heb opgedaan, hoe we door de juiste remmen te kiezen en ze juist te monteren, uiteindelijk sneller durven en kunnen rijden.

Shift left performance testen, bestaat het echt - Michael Kok

Het is opvallend dat in Scrum teams het functioneel testen binnen een half uur begint nadat nieuwe software wordt opgeleverd, terwijl performance testen vaak dagen tot weken later begint. Hierdoor bestaat het risico dat te lang wordt doorontwikkeld op een niet levensvatbaar ontwerp, waardoor projecten onnodig vertraging oplopen. Performance testen met een zelfde korte cyclus is goed mogelijk, maar stelt de performance tester voor een aantal nieuwe hindernissen, die stuk voor stuk te overwinnen zijn. Het vergt een aangepaste methodologie gebaseerd op andere dan de gebruikelijke paradigma’s. Ook moet een aantal randvoorwaarden ingevuld zijn.
In deze presentatie deel ik recente praktijk ervaringen opgedaan in een paar Scrum teams en laat ik zien hoe dit in de praktijk werkt en ga ik in op de hindernissen en de randvoorwaarden waarmee de performance tester te dealen heeft.

Removing the “hot gates” of QA, the E2E tests - Prabhuram Govindarajan

The "hot gates" in Thermopylae, is a mountain pass where King Leonidas and 300 of his Spartan warriors fought millions of Persians during Xerxes’ invasion of Greece in 490 BC. The hot gates was a classic bottleneck that slowed down the Persian army. Similarly in QA, End to End(E2E) tests are the hot gates which slows down the software going to production.
In a leading Dutch company where the E2E test was slowing down the teams, instead of fixing the environment problems, the real question to which we found an answer was “do we really need an E2E test?” In the Devops world, it’s important that we redefine the way we do E2E test.
If we do not have an E2E test environment, the key questions that came out of the sessions we had with the project teams were:
- How do we test the connected systems in an integrated fashion?
- How do we make the stubs intelligent to replace all interfaces?
- How do we create test data which is representative and consistent for the whole system landscape?
- How do we know we are testing enough?

The answer lies in accurately organizing many solution levers like #ServiceVirtualisation #Contracttesting #ArtificialIntelligence #SmartMonitoring #TestInProduction

De verrassende parallellen tussen testen en topsport - Nick van den Heuvel

Heb je ooit in een team gezeten dat niet presteerde? Waar doelen niet gehaald werden? Is er teveel chaos om je heen? Voel je je niet in je kracht? Heb je het gevoel dat jij en je team meer kunnen bereiken? Het is nooit te laat om nieuwe doelen te stellen en de weg naar boven weer in te zetten!
In 2005, na een rustperiode van 4 jaar, kwam de liefde voor mountainbiken weer terug. Zodra ik op de fiets zat, wakkerde de passie weer aan, kreeg ik een heldere geest en begon ik nieuwe doelen te stellen. Negen jaar later greep ik de eerste plaats bij de Nederlandse Marathon kampioenschappen nadat ik had geleerd hoe ik kon focussen en mijn fysieke, mentale en technische vaardigheden sterk had verbeterd. Natuurlijk had ik talent, maar mijn mindset, zelfreflectie, energie en mentaliteit waren doorslaggevend bij het pakken van die titel.
Gedurende de jaren op fiets ontdekte ik veel paralellen tussen de topsport en mijn werk als tester. Ik wil graag delen wat ik heb geleerd als sporter en inzicht te geven hoe je meer grip kunt krijgen in je werk, de controle terugkrijgt, jezelf en je team kan verbeteren en je lekkerder gaat voelen.