TestBash Netherlands 2020

Ministry of Testing has partnered with Huib Schoots again to make sure that from Monday 25th to Friday 29th May, there are plenty of learning opportunities for everyone.

We’re opening the week with two 3-day training courses: Automation in Testing with Richard Bradshaw and Mark Winteringham and Professional Agile Testing with Ya'ara Egger and Klaartje van Zwol. We follow that with 6 full-day workshops and 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. Workshops and training will take place in Seats2Meet. TestBash will be in Jaarbeurs.

Pro Ministry of Testing members get €50 off the workshops and conference day for TestBash Netherlands! 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 host more.

Quick Look

Speakers

Jim Holmes
Jim Holmes
Consultant
Alexandra Schladebeck
Alexandra Schladebeck
Head of Software Quality and Test Consulting
Zeb Ford-Reitz
Zeb Ford-Reitz
Technical Lead
Pierre Vincent
Pierre Vincent
Infrastructure & Reliability Manager
Geoffrey van der Tas
Geoffrey van der Tas
Quality/Team Performance Coach
Mark Abrahams
Mark Abrahams
ICT Consultant
Mark Winteringham
Mark Winteringham
DojoBoss
Richard Bradshaw
Richard Bradshaw
BossBoss
Lianne Klaver
Lianne Klaver
Test Engineer
Eveline Bongers-Staal
Eveline Bongers-Staal
Test Engineer
Klaartje van Zwoll
Klaartje van Zwoll
Agile Tester
Ya'ara Egger
Ya'ara Egger
Agile Tester
Ash Coleman
Ash Coleman
Engineering Manager in Quality
Pedro Gonzalez
Pedro Gonzalez
Technical leader
Lina Zubyte
Lina Zubyte
QA Consultant
Saskia Coplans
Saskia Coplans
Founder and Security Consultant
Shivani Gaba
Shivani Gaba
Senior QA
Alexandre Bauduin
Alexandre Bauduin
Senior tester, Airline pilot, inventor...Make it work!
Lucian Adrian Stroie
Lucian Adrian Stroie
Technology Lead
Ali Hill
Ali Hill
QA and Continuous Delivery Consultant
Jarsto van Santen
Jarsto van Santen
Test Automation Engineer
Jurian Jilderda
Jurian Jilderda
Test Automation Engineer

Schedule

Monday, 25th May 2020

Training

A three-day intensive, hands-on and interactive training to help you develop skills and knowledge to survive as a tester in an agile context and grow your career in the testing & quality field. It will sharpen or change your paradigm of testing and quality in an agile context.

Why You Should Take This Course

Almost every company nowadays works agile or is considering doing it. What does an agile way of working or being agile really mean? In essence, it is creating value in close collaboration with the customer and respond to a changing market and constantly changing customer wishes. Scrum is often the first step to do this. Benefits include quick feedback, shorter time-to-market, lower costs and focused delivery of working and tested products. Who doesn't want that?

Creating quality products is of course easily said, but how are you going to do that? It presents teams with major challenges. We do not know everything in advance, requirements change and during development we learn new things. Building software is research and development: discovering what works best in small steps, together with the customer.

In the Professional Agile Tester training you learn to act successfully within an agile team. In this three-day training, you learn many important principles about quality and testing in an agile context to help you and your team on a journey to better software and happier people.

This training is designed to help you develop skills around the 4 pillars of testing and quality in an agile context: people skills, agile skills, testing skills and technology skills (PATT).

What You’ll Learn on This Course

Day One

To kick-start the course, we will explore what agile is, what it means to be agile and what an agile way of working means. We will also dive into the challenges teams face which lead to quality-related issues.

In the second half of day one, we will introduce a product which we will work with during the whole training. On day one we will learn about the product by play, exploration and making several models to help us think about risks and the strategy to test the product.

By the end of day one, you will be able to:

  • Describe the concepts of agile and how they affect software development
  • Explain how testing and quality fit in an agile way of working (using Scrum)
  • Explain what agile means for the skills of a tester
  • Talk about testing in an agile context and explain why this is a whole team approach
  • Describe what models are
  • Explain how models benefit and enact thinking and talking about testing and quality
  • Create different types of models using the heuristic test strategy model
  • Create models with mind maps
  • Describe what risks are
  • Apply different techniques for discovering risks like horror plots, the headline game & risk storming
  • Hypothesise and construct different types of risks that might affect a product or project
  • Construct testing activities from risks
  • Explain what a test strategy is
  • Talk about the parts of a test strategy
  • Build and expand a test strategy fast
  • Ask powerful questions to learn for example about the product, the specifications and the context
  • Identify situations where ambiguity in communication and documentation is slowing us down

Day Two

In the first part of day two, we’ll do actual testing on the product based on the risk analysis and test strategy made in day one. While testing we will further expand our strategy and risk models. We will learn how to construct and expand testing activities and learn how to document your testing as lean as possible while still being useful.

In the second part, we’ll move onto collaboration and communication while working in an agile team. Here we will explore refinement and sprint planning to learn how a tester can add maximum value in a variety of situations.

By the end of day two, you will be able to:

  • Explain what session-based testing is
  • Create charters for sessions to learn about the product and test it
  • Document what you learn using a variety of approaches
  • Explain why note-taking is important
  • Take powerful and concise notes
  • Explain the basics of critical thinking
  • Explain why critical thinking is important in software development
  • Identify claims, conclusions, and reasoning in your own thinking
  • Identify cognitive biases, false reasons and logical fallacies
  • Describe different software development activities and zoom in on communication and collaboration from a quality and testing perspective
  • Discuss some of the challenges in communication and how to overcome them
  • Explain the role of testing and quality in Scrum ceremonies
  • Review user stories
  • Identify challenges in a team using user stories
  • Explain the benefits of splitting user stories into smaller parts from a quality perspective

Day Three

In the first part of day three, we’ll do some more testing on the product in sessions. We will learn how to explain the status of the product, what we did and the remaining risks using the testing story.

In the second part, we’ll dive deeper into collaboration and communication in an agile team using retrospectives and Sprint reviews. Finally, we will discuss how technology can help accelerate teams.

By the end of day three, you will be able to:

  • Explain how to report your testing using a variety of approaches in and outside of scrum ceremonies
  • Give your stakeholders insight into the testing and quality of the product
  • Use the basics of storytelling in your daily work
  • Explain what feedback is
  • Provide feedback in an effective way using different approaches
  • Explain the purpose and benefits of a retrospective
  • Identify anti-patterns in testing and Scrum
  • Facilitate basic retrospectives to help accelerate the team by removing waste and reflect on the way of working
  • Explain how tooling and technology can accelerate teams
  • Guide your team to talk about testability and appropriate use of automation, tooling, and technology
  • Talk to your stakeholders about the benefits and traps of using automation
  • Explain what quality coaching is and how teams benefit from it
  • Explain how professional agile testers add value in a variety of ways depending on the context you are in

Is This Course Right for Me?

Professional Agile Tester has been designed for anyone looking to improve their knowledge, people skills, agile skills, testing skills, and technology skills by taking a hands-on and interactive training course. Whether you are a developer, a scrum master, a product owner, a manager responsible for teams or products or a tester, this training will help you and your team develop better software by teaching you about testing and quality. Also, if you are looking for a career change as an aspiring tester, or someone looking to fill in gaps in your knowledge and skills, this course is for you.

Do I need to know or have done any agile or testing beforehand?

Not necessarily, although it will make it easier. If you have knowledge and experience, this training will provide you a variety of approaches and techniques to think and talk about testing and quality and improve your hands-on (people, agile, testing and technology) skills.

If you don’t, this training will give you insight into the mindset and skillset of professionals in an agile testing context. We have a collection of helpful online resources to prepare you to learn about the basic concepts so you can hit the ground running.

Work experience

Having some work experience in any professional context or project will help you understand the communication and collaboration issues we discuss in the training easier.

Agile

The Professional Scrum Master course is a good start, but not necessary. No experience at all with Scrum or agile? Read the Scrum Guide carefully before going to this training.

Testing

Basic knowledge of and/or experience with testing or developing software is useful. If you do not have any experience in this field, collaborating with more experienced people during the training will help you learn about testing and quality in an agile context.

What Do I Need To Bring?

Enthusiasm to learn and a windows laptop. We invite you to bring your real-life people, agile, testing or technology challenges to the training.

Klaartje van Zwoll
In 2015, Klaartje chose to switch from teaching at a primary school to software development. She is a tester and agile coach who values strong team relationships and collaboration. She has an eye for people and their interests. Over the years she built experience in different sectors including education, government and public transport. Klaartje won the Dutch Software Testing Championship in 2017, and premiered as a speaker at the Agile Testing Days in 2019.
Ya'ara Egger
Ya'ara is an agile tester, a trainer and an enabler of awesomeness. As a toddler she learned how hand-cranked music boxes work by disassembling one. She proudly presented her findings to her surprised mother, including a detailed report of the steps to reproduce. It was the first of countless disassembled appliances and devices. When Ya'ara joined the Israeli Air Force as part of her mandatory service, she was assigned to turn headquarters flight commands into flight instruction manuals and train pilots about flight safety. She studied neurobiology to learn what makes people happy. When realising Physics was not it, she took a more direct approach and went on to study pastry-making, because who doesn’t love cakes?! Ya'ara accidentally became a tester in 2013 while working for a food delivery web company, and finally found use for the skills she acquired: understand how things work by breaking them down, making it clear how to find and avoid faults and always aspire to make people happier.

Training

What Do We Mean By ‘Automation in Testing’?

Automation in Testing is a new namespace designed by Richard Bradshaw and Mark Winteringham. The use of automation within testing is changing, and in our opinion, existing terminology such as Test Automation is tarnished and no longer fit for purpose. So instead of having lengthy discussions about what Test Automation is, we’ve created our own namespace which provides a holistic experienced view on how you can and should be utilising automation in your testing.

Why You Should Take This Course

Automation is everywhere, it’s popularity and uptake has rocketed in recent years and it’s showing little sign of slowing down. So in order to remain relevant, you need to know how to code, right? No. While knowing how to code is a great tool in your toolbelt, there is far more to automation than writing code.

Automation doesn’t tell you:

  • what tests you should create
  • what data your tests require
  • what layer in your application you should write them at
  • what language or framework to use
  • if your testability is good enough
  • if it’s helping you solve your testing problems

It’s down to you to answer those questions and make those decisions. Answering those questions is significantly harder than writing the code. Yet our industry is pushing people straight into code and bypassing the theory. We hope to address that with this course by focusing on the theory that will give you a foundation of knowledge to master automation.

This is an intensive three-day course where we are going to use our sample product and go on an automation journey. This product already has some automated tests, it already has some tools designed to help test it. Throughout the three days we are going explore the tests, why those tests exist, our decision behind the tools we chose to implement them in, why that design and why those assertions. Then there are tools, we'll show you how to expand your thinking and strategy beyond automated tests to identify tools that can support other testing activities. As a group, we will then add more automation to the project exploring the why, where, when, who, what and how of each piece we add.

What You Will Learn On This Course

Online
To maximise our face to face time, we’ve created some online content to set the foundation for the class, allowing us to hit the ground running with some example scenarios.

After completing the online courses attendees will be able to:

  • 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

Day One
The first half of day one is all about the current state of automation, why AiT is important and discussing all the skills required to succeed with automation in the context of testing.

The second half of the day will be spent exploring our test product along with all its automation and openly discussing our choices. Reversing the decisions we’ve made to understand why we implemented those tests and built those tools.

By the end of day one, attendees will be able to:

  • Survey and dissect the current state of automation usage in the industry
  • Compare their companies usage of automation to other attendees
  • Describe the principles of Automation in Testing
  • Describe the difference between checking and testing
  • Recognize and elaborate on all the skills required to succeed with automation
  • Model the ideal automation specialist
  • Dissect existing automated checks to determine their purpose and intentions
  • Show the value of automated checking

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.

By the end of day two, attendees will be able to:

  • Differentiate between human testing and an automated check, and teach it to others
  • Describe the anatomy of an automated check
  • Be able to model an application to determine the best interface to create an automated check at
  • How to discover new libraries and frameworks to assists us with our automated checking
  • Implement automated checks at the API, JavaScript, UI and Visual interface
  • Discover opportunities to design automation to assist testing
  • An appreciation that techniques and tools like CI, virtualisation, stubbing, data management, state management, bash scripts and more are within reach of all testers
  • Propose potential tools for their current testing contexts

Day Three
We’ll start day three by concluding our exploration of toolsmithing. Creating some new tools for the test app and discussing the potential for tools in the attendee's companies. The middle part of day three will be spent talking about how to talk about automation.

It’s commonly said that testers aren’t very good at talking about testing, well the same is true about automation. We need to change this.

By the end of day three, attendees will be able to:

  • Justify the need for tooling beyond automated checks, and convince others
  • Design and implement some custom tools
  • Debate the use of automation in modern testing
  • Devise and coherently explain an AIT strategy

What You Will Need To Bring

Please bring a laptop, OS X, Linux or Windows with all the prerequisites installed that will be sent to you.

Is This Course For You?

Are you currently working in automation?
If yes, 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 no, 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 web space, 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 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.

Mark Winteringham

I am a tester, coach, mentor, teacher and international speaker, presenting workshops and talks on technical testing techniques. I’ve worked on award winning projects across a wide variety of technology sectors ranging from broadcast, digital, financial and public sector working with various Web, mobile and desktop technologies.

I’m an expert in technical testing and test automation and a passionate advocate of risk-based automation and automation in testing practices which I regularly blog about at mwtestconsultancy.co.uk and the co-founder of the Software Testing Clinic. in London, a regular workshop for new and junior testers to receive free mentoring and lessons in software testing. I also have a keen interest in various technologies, developing new apps and Internet of thing devices regularly. You can get in touch with me on twitter: @2bittester


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.

Thursday, 28th May 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
Jim is the owner/principal of Guidepost Systems which lets him engage directly with struggling organizations. He has been in various corners of the IT world since joining the US Air Force in 1982. He’s spent time in LAN/WAN and server management roles in addition to many years helping teams and customers deliver great systems. Jim has worked with organizations ranging from start ups to Fortune 10 companies to improve their delivery processes and ship better value to their customers. When not at work you might find Jim in the kitchen with a glass of wine, playing Xbox, hiking with his family, or banished to the garage while trying to practice his guitar.
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
 
Alexandra Schladebeck

Alex fell into IT and testing in 2005 and has never looked back. She is now Head of Software Quality and Test Consulting at BREDEX GmbH and spends her time working with test consultants, developers and customers to help them towards great quality.

You’ll usually find Alex talking about quality and how it affects the whole development process. She’s also a frequent speaker at conferences where she likes to share her project experiences and learn from other practitioners.


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.

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.
Nowadays we build applications via the microservice principles to make our applications easier to maintain, deploy, test and change. Multiple microservices together form one application. These microservices can easily be deployed on cloud platforms. With this, we as a DevOps team, get more control of our infrastructure, but also a way of making more mistakes.
 
During this workshop we will show you the importants of doing Performance Tests and the added benefits of adding resilience tests. Because what is the impact of a redeployment of your application? The impact of a switch over in availability zones? And how is your application dealing with all this?
 
We are combining the skill of creating your own performance test and creating your own Resilience test to start testing your Cloud microservice application. To create a resilient service for your customer. A resilient service: is a stable & reliable service, has high availability, and does not compromise the integrity of the service or the consistency of the data.
 
During this workshop we will show you how to do that and tell you more about:
 
  • Basics in Microservices &; Cloud platforms;
  • What is Performance Testing
  • Setting up your own Performance Test
  • What is Resilience;
  • Setting up your own Resilience Test;
  • How to automate Resilience Testing;

Takeaways

Main statement: Resilience testing, why it is important and how to start with it! 
Key learning 1:  Theory on Cloud, Microservices and the new things we need to test; 
Key learning 2:  Performance Testing, from theory to creating your own tests with Gatling; 
Key learning 3: What Resilience Testing is and how to approach it; 
Key learning 4:  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.
Mark Abrahams
Mark works with Geoffrey as a thought leader for Ordina Auto|Q. Mark has a focus on new technical innovations and test automation.
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.
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.

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. 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 map out a way to our intended goals by seeing the potential in our everyday opportunities.

Takeaways

In this workshop you will learn:

  1. Mapping requirements for organization based success (using your career ladders to create goals)
  2. Structuring conversations for career growth
  3. 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.

Friday, 29th May 2020

Conference

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.
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

Main takeaway:  Resilience testing, why it is important and how to start with it! 
Key learning 1:  Theory on Cloud, Microservices; 
Key learning 2:  How to do your very own Resilience Test; 
Key learning 3: The importants of Monitoring and combination with testers; 
Key learning 4:  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.
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.

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.


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
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.
Alexandre Bauduin
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!

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).
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 involved in learning how software testing can flourish in the world of DevOps and Continuous Delivery. Ali can be found talking about testing on Twitter or at the Edinburgh Ministry of Testing Meetup.

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)
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.


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.


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
Alexandra Schladebeck

Alex fell into IT and testing in 2005 and has never looked back. She is now Head of Software Quality and Test Consulting at BREDEX GmbH and spends her time working with test consultants, developers and customers to help them towards great quality.

You’ll usually find Alex talking about quality and how it affects the whole development process. She’s also a frequent speaker at conferences where she likes to share her project experiences and learn from other practitioners.


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.