Datumwoensdag 15 mei 2024
Tijd09:00 - 21:00u
Westkanaaldijk 7
7354DA Utrecht

Wederom bieden we een mooi gevuld programma aan; zet de datum in je agenda!

*) aanmelding geldt voor hele evenement; alleen voor bijwonen workshops  moet een selectie gemaakt worden.

Een pendelbusje rijdt van NS station Maarssen (kanaalzijde) naar DeFabrique tussen 12:45 - 14:15 en tussen 21:15 - 22:15


Ochtendprogramma: Workshops

09:00 - 13:00

Jutekelder | Marianne Duijst

A hands-on journey to visualization and listening
Ready. Steady. Draw! Listen. Brainstorm. Visualize. Experiment & Share.

Sketchnoting is a creative way of taking notes of talks, trainings and meetings. Through a unique combination of text and graphics,
sketchnotes highlight the core of the sessions, focus your attention and allow you to communicate ideas more quickly and widely.

Visualisation helps wonders when brainstorming new ideas, such as test charters, product creation or retrospectives. There’s something about seeing your and your team’s ideas beautified on the page that really sparks your imagination and wild ideas.

Luckily, you do not need to be an artist or a creative genius to harness the power of sketchnotes. Join me on this hands-on journey to improve your notetaking skills. Put pen to paper and experiment.
Improve your attentive listening. Allow yourself time to slow down in order to speed up. Expand your visual library and combine
visuals with text. Choose your constraints and dare to share your work . Learn how to harness the power of sketchnotes and visualisation in office.
This workshop is suitable for everyone who is willing to experiment regardless of artistic skill.

Meelzolder | Bas Dijkstra

API calls are responsible for 83% of all internet traffic.
No wonder that malicious parties are increasingly trying to use APIs to gain access to systems and data.
That is why it is important that we as testers have insight into the security of the APIs that our systems use.
But how do you actually do that? And isn’t that very complicated?

In this workshop we use the OWASP API security top 10 of 2023, looking at some of the most common security vulnerabilities for APIs, and how we can create valuable tests without specific tools or in-depth specialist knowledge, to better understand security of the data and systems that unlock our APIs.

At the end of the workshop you will have seen how you can test for common API security vulnerabilities with a dose of common sense and creativity.

Postkamer | Erik Deibert & Maarten Beks

In a modern application landscape and architecture, an API layer is indispensable.
This also means that in a Test Strategy attention for testing and automating these APIs must be present.
An API unlocks a bit of functionality that can be tested perfectly autonomously in isolation.
But which tool is best to test such APIs?
A market research shows that Playwright is increasingly gaining popularity. Although Playwright mainly is used for test automation at GUI level and “Visual Testing”, Playwright also offers extensive options for automated testing of APIs and even mocking.

In the workshop “API Testing with Playwright” the participants are simply included in the possibilities that Playwright offers for testing and mocking APIs.

Douchelokaal | Sander van Beek

Security (secure development) is very important for most organizations, yet few testers dare to touch it.
Learn the basics so you can assist specialized security testers.
Learn to use different tools and ways you can test security.

Havenmeester | Fin Kingma

Component testing can cover your functional acceptance criteria within your build. This is possible without external dependencies and helps developers gain more control on the quality of their own code.
Component testing is particularly useful for testing microservices and enables teams to make changes without spending much time on fixing their tests.

During this workshop you will create component tests for a SpringBoot microservice, using Java17 and Cucumber.
We will start with setting up the component tests and step by step you will experience the most common technical challenges and learn how to deal with them:
– setting up the component test framework
– Rest assured to test the Rest APIs
– Creating test data via the repository
– Event Based using Kafka
– Authorization with JWT tokens

Reference component testing:

Plenair: Opening & Keynote

14:00 - 15:15

Plenaire zaal |

Sponsoren zullen zich kort introduceren

Plenaire zaal | Testnet werkgroep Sustainability

De ontwikkelingen op het gebied van duurzaamheid met betrekking tot IT / Testen.
Debat: Wat is meer Sustainable?
1. Een moestuin of een supermarkt?
2. Een eigen server (on-premise) of een dataserverpark (Cloud)?
3. Een eigen auto of een deelauto?
4. Contant geld of digitaal geld?
De vragen komen rechtstreeks uit de Toolkit, pagina 20 t/m 24

Dit wordt een debat in Ronde Tafelgesprek vorm. Iedereen kan iets zeggen, elke deelnemer is gelijkwaardig met een moderator om te faciliteren.
Het idee is bevorderen van dialoog en naar elkaar luisteren. Het onderwerp is rond sociale, ecologische en economische

Boris Schouten en Emile Nieborg geven in een korte inleiding de vragen duiding en welke duurzaamheidsaspecten verborgen gaan achter IT en testen.
Daarna kan het debat starten.


15:30 - 18:15

Jutekelder | Rowena Belt

In my role as a Test Automation Engineer, I faced a challenge many might recognize: minimal documentation, no test automation, and a missing test strategy. But I didn’t back down, I took charge!
In this presentation I will talk about how I set up the test automation for my own team and how I integrated it in an overarching test strategy. This not only gives you back the control over the whole testing process but also helps you to look with a critical eye to your own work. And your team gets a visible test approach and therefore more confidence in the whole test process.

The most important take-a-ways are:
 What is the importance of a test strategy and why it isn’t difficult to start with one.
 How do you bring together test automation and manual testing in a strategy where it doesn’t matter how you test.
 What is the positive impact of a test strategy on your own testing and test automation and how can it impact your team.

Meelzolder | Boyd Kronenberg

On-demand testomgevingen zijn innovatief en essentieel voor snellere feedback over kwaliteit en risico’s in vergelijking met traditionele testomgevingen.
Tijdens mijn presentatie wil ik de TestNetters inspireren met de voordelen van on-demand testomgevingen, waaronder geïsoleerde productie-like systeemtesten, tijdelijke omgevingen en een breed scala aan use-cases.
Bovendien zal ik uitleggen waarom deze technische implementatie uitstekend past bij een cloud-native architectuur.
Daarnaast bespreek ik trends in ons vakgebied die de behoefte aan on-demand testomgevingen versterken.
Hiernaast zal ik benadrukken dat teams hun engineering mindset niet mogen (laten) verwaarlozen.
Ontdek bottlenecks en pas quality engineering toe om innovatieve oplossingen te realiseren.
Zo is ook mijn eigen ervaring met on-demand testomgevingen ontstaan!

Postkamer | Marianne Duijst

An Agile Quality Coach encourages team members and stakeholders to embrace quality engineering and make quality tangible for the product, process and people involved at both teams and organizational level.
More and more agile teams are actively embracing the value that an Agile Quality Coach brings. What are the key essentials to have in
your backpack/toolbelt to get started with Quality Coaching?
What do teams and organizations need to arrange to truly get the benefits of Quality Coaching?

Come listen to Marianne share her experiences, learn more about Testability, Psychological Safety, and the application of Quality Coaching to boost your experience and understand the role in-depth.

Douchelokaal | Frank van der Kruijssen & Perry van Wesel

Automatic testing has traditionally always focussed on specific test scenarios, from low-level unit testing all the way up to automated acceptance testing. These tests follow a static script to ensure their functionality is covered. This kind of testing is – and will remain – important, but it has the flaw that it will always be limited to the test scenarios imagined up front. We have all seen issues occur in software missed by tests, simply because it did not occur to us before.

This is where Model-Based Testing comes in. In contrast to traditional, scenario-based testing, no test scenarios are written up front. Instead, a model of the system behaviour is specified that describes the dynamic behaviour of the system as influenced by outside stimuli. The tester program will then automatically dream up test scenarios to try to explore on the model. This means the tests are not limited to one static set of scenarios, but are more like the process of manually testing a system like QA does: just trying some things and seeing what happens. This will not only find problems foreseen up front, but also problems not foreseen, reducing the number of issues slipping through.

We will discuss what Model-Based testing is, how it works and how we apply it on real systems.

Havenmeester | Frank van der Kuur

This presentation covers the essential building blocks for a successful design of test automation from practical experience.
Not only the technological challenges, but also the impact of process, people and organization in architecture are discussed.
Often at the start of a TA implementation, mainly attention is paid to the technological challenges. Valuable, because if later it turns out that the solution cannot handle these challenges, success is ruled out in advance.
Identifying these challenges and finding the right answers to them in practice appears to be very difficult.
Even if answers are found it still is no guarantee for success.
Least as important is that the TA architecture takes into account the organizational goals, the people who work there and the existing (or future) development process.
As a test consultant, Frank has worked on quite a number of TA implementations.
During this interactive presentation Frank will discuss the essential cornerstones to successfully set up an architecture for a (new) TA solution. Using practical examples he will show what questions he asks during an implementation process and what impact the different answers have on the final architecture.

Postkamer | Gilbert Smulders & Marcel Mersie

In een korte presentatie leggen wij uit wat TMMi is en wat je daar als tester aan hebt.
Tijdens het najaarsevenement bleek wel dat TMMi helemaal nog niet zo bekend is binnen de huidige testwereld.
Een aantal jaar geleden wisten de meeste testers wel van het bestaan van verbetermodellen als TMMi, TPI en CMMi. Maar tegenwoordig werkt iedereen Agile, DevOps, of iets vergelijkbaars en verbeteren we ons proces continu via de retrospectives.
De eerder genoemde verbetermodellen zijn we inmiddels vergeten.
Maar wil je echt het verschil maken binnen de organisatie, dan moet je toch wat verder kijken dan alleen je eigen team. Dan zijn toch deze verbetermodellen een heel interessant hulpmiddel. En nee, we zeggen niet dat je de organisatie moet gaan certificeren voor een volwassenheidsniveau. Maar het TMMi model kan je wel enorm helpen om echt structurele verbeteringen te realiseren
en te borgen.

Marcel en Gilbert zullen in hun presentatie het TMMi model uitleggen en wat het voor jouw organisatie kan betekenen. Daarnaast zullen ze je praktische handvatten geven om echt zaken te verbeteren in jouw dagelijkse praktijk.

Jutekelder | Richard Ammerlaan

The Illusion of Controlling a Test Environment – Challenging 5 Test Automation Illusions

Description of undertakes to manage the 5 most important aspects that frustrate testing and specifically test automation within a test environment (software and data versions, E2E chains, the behavior of other teams and the basic properties of the software that needs to be tested).
What can you check and what solutions solve multiple problems same time?
Technologies used are pipelines, test data management, service virtualizations and design/monitoring/dashboard tooling to tie everything together in kind of Digital Twin.

Meelzolder | Joost van Wollingen

As the role of test engineers evolves, we are more and more exposed to running applications in production environments.
There’s a high chance that you and your team are responsible for deploying and operating software in production.
Observability can be a wonderful addition to a testers toolbox AND we have a role to play in our teams efforts to set up great observability. Join this session to learn what observability is, how it relates to testing and how you can have a positive impact on your team through observability.

Observability allows test engineers to tap into new, potentially unexplored feedback loops. During testing observability can be used to inspect side effects that otherwise might not be visible on the UI or API.
Having observability tooling available while testing and investigating bugs will make you more effective in hunting down and pinpointing defects. At the same time, observability for new features should be checked by test engineers for accuracy.
After releasing to production, observability can help you establish a feedback loop with your customers. Good observability is not only about technical metrics such as memory and CPU usage, but should be about your features.
How are users interacting with your system?
It might even help you to detect issues before your customers even notice.

We’ll clarify the Three Pillars of Observability, logs, metrics and traces.
What are they and when should you use them?
Where to get started with observability?
I’ll share some ideas on workshops you can do with your team to get the most important metrics out.

What to watch out for:
• Alert fatigue, all alerts should be clear, concise, actionable and provide access to the data
• Costs. Measuring is good, but measuring too much can get very expensive, very quickly.

3 take-a-ways
• What are the most important types of observability? (logs, metrics, traces)
• Why should you care about observability as a test engineer?
• How can you leverage observability to be a better test engineer?

Postkamer | Prince Sethiya & Albert Eikelenboom

We are from ING Bank and working in the Core bank department you can say ”The Heart of the bank”. 
We aim to highlight our transition from HP ALM and HP UFT, Hyper-V, and over 25 virtual machines to a more advanced setup involving Robot Framework, Selenium, Git, Docker, and Azure Cloud.
This transformation encompasses the migration of more than 1000 test cases to these modern frameworks, showcasing our adaptability and commitment to staying at the forefront of technological advancements.

 As part of our journey, we have not only adopted new tools and technologies but have also invested in the training and development of our colleagues. This includes imparting the necessary skills to effectively work with the new frameworks, ensuring a smooth and efficient transition for our entire team.
One of our major achievements lies in achieving 100% process automation.
This involves the seamless initiation of automatic Daily-Regression and Release-Regression tests, leading to the generation of comprehensive email reports.
This level of automation not only enhances the efficiency of our testing processes but also allows us to respond rapidly to changes in a dynamic development environment.

 Moreover, we take immense pride in our ability to maintain and execute a substantial volume of 4400+ test cases every day.
What sets us apart is our accomplishment in achieving this with the least infrastructure, a testament to our commitment to sustainability and resource optimization. Operating within a continuous delivery model, we have streamlined our testing
procedures to align with the fast-paced nature of modern software development.

Douchelokaal | Eduard Hartog

The operation and control for the Botlek Bridge has been programmed.
An important part of the project was to test redundancy.
In this project has been tried to trace back the testcases for testing redundancy in a structured way using testing techniques.

Havenmeester | Ronald Kerkhoff & Otman Zemouri

Test tool management is een essentieel onderdeel van het succes van DevOps teams. Test tools zijn echter slechts hulpmiddelen die kunnen worden gebruikt om bijvoorbeeld de efficiëntie van het testen te verhogen en de kwaliteit van het test proces verbeteren. Hierdoor zijn DevOps teams beter in staat inzichten in de kwaliteit van het
software product te laten zien.
Door test tool management te implementeren kan dit helpen om DevOps teams beter te ondersteunen niet alleen bij het selecteren en implementeren van de best beschikbare test tools maar ook met het juiste beheer en onderhoud.

Postkamer | Sophie Baksteen

This presentation will cover three examples of ways the test process within the ABN AMRO app team is improved.

There were three recurring complaints from the testers:
– managing the regression test was heavy and difficult
– the regression test process took too long
– the test environment was unreliable so tests could not always be finished within the planned time

For each complaint the cause, actions undertaken to improve the situation and the result of these actions will be presented.
By doing this, hopefully the public will get inspired to take action themselves to tackle their biggest annoyances and make everyday work more fun and easier.

Douchelokaal | Daniël Venhuizen

How do you keep a grip on quality in complex business chains in a Scaled Agile environment where there is a constant cadence of deliveries taking place?
In this presentation Daniël takes the participants through applying Quality Orchestration in practice.
Daniël shares practical stories and fun anecdotes that he himself has experienced as a Test Manager / Chain Director in a Scaled Agile environment at a large non-profit organization.
In addition, the participants are taken into Quality Orchestration based on the latest developments in TMAP: Quality for DevOps teams.
A nice mix of theory and direct application in practice.

The most important message is that the participants of the presentation get an idea of ​​how they can gain insight into what they need to pay attention to with Quality Orchestration, with the aim of being able to do apply this themselves in their own environments.
The tips, trics and anecdotes can be applied in both Scaled Agile and classic Sequential environments (V model).

Jutekelder | Heini Veneberg

Scaled Agile/Agile Scrum zijn goede methodologieën op papier. In de praktijk zien we echter nog steeds dat het lastig is om beloofde functionaliteit goed en tijdig te leveren. Natuurlijk heeft elk teamlid in een Scrumteam of in de releasetrein de intentie om het juiste te doen.
De Product Owner bevindt zich met één been in het Scrumteam en staat daarmee redelijk ver van zijn business af. Omdat de PO “één van ons” moet zijn, zie je dat de tester vaker te maken krijgt met onvolledige user stories. Vaak wordt gedacht dat deze details wel tijdens de sprint zullen worden ingevuld. Als tester blijf je continu worstelen met wat wel en niet binnen de sprint valt.
De Happy Sprint Machine (HMS) zorgt voor 100% betrouwbaarheid in leveringen. Hoe dan? Door de backlog realisatie op een andere manier te organiseren.
De Product Owner wordt meer betrokken bij zijn business, waardoor hij een betere connectie heeft met zijn dagelijkse werkzaamheden.
Via de HMS vullen we het gat dat hierdoor ontstaat, en de tester krijgt een goede sparringpartner erbij. De tester krijgt vervolgens een prominente rol bij de oplevering, samen met een delivery manager.
Een bijkomend voordeel is dat het niet uitmaakt waar het
ontwikkelteam zich bevindt. Het feit blijft dat de betrouwbaarheid van leveringen 100% is en dat de tester meer tijd heeft om te testen, wat de kwaliteit enorm verbetert.

Meelzolder | Karl van Heijster

Eerst programmeren de programmeurs, dan testen de testers: het komt niet vaak voor dat zo’n voor de hand liggend idee zoveel
misvattingen herbergt. Welk aannames liggen ten grondslag aan dat idee? En wat gebeurt er wanneer we die aannames kritisch tegen het licht houden?
Dan verandert ons idee van software ontwikkelen ingrijpend.

In deze sessie blik ik terug op de verander(en)de manieren waarop mijn team de afgelopen jaren software heeft ontwikkeld, en welke rol tests daarin hebben gespeeld. – Wie test er? Hoe? Wanneer? En vooral: waarom?
Op al die gebieden hebben we hardnekkige aannames (moeten) herzien.
Aan het eind van deze sessie ben je je bewust van enkele ingesleten patronen in de manier waarop je software ontwikkelt en test.
Het zal, met een beetje geluk, de eerste stap naar verbetering zijn.

Postkamer | Wouter Ruigrok

Generatieve AI zoals ChatGPT, Gemini, Claude en anderen zijn “the talk of the town”. En wij zijn ervan overtuigd dat GenAI het leven van iedereen gaat veranderen.

Binnen Sogeti ontwikkelt een team onder aanvoering van Wouter Ruigrok de GenAI Amplifier, dit is onze toolbox waarmee quality engineers hun werk effectiever en efficiënter kunnen doen.
In deze presentatie vertellen wij: Wat gaat GenAI voor testers betekenen?
Hoe kan GenAI ons kwaliteits- en testwerk ondersteunen?

In deze presentatie legt Wouter uit waar deze GenAI Amplifier nu staat, hoe op dit moment het werk van testers al prima ondersteund wordt, en hij licht een tipje van de sluier op van wat er allemaal nog gaat komen. Want één ding staat vast: de ontwikkelingen met GenAI gaan razendsnel.

Wil jij weten hoe ook jouw werk op korte termijn gaat veranderen? Laat je dan inspireren in deze interactieve sessie!

Douchelokaal | Johan de Wijs

As is being done in chemistry for many years, it is possible to measure data quality by performing statistical analyses on data loads.
By building a data quality framework in the database itself and letting the database server doing all of the hard work, anomalies in data loads can be visualized beautifully a in Power BI report.

The importance of data quality checks on data loads in data warehouses will in itself surprise nobody. The way in which statistical
measurements can be utilized to achieve this result just might.
Briefly I will introduce the statistical methods involved and how they can be applied within a database server to analyze data loads. Then I will explain how to interpret and export these results to a reporting tool where they will be displayed in a dashboard. There are a few different strategies one could follow regarding implementation when considering the underlying data model. These will also be discussed.

All will be demonstrated with the use of a SQL Server test database with which I simulate the load sequence of a data warehouse. To avoid performance issues and make the presentation run smoothly I have pre-loaded these loads into an indexed staging area (loading a data warehouse can take a long time!). Data loads spiked with corrupt and deviating data will then show the audience the test results in a Power BI report.

To conclude I want to demonstrate briefly how Power BI can be used to provide insight in data issues which are otherwise hard to spot.

Havenmeester | Egbert Bouman

Mike Cohn’s well-known test pyramid tells us that the center of gravity should be at the unit testing at the bottom of the pyramid.
That pyramid is popular for a reason, but I would like to present one alternative that better suits our needs today: the Christmas tree model, with the center of gravity in the middle.
Because unit testing always causes hassle and discussion among testers and developers, while the real trouble is always in the interfaces and coupling surfaces.
New concepts such as Contract Based Testing (CBT), PACT and Trophy Testing respond to this.
There is also coming better tooling for stubbing, mocking and virtualization (‘test doubles’) and automatically setting up and breaking down environments (‘infrastructure as code’) and test data, wíth links.

I would like to discuss this with the audience, with the Christmas tree model as a starting point for a state-of-the-art automation strategy.
I will include the insights in my AutomationSTAR presentation on the same theme, October 9 in Vienna.


19:25 - 20:10

Jutekelder | Huib Schoots & Rik Marselis

Hoe groot zijn de verschillen in het testvak nu eigenlijk?
Huib en Rik nemen je mee in een interactieve discussie (waar jij dus ook aan mee doet!).

Rik staat bekend om zijn werk in de TMAP-gemeenschap als de hoeder van het TMAP-gedachtengoed. Terwijl Huib bekend staat om zijn werk in de context-driven testgemeenschap en hij een van de vijf Rapid Software Testing-instructeurs ter wereld is.
Sinds kort is Huib een collega van Rik bij Sogeti. Voor velen was dit een verrassende, maar ook interessante stap. Sindsdien werken zij samen om binnen Sogeti onder andere collega-professionals bij te spijkeren.
Tijdens hun samenwerking kwamen ze er opnieuw achter dat er allerlei verschillen zijn, maar net zo zeer ook vele overeenkomsten.

In deze interactieve sessie vertellen Rik en Huib over hun visie op de testwereld. Het belangrijkste is dat ze een zeer vergelijkbare kijk hebben: we moeten het echt beter doen en ons best doen!
Maar als je naar de details kijkt, verschillen ze ook wel van mening.
Tijdens dit interactieve gesprek bespreken Rik en Huib het verbeterpotentieel van de testwereld. Wat kunnen we doen om betere
testers te worden? Wat moeten moderne testers doen om relevant te blijven?
Huib en Rik kijken vanuit hun eigen perspectief, wat op zichzelf interessant is. En door de overlap en verschillen te vergelijken komt er een waardevol perspectief. Daardoor is deze sessie een “must-see” voor elk lid van TestNet.

Meelzolder | Pieter Withaar

What do the years 1994, 1999 and 2023 have in common? They all mark the moment that new technologies became widespread and affordable.
While some still consider these innovations superfluous (“I have an answering machine, right?”), others consider them indispensable (“Did you really write this without ChatGPT!?”).
During such periods, applications and developments evolve at an astonishing speed. While fleeting hypes (“SMS RINGTONE ON to 2020”) follow each other in quick succession, it is other technological developments that really bring about significant changes. Recognizable?

While current advances in AI are fundamentally different, the past offers valuable lessons. Combining these lessons with a deep understanding of AI allows us to look ahead to the future.
This is not just about the technology itself, but especially about its impact on people, our behavior and its consequences. And from there we can look at the impact AI has on our work.

Douchelokaal | Elout van Leeuwen

De afgelopen jaren heeft Robot Framework flinke stappen gemaakt en blijft actief doorontwikkeld worden. Niet alleen de tool zelf, ook het ecosysteem er om heen wordt steeds volwassener. Als je in het verleden Robot Framework hebt uitgeprobeerd, of je wil een kort overzicht van deze tool, is deze presentatie voor jou.
Ik neem je mee in de mogelijkheden van Robot Framework en de belangrijkste wijzigingen in de afgelopen jaren.

Havenmeester | Marek Lof

Wanneer we proberen betekenis te geven aan de wereld van Testen, Innovatie, Automatisering en Kwaliteit, kunnen we niet anders dan een paar gemeenschappelijke noemers zien. Deze hebben te maken met het leiden door eerst de basisprincipes onder de knie te krijgen in drie belangrijke stappen; de voetheuvels, bergen en pieken van het implementeren van test- en automatiseringsvolwassenheid, en vervolgens het opnemen van nuttige handvatten zoals Human Reinforced Quality Assessments om het proces van het implementeren van AI/ML- capabilities te beheersen binnen je nu volwassen en geüpgrade teststrategieën en automatiseringsplatforms.
Dit andersom proberen te doen werkt niet!

Ik deel enkele inzichtelijke ervaringen uit de praktijk als Test Lead, die je direct kunt implementeren en auditen op jouw eigen test- en automatiseringsrealiteit met praktische checklists van versnellende innovatieve start-ups en worstelende legacy-organisaties met betrekking tot het verbeteren van jouw test- en automatiseringsaanpak en klaar maken voor het implementeren en gebruiken van HRQA- en AI/ML-capaciteiten.
En hoe gaan we dit beheren in een wereld waar testen nog steeds een van de belangrijkste vertragingen is voor soepele releaseflows, waarbij security en privacy net zo belangrijk zijn als correcte en schone code voor werkende producten.

Laat me je een verhaal vertellen, kom zitten, blijf even en luister, test niet.

Plenair: Keynote

20:15 - 21:00

Plenaire zaal | Linda van de Vooren

Have you ever felt like you didn’t belong? Have you been afraid someone might unmask you? Do you diminish compliments others give you because you didn’t really try it that hard but you managed somehow? Well, I did!

After I quit studying and ended up without a diploma, I found myself doubting my abilities, working next to people with a normal education, like having a university degree.
I felt like I had to prove myself and out perform them, to prove I was good enough. I was afraid they could catch me.

Impostor syndrome is feeling like an impostor, doubting your skill, talent or proven accomplishments. Even if it is proven, it might feel as if you were lucky, or as if this was so easy that anyone could have done it.
Maybe you feel like you’re pretending to be intelligent and feeling successful, but you’re convinced you really aren’t, it’s just luck.

I was recently contracted at a bank (for 3,5 years) and work on a global project as a testmanager in a technically and politically challenging field, and I was kicking ass!
But wait..what about my impostor syndrome?
I have had to set aside my doubts in my abilities, by following a couple of guidelines (and getting a good psychologist!).
I have managed to turn my impostor syndrome around, to it being my personal incentive to do better, not perfect. I’d like to share with you my story and my lessons learned that got me to the place I am today.


De borrel is tussen de informatiemarkt, dus mocht je nog geen rondje gemaakt hebben, ga overal nog even langs!