About Gerard van Engelen

As a DevOps test specialist, I’m an experienced contributor to the quality of the products that I work on. I solve complex issues by comparing them with simpler everyday stuff. This helps me and my team(s) provide value by building stuff the right way and with the right functionality.

I’m a T-shaped engineer with experience in setting up frontend- and backend automation, setting up monitoring as code, creating automated and opinionated pipelines, and IaC. As a true DevOps engineer, I can contribute to multiple aspects of the software delivery process.

My ambition is to automate as much as valuable, but the proof of the pudding is in eating it. So I always challenge myself and my team to also do manual testing for new features.

Speech title

Contract testing, an automated solution to inter-team collaboration.

Talk description

Do you work on services that depends on the services of other teams, or is your service being used by multiple other teams? Then you probably know the struggle of figuring out which team has caused issues in your application, or figuring out who you need to inform about pending (breaking) changes. And you probably know the struggle of testing it all end-to-end, tests are flaky, tests are slow, tests are hard to maintain, or all of the above.

If you feel this pain then you might be interested in contract testing. Contract testing is a form of API testing which allows you to prove end-2-end integration without having deployed environments and with easy to maintain tests. It shortens the feedback loop, and provides direct insights in which application can work together and which can’t.

During this talk I will help you discover:

  • What is contract testing
  • How does contract testing fit in a generic test automation architecture
  • A practical example on contract testing using pact
  • How to convince your team/ organisation to start doing contract testing

So join this talk and see how contract testing can help you to automate your inter team collaboration

Take aways:

  1. Don’t use e-2-e tests to check if applications can work together
  2. Contract testing fits in a generic test automation architecture
  3. Contract testing will help you automate inter team communication