Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
Benefits of Contract Testing with Bas Dijkstra
228 Plays3 years ago
Conversation with Bas about the benefits of contract testing. In this episode we talk about who is responsible for testing, removing the reliance on end-to-end tests, where to start with learning contract testing and much more. Find out more about Inspired Testing academy, the 6 part blog series introducing a use case for consumer-driven contract testing. Also checkout more of Bas' content on his blog on test automation or follow him on LinkedIn.
Hosted on Acast. See acast.com/privacy for more information.
Recommended
Transcript
Introduction to Contract Testing
00:00:00
Speaker
Hello and welcome back to the podcast. In this episode I have a conversation with Bass Dijkstra about the benefits of contract testing. In this episode we talk about who is resourceful for testing, removing the reliance on end-to-end tests and where to start with learning contract testing. And also we touch on other topics like bidirectional contracts which we previously spoke about with USAS. So I hope you enjoy the episode. Hello Bass.
00:00:27
Speaker
Nice to meet you and thanks for coming on the podcast. Hi, Lewis. Thank you so much for having me. I'm looking forward to a chat. Yeah, so I've followed you for a long time on social media and stuff like that. What was that you? Taking you a bit of a break from social media right now.
00:00:45
Speaker
I'm trying to not always succeeding, but I'm trying to dial it down a little. Fair enough. Fair enough.
Meet Bass Dijkstra
00:00:55
Speaker
This year you started a new role. Is that right at Inspired Academy? Yeah, it was actually September of last year. So September 2021, where I joined Inspired Testing as their director of Academy.
00:01:08
Speaker
Amazing, so what was your journey to becoming the director there and what does your role now involve? So before I started here, I've pretty much always been an engineer and consultant in the software testing and more specifically in the automation space. So I've done the engineering, the consulting,
00:01:36
Speaker
part for about fifteen years something like that so i started in two thousand six so what sort of kind of fifteen years yeah started out with the big consultancy that move to a smaller consultancy.
Career Transition Journey
00:01:52
Speaker
And then I started on my own as a freelancer. And over the last couple of years, I slowly branched out from just being full-time consultants to also doing training, to doing some public speaking. So blogging, which I've been doing for five, six years now. So yeah, basically diversifying whatever it is that I do, getting more involved in the community, sharing knowledge with it, which is really, really fun to do.
00:02:22
Speaker
And so, especially the training part of my career has grown quite significantly over the last couple of years. And that's probably one of the reasons why. So I've been in touch with Inspire Testing for about four years already. So I've been chatting to them for a while, seeing them grow. And they approached me somewhere in June of last year.
00:02:50
Speaker
to say, well, we are going to invest in our Academy and we're looking for someone to basically run with that. Awesome. Yeah. And so yeah, that's, that's how I ended up at inspired testing at the inspired Academy.
Training Audiences and Processes
00:03:05
Speaker
So what kind of people come through the Academy? And what's what's basically have four audiences?
00:03:14
Speaker
So it is our own staff. So Inspired Testing is a software testing services provider based in South Africa. We are just shy of 300 people now. Nice. So that's one audience making sure that our own staff properly trained and gets the training opportunities that they're looking for. We provide public courses. So individuals who go to our website can sign up for those courses.
00:03:43
Speaker
We do quite a few B2B engagements, so when existing or new clients, companies, teams come to us and say, well, we have a team who we want to upskill in something related to testing or automation. That's what we do. So that's the third one. And the fourth one is,
00:04:04
Speaker
In February of this year, we started a finished intake of interns. And they are going there now just at the time of recording this almost two months.
00:04:19
Speaker
on the way in a one-year traineeship, which will grow them into junior automation engineers really. Awesome. Sounds great. Yeah, it is. It's been a lot of fun, a lot of fun, a lot of stuff. Again, I've always been engineer or consultant. I've never been
00:04:43
Speaker
head of anything or director of anything. So there's a lot that I'm figuring out on the fly. Yeah, yeah, the support's great. So and they they they knew that when they brought me in. So yeah, they that's the way isn't it? Yeah, get the job and then work out how to do it. Yep. Yeah, that's that's the story of the last six ever months. Absolutely.
00:05:09
Speaker
Awesome.
Discovery of Contract Testing
00:05:10
Speaker
Good stuff. So obviously you blog about contract testing and you're active in that space training and stuff like that. So when did you first kind of learn about it? So I've just looked it up just before that. And I think the first time I got in touch with the team, we unpacked the pack for that was probably the first and that's some two and a half, three years ago now. Um, so I've been.
00:05:38
Speaker
writing about the trading in the API testing and mock-up space for a little longer, blogging about that a little, again, speaking about it, doing trading in it. I think I can't remember exactly, but I think it was the
00:05:55
Speaker
pack team who reached out to me who said, well, and we're looking at, and we have this, this, this approach, this new approach to as solving all of those issues you've got with large scale integration and M2M testing, it's called contract testing.
00:06:10
Speaker
This might be something that interests you too. So that's where I started reading up on it and trying out the tools and seeing what basically what contract testing is all about. So that's where this whole thing started. Yeah. So what kind of things at the time did you like about it and problems did it solve for you?
00:06:31
Speaker
I've been in testing and automation for, again, almost 15 years now. And especially over the last couple of years, of course, systems software has become ever more distributed from monoliths to service-oriented architecture to microservices to...
00:06:50
Speaker
One of the challenges that brings is doing again, large scale integration and end to end testing. You have all these different components that you need to get into the right state at the right time.
00:07:04
Speaker
developed in different teams and different organizations. It's really hard to synchronize that, to get everything in place in the right state at the right time. Contract testing claimed to be an approach and it has proven to be an approach ever since.
00:07:21
Speaker
to solve that issue. That to me is the biggest benefit really that I saw and that I speak about too. The tools are fantastic, but it's really about the underlying problem that's also really which is not having to build that big integration environment really and having all these dependencies which could be dozens or even hundreds of them.
00:07:47
Speaker
and all spinning them up, getting them into the right state at a single point in that each and every time you want to run your integration tests.
Solving Testing Challenges with Contract Testing
00:07:58
Speaker
Yeah, absolutely. Yeah, I think that's a big win for me is when I'm talking to teams and I say to them, what are the challenges you have with your integration tests? And then people start coming out, oh, the environment's not stable. It takes a lot of setup.
00:08:15
Speaker
I've got these scripts that rely on each other. They have dependencies. And so this is where I think, for me, contract testing really comes in and can really solve these people's problems. Yeah. I love the way, and I've stolen this wording from the Pack from Packflow team. So what I like about it is that it makes integration testing asynchronous.
00:08:42
Speaker
Yeah. So instead of trying to spin up and have everything in place at the same time, so do synchronous integration testing, each party, each component in that entire, in your environment, in your distributed system, does their due diligence as part of their own build development cycle really.
00:09:08
Speaker
And everything is stored into content that makes it asynchronous, which is much, much easier to manage. Yeah, that's a really good way to describe it. I didn't come up with it. I don't want to take credit for that. But that's what I love and it's something that I'm always trying to do when I'm training and trying to improve is really make these complex, complicated things and try to
00:09:35
Speaker
Explain that in as simple terms as possible that this is for me just the difference between the synchronous asynchronous is a great way of illustrate the describing the benefits of contract testing with.
00:09:49
Speaker
When I run my workshops, the first thing I always do is I ask people, do you know what it is? Have you got an idea about how you would do it? And the majority is always, I don't know what it is. And I have no idea how I would implement that. That sounds really, really familiar. Yeah. Yeah. So do you get the same thing? And yeah, what kind of feedback do you get?
00:10:17
Speaker
Yeah, absolutely. So it's just contract testing. It's a term that a lot of people sort of kind of are becoming aware of now. So they know it's a thing, and they know it's there. But as you said, when you ask them, can you explain to me what contract testing is?
00:10:37
Speaker
Well, blank stares. Yes, exactly. Not really. My explanation has definitely, hopefully, become better over the last couple of years. But it takes time because it is a different way of approaching a problem. So whenever I do a contract testing workshop with clients or at a conference or whatever,
00:11:06
Speaker
I always start with this guy. So the first part is theory, and that might take me 20, 30 minutes, just properly explaining what it is, how it works. If we talk about traditional, I love how we start talking about traditional contract testing now.
00:11:25
Speaker
With the whole new bidirectional thing being the new approach. But the traditional consumer driven contract testing explaining the flow, how it works, the responsibilities of each of the parties. So it takes me a solid 20, 30 minutes, but I want people to understand what's happening before I show them the code base that I typically use in workshops. What's happening here?
00:11:53
Speaker
Yeah, but once you've got that set up, then the learning curve does drop after that.
00:12:02
Speaker
Oh, absolutely. So the first thing I typically do in these, in these workshops is just have people replay, don't, don't make any changes and just run the tests on the consumer side. See that the contract's appearing somewhere. Don't even introduce packed brokers until way later in the workshop. So I want to just, just because I want to introduce one concept at a time,
Teaching Contract Testing
00:12:27
Speaker
really. Yeah. And that that's already pretty hard with.
00:12:29
Speaker
And that is it will just copy that contract from the consumer to the provider, run the test of the provider and see that all those test paths, which means the provider can fulfill all of the expectations in the contracts generally by the consumer.
00:12:46
Speaker
Yeah. It's typically only then, when I first told them the story and explained the flow of contract testing, I said, well, now just repeat that flow. It was three of the four steps. So generate the contract, copy the contract, verify the expectations in the contract. Then they said, oh, this is what it looks like. That's when things start to click. For sure. Yeah. No, that's a good way to approach it, I think.
00:13:16
Speaker
So in your blocks you have this running theme of a sandwich store. So is there a story behind this or is it? This has got the sound incredibly disappointing but no, not really. Other than who doesn't like a good sandwich.
00:13:32
Speaker
No, not really. I used things like webshop themes really often in a lot of talks courses and stuff because everybody knows what a webshop is and what it does. I was just looking for an example that was
00:13:50
Speaker
familiar to most, if not all of the people who would read it. And so, to not make things even more complex. But no, there's not really much more of a story behind it. No, no, that's all good. When I started performance testing, it was the pet shop. Obviously, yeah, the swagger pet store. Yeah.
00:14:15
Speaker
So I touched upon this a bit with Yousuf in the previous episode, but I think one of the gaps that potentially bidirectional can fill is the separation between testers and developers in implementing contract testing and getting involved with it. So I think that's where kind of end-to-end testing for me is a good conversation to bring in contract testing and say it can solve some of your problems and understanding it
00:14:43
Speaker
is part of the way towards saying, okay, I don't need to rely so heavily on my end-to-end test suites rather than looking at it from an outside perspective, which I think a lot of integration tests
Integrating Testing Roles
00:14:56
Speaker
do. I was interested to hear your thoughts on how you kind of see the difference between testers' input and developers' input. That is a really good question.
00:15:09
Speaker
First of all, thank you for that. That's making me think as well. To be really honest, I try to steer conversation away from who's responsible for what most of the time. That goes for software testing in general, for automation in general, not just for contract testing. There's always discussion, who does what? My typical answer to that
00:15:39
Speaker
I don't really care as long as it gets done. I know that that is a gross generalization. I sometimes joke, I don't care if the janitor does it as long as it gets done. But the better answer to that is, of course, it depends. It depends on your team, skill sets, and it's because of individuals, the ratio of testers, developers in your team.
00:16:08
Speaker
And whether or not, and a lot of teams have sort of kind of stopped identifying and labeling people as either developers or testers in their teams. And I think in a lot of times that's a really good thing because they are not separate disciplines really.
00:16:23
Speaker
They're so intertwined, really. It's really difficult to say, well, this is where development starts and ends and this is where testing starts and ends. That's why I try not to say about that, how can testers get involved? If you do this, they should get involved. They have people who identify or are identified as testers or identify themselves as testers. That's totally fine, by the way.
00:16:52
Speaker
So what you're saying is that all forms of testing, right, is both responsibility. So I think what I was leaning towards was end to end testing is traditionally done by testers, right? But if all testing is done by everyone,
00:17:09
Speaker
Yeah so that is a different way yeah it's approaching the problem in a slightly different way and i don't really believe in the illusion that everybody should be able to do everything because that's because what you get that what you typically get that is everybody's really mediocre at best sure yeah.
00:17:33
Speaker
But what i like to talk about more is the trick with testing in general and especially with automation is writing your test your automation as close to the problem as close to the implementation as possible i think contract testing because it is so by just by nature.
00:17:55
Speaker
And because it breaks down that whole integration problem into much more, a lot more smaller sub-problems or sub-questions or sub-tasks maybe, you automatically get your testing done way closer to the implementation.
00:18:12
Speaker
which means it'll probably be easier to incorporate in your, just as part of your regular development lifecycle, your build pipeline. And again, because it breaks down that big integration testing problem into a series of smaller.
00:18:33
Speaker
And I think that's a good thing for testers, because we all know these large-scale integration end-to-end tests, they are hard. Hard to write, hard to run, hard to maintain, take a lot of time. So any effort, any possibility of breaking that down into smaller problems. And yes, that requires both developers, but especially testers, to work
00:19:02
Speaker
More closely together they don't just look at an application just from an outside or perspective anymore they need to get to dive deeper into what what are the different components of the different consumers different providers how do those communicate with one another and what's the.
00:19:19
Speaker
at this integration testing and this integration issue that I've seen from which consumer provider by which integration is causing this bigger problem and zooming in and writing tests that are much more fine grained really much more much smaller in scope which I think is going to try and avoid talking about pyramids here but it is
00:19:45
Speaker
It is a good attitude. Basically, the only thing I'd say about it is don't try and solve something with an integration or that you can solve with. I'd rather have many more smaller tests, which is basically what contract testing is doing. It's breaking down this big problem back into all these smaller sub-tasks, really. And at the end of the day, if that's the developer doing it, tester doing it, somebody else may be doing it.
00:20:14
Speaker
That'll be different for every team, really. Great answer. Thanks for that.
Resources and Further Learning
00:20:21
Speaker
Cool. So I think that wraps up what I wanted to cover today. So where can we find some of your resources, your blog, and everything like that?
00:20:31
Speaker
And first of all, again, I'm the director of Inspired Academy. We offer courses and training in the software testing automation space. If you're interested in seeing what we have on offer, that's inspiredtesting.com.com. My own blog is on testanimation.com. So that's where you can find my ramblings on
00:20:57
Speaker
A lot of different things related to testing and especially automation, what domain name sort of kind of gets in the way. And that's also where I just now this morning published the last of a six port post series on contract testing, but there's lots more of there as well. And yeah, as you said in the beginning of this episode, I am trying to dial down a little bit on my
00:21:24
Speaker
especially my LinkedIn activity, but you can still find me there, contact me there, message me there, and I'm more than happy to have a chat on anything, software testing, automation, or training. Awesome. Yeah, we'll put some links in the show notes to all those links. I really appreciate that. So find those there. And yeah, thank you for coming on the podcast. Thank you so much for having me, Lewis. It was a pleasure. Yeah, really enjoyed it. Thank you.