TestBash Netherlands Online 2020

Ministry of Testing has partnered with Huib Schoots again to make sure that from Monday 12th to Friday 16th October, there are plenty of learning opportunities for everyone in this new Online format. How cool is that?

All announced timings will run in line with the Dutch timezone (CET or UTC+1).  

We’re opening the week with the very popular 3-day training course: Automation in Testing with Richard Bradshaw and Mark Winteringham. Ticket prices for the Automation in Testing 3-day training course starts at a Super Early Bird rate of €1000. Places are limited so get that request into your boss as soon as you can. 

We follow that with 5 world-class full-day workshops in a diverse mix of topics - will one of them fit your appetite for learning? Tickets are limited to 25 attendees workshop, so get yours now so you don't miss out! Workshop ticket prices start at €400 for the Super Early Birds amongst you. Get in quick as some Early Bird Tickets are already sold out!

We conclude the week with our beloved single track conference day, TestBash, where we’ll have 10 talks and our Community Space for added learning opportunities in the breaks. All of this for a single ticket price of €99 per person!

Pro Ministry of Testing members get €25 off the workshops and conference day for TestBash Netherlands Online 2020! Not Pro? Sign up today and save on your TestBash tickets, but also get access to every past TestBash talk, online courses and a whole lot more.

 

Speakers

Jim Holmes

Jim Holmes

Consultant

Alex Schladebeck

Alex Schladebeck

Head of Quality / CEO

Zeb Ford-Reitz

Zeb Ford-Reitz

Technical Lead

Pierre Vincent

Pierre Vincent

Infrastructure & Reliability Manager

Lianne Klaver

Lianne Klaver

Test Engineer

Eveline Bongers-Staal

Eveline Bongers-Staal

Test Engineer

Ash Coleman

Ash Coleman

Engineering Manager in Quality

Richard Bradshaw

Richard Bradshaw

BossBoss

Mark Winteringham

Mark Winteringham

DojoBoss

Shivani Gaba

Shivani Gaba

Senior QA

Lina Zubyte

Lina Zubyte

QA Consultant

Ali Hill

Ali Hill

QA and Continuous Delivery Consultant

Lucian Adrian Stroie

Lucian Adrian Stroie

Technology Lead

Saskia Coplans

Saskia Coplans

Founder and Security Consultant

Jarsto van Santen

Jarsto van Santen

Test Automation Engineer

Jurian Jilderda

Jurian Jilderda

Test Automation Engineer

Pedro Gonzalez

Pedro Gonzalez

Technical leader

Geoffrey van der Tas

Geoffrey van der Tas

Quality/Team Performance Coach

Bauduin  Alexandre

Bauduin Alexandre

Senior tester, Airline pilot, inventor...Make it work!

Schedule

Monday, 12th October 2020

Training

What You Will Learn On This Course

Getting ready for the course

To maximise our live online time together, we’ve created some self-paced online content to set the foundation for the class, allowing us to hit the ground running with some example scenarios.

Day One

Day one begins with an introduction to the Automation in Testing mindset and then hits the ground running by kicking off the three-day roleplay. The start of the roleplay focuses on analysing our product, project and processes and visualising what we’ve learnt to inform us on what opportunities exist for automation. The afternoon then uses that new visualised knowledge to help us plan what we want automated checks we want to create.

Day Two

The first half of day two will continue with our focus on automated checking. We are going to explore what it takes to design and implement reliable focused automated checks. We’ll do this at many interfaces of the applications.

The second half of the day focuses on the techniques and skills a toolsmith employs. Building tools to support all types of testing is at the heart of AiT. We’re going to explore how to spot opportunities for tools, and how the skills required to build tools are nearly identical to building automated checks.

Day Three

Day three takes a step away from automated checking to explore an area of automation in testing that is often ignored. Building tools to support testing activities. Through a series of hands-on activities and challenges, you will learn how to speed up your testing and get deeper into your applications through a range of different tools. 

Frequently asked questions

What will I need to bring to the event?

As this is an online event you will need:

  • Strong stable Wifi that will enable you to connect to the training
  • A headset and Webcam so you can collaborate with your fellow attendees and Mark and Richard
  • A PC running, OS X, Linux or Windows

The rest of the prerequisite tools to install will be sent to you before the training. Mark and Richard also offer support with setup if you get stuck.

Do I need to be already currently working in automation to attend this course?

This course caters for every level of experience of working in an automation context. If you do work with automation already, we believe this course will provide you with numerous new ways to think and talk about automation, allowing you to maximise your skills in the workplace.

If you don’t, this course will show you that the majority of skill in automation is about risk identification, strategy and test design, and you can add a lot of value to automation efforts within testing.

I don’t have any programming skills, should I attend?

Yes. The online courses will be made available several months before the class, allowing you to establish a foundation ready for the face to face class. Then full support will be available from us and other attendees during the class.

I don’t work in the webspace, should I attend?

The majority of the tooling we will use and demo is web-based, however, AiT is a mindset, so we believe you will benefit from attending the class and learning a theory to apply to any product/language.

I’m a manager who is interested in strategy but not programming, should I attend?

Yes, one of the core drivers to educate others in identifying and strategizing problems before automating them. We will offer techniques and teach you skills to become better at analysing your context and using that information to build a plan towards successful automation.

What languages and tools will we be using?

The current setup is using Java and JS. Importantly though, we focus more on the thinking then the implementation, so while we’ll be reading and writing code, the languages are just a vehicle for the context of the class.

Takeaways

  • Describe and explain some key concepts/terminology associated with programming
  • Interpret and explain real code examples
  • Design pseudocode for a potential automated test
  • Develop a basic understanding of programming languages relevant to the AiT course
  • Explain the basic functionality of a test framework
  • Use the principles of Automation in Testing as a guide when working with automation.
  • Survey a given context to better understand its suitability for the use of automation.
  • Design a model of their product to inform them of how and where automation can be carried out.
  • Use visual task analysis to break down complex system behaviour to make it easier to identify automation opportunities.
  • Differentiate testing from automated checking and how the differences inform their automation strategies.
  • Judge what automated checks to build using system knowledge and risk analysis.
  • Design and build valuable automated checks.
  • Analyse automated checks to determine their intent and quality.
  • Experiment with different tools that can be used to support testing.
  • Use automated tools to support testing activities.
Richard Bradshaw
Richard Bradshaw is an experienced tester, consultant and generally a friendly guy. He shares his passion for testing through consulting, training and giving presentation on a variety of topics related to testing. He is a fan of automation that supports testing. With over 10 years testing experience, he has a lot of insights into the world of testing and software development. Richard is a very active member of the testing community, and is currently the FriendlyBoss at The Ministry of Testing. Richard blogs at thefriendlytester.co.uk and tweets as @FriendlyTester. He is also the creator of the YouTube channel, Whiteboard Testing.
@friendlytester
http://www.thefriendlytester.co.uk
Mark Winteringham

Mark Winteringham is a tester, toolsmith and the Ministry of Testing DojoBoss with over 10 years experience providing testing expertise on award-winning projects across a wide range of technology sectors including BBC, Barclays, UK Government and Thomson Reuters.

He is an advocate for modern risk-based testing practices and trains teams in Automation in Testing, Behaviour Driven Development and Exploratory testing techniques. He is also the co-founder of Ministry of Testing Essentials a community raising awareness of careers in testing and improving testing education.

You can find him on Twitter @2bittester or at mwtestconsultancy.co.uk / automationintesting.com

@2bittester
https://www.automationintesting.com

Thursday, 15th October 2020

Workshops

All Day Sessions | 9:00am - 5:30pm
Are you part of a software delivery team, but don't know how to write or read software code? Many testers, business analysts, program managers, and other "non-technical" team members (what a bad label!) are often intimidated by their lack of coding ability. This has a direct impact on team effectiveness, as it impairs good communication in tasks as simple as Three Amigo discussions, or active coding events like pairing or mobbing.

Team members don't need to understand deep, technical aspects of software engineering to be effective contributers when coding. Everyone can make great inputs by understanding a few basics.

This workshop is intended to help team members gain basic comfort at writing software. Workshop attendees will NOT leave this course experts in software engineering. They WILL leave having written four to ten unit tests and the ssytem code to make those tests pass! 

The goal of this workshop is to learn and understand the most basic fundamentals of how works: source code, compilers, interpreters, Integrated Development Environments, and automated testing frameworks. Attendees will spend a bit of time learning basic concepts, discussing and clarifying a basic software example problem, then move straight into firing up an IDE and writing some code. Coding will be done as pairs or groups ("mobs"), so no attendee should feel intimidated about struggling alone!

The workshop will use Visual Studio Code and C#, and is supported for both Windows and Macintosh. Time permitting, examples of Java and Ruby may also be given.

Takeaways

  • Learn enough about code and how it's written to have better conversations with your team
  • Get basic exposure to fundamentals of software craftsmanship such as readability and simplicity
  • Write some automated tests and the system code to make them pass!
Jim Holmes

I test, I coach, I write code. I mentor, I try to learn.

You can see my blog at FrazzledDad.com and catch my Tweet stream at @AJimHolmes. Warning: Plenty of political venting due to the insane environment in this year's awful election cycle in the US. I complain about my awesome teen daughter too.

@AJimHolmes
http://www.FrazzledDad.com
Aren’t unit testing and TDD old news?
 
Well, yes and no. Yes, they have been around for a long time. And many people know about them. And yet… There are (in our opinion) too many projects that don’t use unit testing enough, or correctly. And there is confusion about how TDD really works. And people wrongly conflate unit testing and TDD. Also, it’s easy to find very trivial examples online. But what do unit tests look like when the application starts to become more complex than a standard calculator? 
 
Unit testing and TDD are also a grey area for tester involvement. On the one hand - these are tools used by developers to document, check and design code. On the other hand - we know that test design techniques are relevant and useful for unit testing and TDD (what data are we using? Are my tests independent? What should I check? Are they testing too much? Are they even actually testing something?! Do… do they have an assert?). It also makes sense for testers to know what the unit tests are actually checking - so that they don’t unnecessarily duplicate tests at other levels or don’t have false trust in some mystical, unknown tests. And tester involvement in design through TDD can help catch problems before they become code, as well as provide test ideas and uncover risks to be explored. 
 
In short, it can make sense to involve both the tester and developer perspectives to achieve better results than each person could do alone and to produce high quality artefacts. In terms of whole team quality, we see this as a great move!
 
What’s the workshop going to involve?
 
The main aim of the workshop is for participants to really experience unit testing and TDD - with simple, yet non-trivial, examples. 
 
A developer with an affinity for unit testing and a tester with a passion for unit testing, whose mind was blown by her first TDD experience will guide you through the process of testing (via unit tests) and designing/developing (via TDD) a very small application. Over the course of the workshop we’ll :
  • Look at reasons and motivation for unit testing and TDD
  • Present some theory and definitions (especially of what *isn’t* a unit test!)
  • Do plenty of interactive exercises for unit testing (including mocking) and TDD
 
We'll work together on both tests and code, noting what we learn and what we want to learn in more depth. We’ll spend time working in groups and in mobs.
 
Who should attend this and why?
 
For the reasons mentioned above, both testers and developers should attend this workshop. 
Testers will gain a deeper understanding and real experience with unit testing and TDD and will see how their input can really help with these activities. Developers will (re)experience unit testing and TDD with a focus on quality - both in terms of good tests and in terms of the test perspective. 
 
We have worked on unit testing and TDD with tester/developer groups in our company and are happy to report that all parties had fun and learned things!
 
What do I need?
 
Programming knowledge is welcome but not necessary. Logical thinking skills and a yearning for learning are far more important! 
 

Takeaways

  • Understanding of unit testing and TDD through some theory but mostly practice and experience
  • Ability to recognise good unit tests and TDD practices
  • Awareness of the problems that can crop up during unit testing and TDD
  • Concrete examples on how to involve testers and developers in unit testing and TDD
 
Alex Schladebeck
Alex is a passionate tester whose favourite topics are quality, agility and humans. She is CEO and Head of Quality at Bredex GmbH. In these roles, she supports colleagues, customers and teams on their journey to better quality - be it in products, in processes or in their communication. In previous roles, she was responsible for enabling teams and growing quality. Now she enables others to do that work, and works on nurturing a system in the company where everyone can flourish. Alex views the world through the curious eyes of a tester and loves learning new things. She shares her knowledge and experience in workshops, coaching sessions and as a speaker or keynote speaker at conferences.
@alex_schl
http://www.schladebeck.de/
Zeb Ford-Reitz
Zeb is a software developer and technical lead at BREDEX GmbH in Germany. He is a huge fan of open source, and was an active Eclipse committer for many years. He works closely with testers in his teams to share understanding about quality and risk. He has a knack for effective code documentation and is not fond of acronyms.
@zfordreitz

End-to-end integration plays a strong part in testability, unfortunately, when an application grows, these kind of tests become a burden: brittleness, slower feedback and overall poor return on investment to improve quality.

Contract testing brings an alternative approach for validating integration points in fast-changing distributed systems. Because contracts don’t need integration environments, they can give very fast feedback to prevent API and messaging breaking changes from being introduced early-on.

Contracts are also a catalyst for inter-team communications. They help interactions between services become a central attribute in designing solutions, as opposed to an emergency concern when they break at a late integration stage.

This workshop covers the core concepts of contracts testing and contracts can play a part in reducing the struggles of integration tests. The attendees will be working on practical examples of defining contracts between teams and services, as well as implement them using the Pact tool-chain.

High-level schedule of workshop

  • Overview contract testing concepts and Pact
  • Hands-on activity: defining contracts between teams
  • How-to & hands-on activities: using Pact to implement contract generation and validation
  • Contract testing and CI/CD
  • Looking at your own architecture and how contracts can help your testing strategy

Takeaways

After this workshop, participants should:
  • Have a good understanding of the consumer-driven contract testing pattern
  • Know when and where to use contract tests instead of integration tests
  • Be able to implement simple Pact tests for both consumers and providers, and how to automate them in a CI/CD pipeline
Pierre Vincent
I am originally from a Software Development background and the rise of DevOps drove me to become more involved in how systems actually run in the real-world, and how I could make a difference helping others care about the applications they release to production. I am currently Infrastructure & Reliability Manager at Poppulo, where I'm responsible for our continuous delivery platform and the operations of our hybrid on-prem/cloud infrastructure.
@PierreVincent
https://blog.pvincent.io
Yippee ki-yay! is an old, American cowboy expression, an expressions of extreme joy or excitement. And my goal for this workshop is to get you as excited about REST API testing as I am.
 
Testing the API instead of, or next to, the UI has many benefits:
  • Fast and easy to test business logic;
  • Fast and easy to automate, even if you feel you’re not made for coding or never coded before;
  • Faster (automated) (regression)test execution.
 
And nowadays, with the microservices approach being widely adapted, a lot of development teams don’t even have an UI to test. So, why shouldn’t you start testing the API? 
 
Content of the workshop
 
Morning program
The first half of the day we will start with the basics of a REST API like, base URL, verbs, status code, headers.. so you know what the documentation of the API we are going to test is talking about. 
And an introduction to Postman, a tool that is easy to understand but also has many advanced options if you keep using it after this workshop. Are you faster in writing code then writing proper English? No worries! It is also possible to do the exercises in RestAssured or Karate.
And then you are ready to start testing!
 
Afternoon program
First you can relax a little for the recap of the morning and some extra information about automating the test cases. But then it is your turn to get the benefits of the automation options of Postman. Making your work less repetitive and more interesting and fun!
 
So, no experience in API testing and want a quick start? API testing frightens you a little because it sounds too technical? Or hardcore UI test automater but no understanding of an API? I’m looking forward to see you in my workshop!
 
P.S. What we won’t be covering during the workshop is the topics in depth security testing and performance testing of the API.
 

Takeaways

  • You will have a clear understanding of what a REST API is and where it is used for;
  • You will be able to read and understand documentation about a REST API;
  • You can translate test techniques into test cases for API testing;
  • You have a collection of automated tests in Postman, which can be reused in the future;
  • And you can run your created and automated tests with Newman from command line, so you can integrate them in the build pipeline.
 
Lianne Klaver
¡Hola! I'm Lianne, by nature I’m positive, eager to learn and like to laugh a lot. Professionally I’m a freelancer in the world of mobile apps, API's and QA. Before I had a career in sales, selling medical nutrition and toothpaste. Quite fast after making the switch to becoming a test engineer, I found out I could combine the best of both careers: My persuasive and dicactic skills from my sales career with my knowledge from testing or advising on mobile app projects (REST API’s play a big role in mobile app development). So I became a trainer! I gave multiple courses on API and Mobile app testing. The combination of meeting people, sharing knowledge and having some good fun and laughs makes it a welcome change to my daily work.
@Lian_Klaver
https://www.linkedin.com/in/klaverlianne
Eveline Bongers-Staal
Hi! I’m Eveline, a freelance test engineer, with a focus on mobile apps and API’s. I have worked in several mobile app projects where API testing helped me to work more efficient, have a better understanding of the application and find bugs earlier in the process. Not too long ago I discovered my passion for software testing after working in sport management. To become a tester I experienced that among other things workshops and experienced colleagues helped me enormously to make great strides in a short time. This inspired me to contribute and give workshops every now and then. Want to know more? Let’s meet and learn from each other.

https://www.linkedin.com/in/evelinestaal/

Over the course of our career, we as testers have become innately proficient at mapping the approach to effectively test any application. By reverse engineering, backstepping our way from outcomes to potential scenarios. Also by strategizing the next steps by structuring and modelling the application we are working on and mapping quality characteristics, risks and user needs. So why wouldn’t we use these skills to propel us through our desired careers? In this workshop, let’s explore our careers in testing. We will identify what makes us happy and map out a way to our intended goals by seeing the potential in our everyday opportunities.

Attendees will participate in a series of exercises that identifies the unseen work that goes on within their day to day job. We will use testing tools and models to strategically walk through your desired outcomes/goals. Through breakout groups and couplings, attendees will craft testing identities (as they would like to be seen) and then receive feedback on how to effectively broadcast their successes. Through this experimental workshop, we are taking an attentive look at expectations (drawn out by your organizations) and mapping those to aspects of your work we have uncovered through our exercises. Testers will be able to go back to their organization with language and tools for how to make their unseen work invisible, and managers will go back to their organizations with approaches to better assist their direct reports in unveiling and attending to day to day requirements.

Who should attend this workshop?

The workshop is for all levels. It helps you identifying goals and finding creative ways to achieving them. It is especially great for leadership so that they can better assist in the careers of their individual contributors. This is an all around approach to career trajectory and a path to do the things you want to do. It results in more fun in your work. It helps you to coach others to happiness too.

Takeaways

In this workshop you will learn:
  • Mapping requirements for organization based success (using your career ladders to create goals)
  • Structuring conversations for career growth, doing the things you want to and make you happy and more fun at work
  • Owning 1:1’s, reviews, and interviews
Ash Coleman
Ash, a former chef, put recipes aside when she began her career in software development, falling back on her skills in engineering she acquired as a kid building computers with her brother. A progressive type, Ash has focused her efforts within technology on bringing awareness to the inclusion of women and people of colour, especially in the Context-Driven Testing and Agile communities. An avid fan of matching business needs with technological solutions, you can find her doing her best work on whichever coast is the sunniest. Having helped teams build out testing practices, formulate Agile processes and redefine culture, she now works as an Engineering Manager in Quality for Credit Karma and continues consulting based out of San Francisco.
@AshColeman30

Friday, 16th October 2020

Conference

Exploratory testing remains misunderstood and underappreciated by many in the testing and development communities. For example:

  • Many people know the name but can't say what it means (beyond standard definitions)
  • There are relatively few people who choose to make it their speciality
  • Requests for test services are usually for manual or automated test case creation/execution- even when the project will not benefit from them.
  • Many developers don't understand the value and necessity of it and therefore don't practice and improve.

This is a worrying and also interesting state of affairs. Worrying because exploratory testing is a key part of good quality strategies - and the only way to identify unknown risks. It's interesting because everything we do in software development is exploratory: we work iteratively/incrementally in agile because we gain new insights while working. It's remarkable that we don't already have a catalogue of exploratory activities within software development, and talk more about how to improve our exploration in general.

In this talk, Zeb (a developer) and Alex (a tester) will seek to change this. We will look at exploration as a human activity that has links to agility and experimenting. We'll talk about exploratory activities in the development process - including requirements gathering, coding and debugging, testing (at various layers) and even monitoring and observing. Through stories and examples, we’ll look at exploring from various angles, and give participants motivation and techniques to improve exploration (testing and other activities) within their teams.

Takeaways

  • A better understanding of what exploration is and what activities are exploratory
  • Tips for explaining exploration to others - especially those who don’t “get it” yet
  • How exploration skills will be necessary in the future and how we can prepare ourselves
Alex Schladebeck
Alex is a passionate tester whose favourite topics are quality, agility and humans. She is CEO and Head of Quality at Bredex GmbH. In these roles, she supports colleagues, customers and teams on their journey to better quality - be it in products, in processes or in their communication. In previous roles, she was responsible for enabling teams and growing quality. Now she enables others to do that work, and works on nurturing a system in the company where everyone can flourish. Alex views the world through the curious eyes of a tester and loves learning new things. She shares her knowledge and experience in workshops, coaching sessions and as a speaker or keynote speaker at conferences.
@alex_schl
http://www.schladebeck.de/
Zeb Ford-Reitz
Zeb is a software developer and technical lead at BREDEX GmbH in Germany. He is a huge fan of open source, and was an active Eclipse committer for many years. He works closely with testers in his teams to share understanding about quality and risk. He has a knack for effective code documentation and is not fond of acronyms.
@zfordreitz
Blocked because the API you depend on doesn’t exist yet or isn't completely ready? Facing trouble to test certain scenarios due to a lack of control over third-party APIs?
Struggling to test failure cases like invalid responses or 5XX errors? Frustrated by flaky tests due to slow API responses? 
 
These are some common problems we regularly encounter. We cannot rely on slow APIs that provide a very narrow range of responses. So how can we test effectively in such situations? Is there any feasible solution available? Fortunately, there is: API mocking. 
 
If you are less familiar with mocks and want to gain more insight, join this talk.
In this session, I will explain how to mock APIs using Wiremock. Using a real-life example application, we’ll explore how to handle complex scenarios and form an effective testing strategy. Join this session to gain insights on how, when, and—most importantly—why we should mock APIs. Together we will discover how development and testing can benefit from mocks.  Remember, “If API testing is the king, mocking APIs is the queen!”
 
Please note: at the end of this talk, all attendees will have full access to the example application used during the talk for trying out mocking for themselves :) 
 

Takeaways

 
  • The benefits of mocking APIs for development and testing
  • How to mock APIs
  • Which scenarios can be covered better with mocks
  • When to mock and when not to mock
  • Which different types of testing benefit from mocks
Shivani Gaba
Shivani is a passionate QA Engineer who believes that knowledge sharing boost up all engaged parties and increases their confidence. It was summer of 2013 when Shivani and “testing” met each other first time and are best friends since then. Holding rich experience in testing domain, she currently works as Senior QA Engineer with XING (the largest business network in German speaking countries). With hands-on in all layers of software testing ranging from UI(frontend), API and backend, functional, non-functional , mobile testing - API remains her all-time favourite. As a certified scrum master, working in agile manner is always her approach. She believes in idea of spreading her findings about any “new fancy stuff” she learns. She has worked with multiple international teams and brings forward idea of whole team contributing for quality. She's always up for conversation over twitter, email, linkedin, Xing or beer table :) Linkedin Xing
@shivani_gaba_
Biases are systematic thinking errors that we tend to make. It is inherent to our jobs as testers that we have to collaborate with very diverse groups of people. Some of them may be biased against you - we all know the stereotype of the tester as the nosy intruder who comes to point out everyone's mistakes. But have you ever turned the mirror towards yourself and considered that YOU may be biased as well? Your testing processes may be affected by biases. And even technology itself sometimes inherits their creators' biases.
 
After having worked in both a big multinational company and its opposite - a tiny start-up in various countries, I realized that the most rewarding progress I've made as a tester was recognizing that I have my own biases, and then learning how to manage them. As a result, I have been able to collaborate with my co-workers more effectively, setting aside my own predispositions and allowing myself to take a step back and look at things more objectively, thus ensuring the quality of our products. I realized that all of our work is affected by biases - be it directly or indirectly. This has led me to a lot of great books, conversations, and discoveries about biases.
 
In this story-fuelled session, I will share practical tips on how to recognize your biases, deal with all kinds of professionals and make sure that your testing and the technology you are testing is not biased. 

Takeaways

  • Question everything you (and others) do and this will help to recognize biases.
  • Especially nowadays we have to be responsible not to let biases creep into our tech work (like AI).
  • Everyone is biased, but learning how to manage your biases can help you succeed as a tester.
Lina Zubyte
Lina Zubyte is a passionate Quality Enthusiast who loves to ask questions, test, collaborate with diverse departments and investigate issues. Lina has worked in companies of different sizes (large multi-national companies and startups), moved between countries for work and have had to adapt quickly to get out of comfort zone. Favorite parts of being a quality professional for Lina are: diving deep into complex issues which may even reveal design or algorithm flaws, using monitoring tools and analytics data to understand the impact of found issues and collaborating with the team to build a high quality product.
@buggylina
https://letmetrysoftwaretesting.wordpress.com
As the sole tester on a team that's moving towards continuous delivery and building a DevOps culture, how can your team release frequently, and with confidence?
 
Within my Agile team, the testing activity had become the bottleneck. The testing ‘To Do’ cards on the team’s newly implemented Kanban board were piling up. As the sole test specialist within my team I felt as if I was preventing us from being able to deploy code to our live environment. Frustrated, we got together as a team to discuss how we could fix this problem. 
 
By using our 3Cs board, the team reached a solution. We decided to share my testing knowledge within the team. My role as the test specialist evolved into a coaching role, which made me feel both excited and nervous. We found ways to test throughout the development process. We learned to design test plans and discuss technical challenges together. We collaborated on the testing effort. 
 
In this talk I’m going to share how my team removed the testing bottleneck by using Lean techniques, built in quality to our product and started to become true cross-functional team members by increasing collaboration. I'll also discuss the challenges we faced, such as making this new approach a habit, and how we overcame them. 

If you face similar challenges with your own team, you can try similar experiments.

Takeaways

  • How sharing your testing knowledge can lead to quality being built into your product, thus reducing waste.
  • How to encourage non test specialists to get involved in the testing effort.
  • How collaborating on testing activities built closer relationships across the team.
Ali Hill
Ali began his software testing career testing video games before moving into an Agile testing role. He now works as a QA and Continuous Delivery Consultant at ECS Digital. He has a passion for learning. Recently Ali has been interested in learning how software testing can flourish in the world of DevOps and Continuous Delivery and has been sharing his testing knowledge within his cross-functional team. Ali can be found talking about testing on Twitter, blogging or at the Edinburgh Ministry of Testing Meetup.
@ali_hill91
https://edinburghtester.wordpress.com

The best interface is told to be the one that is seamless to interact with, and a new wave of interfaces based on text, voice or gestures is emerging based on this motto.

At the same time, these interfaces make use of advanced algorithms, ranging from pattern and expression matching engines to natural language processing, sometimes backed by AI algorithms and wrapped around as API services.

Given these starting conditions, testing interfaces based on voice, natural language, gestures or other camera based inputs can raise challenges, from both the novelty as well as from the complexity point of view.

During this session the most important aspects of testing such interfaces will be covered sharing real life experience on putting together the test strategy, tooling, hinting what to do and what to look for, highlighting the importance of modeling intents and transitions in the state-machine model of the tested system.

Takeaways

  • What is a non-conventional / next generation interface?
  • How can I build my testing approach for such an interface?
  • What from my current toolset can I use for this new context?
  • What are aspects to consider when encountering AI in the tester systems?
Lucian Adrian Stroie
The important things are mindsets! They will change you!” is Lucian’s motto. He is currently working at R/GA where he has the opportunity to work with new technologies, brilliant design people and crafty developers, this blend resulting in award-winning & innovative user experiences. His journey into testing started in 2005, and since then he took an interest in many things related to testing & agile His testing experience covers a wide range, from networking & embedded to mobile apps, going through security and desktop applications. His recent interest is in exploring the interaction between users, computer interfaces, and data-driven methods (e.g. AI, ML). You can connect further on Twitter (@lucianadrian) or through his blog (lucianadrians.wordpress.com).
@lucianadrian
https://lucianadrians.wordpress.com/

This is the story of how we helped a client save their security budget. By working with this massive enterprise to embed practical and tangible security solutions across their teams, we drastically reduced their dependency on external forces, reduced vulnerabilities in the pipeline and helped them understand where to target security more efficiently.

In this talk, we'll discuss how security can be integrated into all parts of an organisations culture, with a focus on software testing, by learning how to think like an attacker. How by empowering teams with a hackers mindset we can take the mystery out of security.

Takeaways

  • Understanding how to see through the eyes of an attacker to become more secure
  • How you can champion security across your organisation
  • Why testers are uniquely equipped to carry the torch for security in the pipeline
Saskia Coplans

Saskia is Security Consultant and Director at Digital Interruption. She a registered Data Protection Officer (DPO) and a privacy specialist with over ten years of experience in information security and governance. Along with standards and policy development, she has developed risk-based defensive security strategies across Europe and Central Asia for Governments, NGO’s, Regulators and the Private Sector.

Saskia is a founder of the InfoSec Hoppers, a group of women confronting the gender gap in InfoSec by working together to highlight diversity issues in the industry and make conferences, events and meetups more accessible. She sits on the board or OWASP Manchester and Manchester Grey Hats.

@ms__chief
https://www.digitalinterruption.com/di-blog

In January of 2017 the "Service Team Testautomation" was founded at DUO (part of the Netherlands Ministry of Education). The aim: getting our roughly 40 DevOps teams to properly use automated tests. In the initial mission statement, the main focus was on finding technical solutions. The main line of thinking was: if you build the right stack, the automated tests will come.

As some of you may have guessed: it's never that easy.

Let's look at a few of the problems we ran into:

  • Is ‘built by testers’ actually the right approach?
  • Does 'the right stack' even exist?
  • How do we get people to use the stack we've built, the right way?
  • Can we balance 'can we automate this' and 'should we automate this'?

In the end, we’ve overcome all these issues and managed to turn this experiment into a success, with a major impact on the way testing is done in our DevOps teams.

We’ll discuss the answers we found and the lessons we've learned along the way. Whether you're looking to support others in using automation or looking to automate some tests yourself, hopefully, this talk will save you the trouble of making some of the mistakes we did.

Takeaways

  • How to find/build the right (or good enough) stack
  • Don't stop testing when you start automating
  • Teach what you preach
  • Build support for automation (managers matter)
Jurian Jilderda

Jurian is a test automation engineer at DUO in Groningen, the Netherlands. He's been testing for over 10 years now. Having started out as a manual tester who liked to automate tests, he's now become a test automator: building frameworks & supporting and teaching fellow testers - together with the rest of the Test Automation Service Team.

He lives in Assen, home of the famous Dutch TT race, with his wife and three kids. When he's not at work he can be found coaching his son's football team and supporting his local church. If there's nothing to be done on those either he likes to exercise, run, Netflix, or game his free time away.

Jarsto van Santen

Jarsto has been playing with code for a quarter of a century now, having started at 11 years old. Despite studying law he eventually saw sense and turned his hobby into a career. He now works as a test automation engineer at DUO, as part of the Test Automation Service Team. In practice, this means developing internal testing tools and supporting colleagues when they have trouble getting automated tests to work. As well as a critical look at what should or shouldn't be automated.

In his free time Jarsto is mildly obsessed with world history, science fiction, and fantasy, and all sorts of technology he doesn't get to play around with at work (yet). Somehow he never quite has the time to watch as many movies/series, read as many books, or play as many games as he thinks he should.

@TestTactician
Leading teams is no easy task, you have to deal with people that can have very different personalities, collaborate with them on a daily basis, coordinate activities, be their representative in meetings with stakeholders, and are accountable for the results not only from your work but also from the work your team does.
 
While this is not an impossible task, it can feel exactly like that if you’re an introvert like me, however if you look closely at your own life, you might end up discovering that you can truly be a leader despite feeling you can’t because of your introversion.
 
In this session I’ll share my journey to be able to lead a team, the things I had to go through to get to that point, the lessons I learned, and how reflecting on my own steps was key in helping me achieve this goal.

Takeaways

  • A not so common insight from an introvert about leadership roles.
  • Help attendees identify how they’ve probably been leaders without really noticing.
  • Some tips on how to make your way into leadership roles despite being an introvert.
 
Pedro Gonzalez
I have 11+ years of hands on experience in quality engineering roles. I’ve worked mostly on consulting roles during my career, but also have experience with product development environments and have had a chance to lead teams multiple times in my career.
@pgonzalezr
Nowadays we build applications via the microservice principles to make our applications easier to maintain, deploy, test and change. These microservices can easily be deployed on cloud platforms. Within the cloud we select the best architecture components and all our problems disappear. We automate every step and are able to recover and re-deploy within minutes. Sounds good! Never have performance, resilience or any infrastructure issues ever again. 
 
However, in the cloud more responsibilities end up with the DevOps teams. They become responsible for the infrastructure, have more settings to tune and variables you can control. This also impacts testing.  
 
During this talk we will explore this new world, the impact on testing and how resilience testing fits in. Based on the experience and failures I had with teams moving to the cloud, I will tell you about the pitfalls and how to avoid them. I will also show you how to start with resilience testing your own microservice/cloud infrastructure. 

Takeaways

  • Resilience testing, why it is important and how to start with it! 
  • Theory on Cloud, Microservices 
  • How to do your very own Resilience Test
  • The importance of Monitoring and combination with testers
  • Tools & Best practices to start resilience testing.
  • Geoffrey van der Tas
    Geoffrey works as though leader for Ordina Auto|Q. Geoffrey has focus on more the agile side of testing and exploratory side of testing. Together Geoffrey and Mark worked on this workshop to combine both their skill sets.
    @gavdtas
    https://Geoffreyvdtas.com
    With new development techniques, a couple of things have changed in the testing world. Most of the time the so-called “QA department” went dead when seeking more efficiency and trying to cut costs. A new breed of tester was born: The embedded testers. We want to have quicker feedback on the product, testers have to work hand to hand with the developers, test immediately when code is produced.

    Before the AGILE transformation, testers were like AWACS, planes fitted with a big radar, capable of seeing far away, at the verge of the horizon, relaying crucial tactical information to command center. QA was mandated to perform reviews, inspections and testing on the whole project. 

    When we are testing, regardless of techniques or tools, we are learning and observing what is going on with the product. We report defects based on requirements and good engineering judgment. Writing defects in a bug tracking is one thing, but in fact, testers are located at an ideal spot watching the project taking off. 

    The software industry does not pay as much attention to waste as much as other industries that are deep into lean manufacturing. In aviation, all issues are scrutinized and taken very seriously even if they are (just) incidents.

    What can we derive from issues or bugs (we call them “snags“ in aviation) so that the same problem never will occur again? Why do we have to report the same issues about a login screen over and over? Fixing an issue is important for the product but understanding how that issue made its way inside the product is a great value for the company. Not only we can fix the issue but we can improve processes and more. Not only we become better at building the product but we get better at building any product. 

    In this talk, I will expose my experience as a test strategy lead in the flight simulation world and of course savings that have been achieved by bringing into software lean manufacturing concepts like Kaizen. Flight simulation is a mix of software and serious hardware where we have to deal with a 643 pages long test requirement document from aviation authorities. We will go over the land of dashboards, retrospectives, requirements and of course testing and all that with concrete problems I have bumped in many times. 

    Takeaways

    • Stop fixing issues. Understand why they are there to improve your business.
    • Recognize patterns: A key indicator that some issues are likely to occur and spread.
    • Testing without coding: Testing starts when the proposal is built.
    Bauduin Alexandre
    Alexandre Bauduin is a 53 year old world traveler. He worked in consulting firms gaining experience in several fields (medical, manufacturing, aerospace, pay TV, data warehouse—to name a few) in different countries (Switzerland, France, Spain, Canada, etc.) His career started in the space industry where he discovered his passion for aerospace, working on both military and civilian projects. He was sometimes steered away from aerospace but his passion pushed him to become an airline pilot, as a way to really understand how those instruments he programmed and integrated were operating in a cockpit. One of his last challenges was to organize flight simulator testing into a lean manufacturing environment. He works with milling machines, draftsmanship, accounting and finance, software development, electronic design and industrial robots, and it is always fun for him to use an oscilloscope, an ARINC bus analyzer, and step into assembly language or stall a Boeing 777!
    @B777Alex
    https://www.linkedin.com/in/alexandre-bauduin/