Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
Meet Yousaf Nabi - Pactflow Developer Advocate
176 Plays3 years ago
Conversation with Yousaf, who has just started as a developer advocate at Pactflow. In this episode we talk about his journey to becoming a developer advocate, open source software, openAPI specs, API blueprints, testing your automation testing framework, component integration testing and much more. If you want to find out more about Pactflow or sign up for free. Also checkout the Tutorials, CI/CD (Consumer Driven Contract Testing) workshop, Bi-Directional Contract Testing Workshop, Pactflow examples
Hosted on Acast. See acast.com/privacy for more information.
Recommended
Transcript
Introduction to API Contract Testing
00:00:00
Speaker
Hello and welcome to how to start API contract testing podcast series with me, Lewis Pacman Prescott, where we'll be talking about the challenges of testing in microservices and how to start API contract testing to make microservice tests faster, more stable and more realistic.
00:00:19
Speaker
Welcome back to the podcast. We have a bonus episode this week. Had a great conversation with Yousef who's just started as a developer advocate at PacFlow, chat for ages enough to make a bonus episode. In this episode, we talk about his journey to becoming a developer advocate, open source software, open API specs, API blueprints, testing your automation framework and component integration testing.
Meet Yousef: Journey in Tech
00:00:44
Speaker
Welcome to the podcast.
00:00:45
Speaker
Thanks for inviting me, Lewis. This is my first ever podcast. So I won't lie, I'm a little bit nervous. And I've seen many different channels that you've, that you're promoting on. But yeah, really excited to be on. No worries. The first guest I had on was also a first timer. So hopefully it'll go smoothly for you. I had a good listen. It was really good. So he set a top precedent.
00:01:10
Speaker
Thank you very much. Cool. So yeah, tell us about yourself. What is your role? What do you get up to? So yeah, I'm Yousaf Nabi. I live in the UK, Leeds to be precise at the moment, but I've been around so you probably can't place my accent. I've been in testing. I'm a bit of a self-confessed geek massively into computers, cars,
00:01:38
Speaker
music, guitars, and I like to find out how things tick, how they work. Not necessarily very good at putting them back together. But I found that kind of has really resonated in my testing career. Nice. I think that's a really good attribute of a tester is someone who likes to dig in and work out what's going on underneath. So that makes sense.
00:02:04
Speaker
Yeah, definitely curious. So you've just started a new role as developer advocate at PacFlow. So tell us a bit about that and your journey to becoming an advocate. Yeah, so I'm really pleased to have joined the PacFlow team as a developer advocate. So my journey to becoming a developer advocate, I think some of you out there might be asking what a developer advocate is. Exactly, yeah. I found in my last role
00:02:34
Speaker
I had a bit of an identity crisis in tech. I wasn't really sure how to pen exactly what I did. I quickly found throughout my testing career that I enjoyed talking to people about the things we were doing. I enjoyed having an eye on the goal of the end user and the value the product was delivering them. And I think having lots of
00:03:03
Speaker
conversations with the people around me and empowering them into kind of good quality principles. Really, it helped discover probably more defects. I enabled more people to discover defects in the system sooner than I ever could on my own.
From University to Software Testing
00:03:24
Speaker
which I found really interesting. Yeah, that's really interesting. So back in 2007, during my university career, I studied artificial intelligence and cybernetics. I really wanted to get into the ethical side of software computing. I'd probably watch too much Terminator.
00:03:43
Speaker
And I thought going to Japan and stopping something like Skynet taking over would be really interesting. But during my time at university, I was on a placement year.
00:04:01
Speaker
was doing accessibility testing at a large bank and I found it amazing. It was one of the most rewarding experiences in my life. I got to see the power that computers and software could bring to the real world
00:04:19
Speaker
to the real world in enabling people with assistive needs in coming back into the workplace. And I was able to directly see the value that software testing provided. And when I finished university, the financial crash had happened and it was very difficult to get a job with my university degree.
00:04:44
Speaker
However, my placement degree, I also studied and passed an ISAB in software testing fundamentals and leaving university that qualification
00:04:59
Speaker
meant more than my university experience. Yeah. So I fell into a software testing job, a medical healthcare provider, and we were working on a e-prescribing system.
Agile Transformation Experience
00:05:14
Speaker
And it was very scary. It was really scary because some of the, so the e-prescribing system, we would test different interactions between medications.
00:05:25
Speaker
and certain interactions between medications could result in a patient dying. So when I would ask questions to my test lead, what happens if we let a defect through and we cause someone, you know, pain, harm or worse death?
00:05:44
Speaker
So I was really scared about the risks in software testing. And in this organisation, it was also very hard. We spoke about kind of different software life cycles in
00:06:01
Speaker
software development lifecycles in universities such as V Model and Waterfall. And this organisation was very much Waterfall. We had two releases a year. We had 80-day regression packs. I don't know if they were 80-day, but they felt like it.
00:06:20
Speaker
And after about four years, four and a half years, I thought that there must be a kind of different way. Like some of these problems I'm feeling now, I'm sure my dad felt in his computing career many years ago. So I moved to an insurance company and this insurance company was going through an agile transformation.
00:06:42
Speaker
Yeah. And I found that really exciting. As a tester, they they empowered me to well, they empowered anyone in the team to get involved in any part of software development. Right. And
00:06:56
Speaker
I find that really exciting because as a tester, I wasn't stuck at the end of the development kind of life cycle. I didn't kind of get a developed product. I was able to kind of get involved really early. So we talk about kind of in agile and agile testing kind of shift left principles. And it enabled me to start talking to the developers whilst they were developing.
00:07:25
Speaker
and it allowed me to peer into the code a little bit. I didn't really understand it, but I knew as we advocated for great things like the, as we talk about things like the testing pyramid, we advocate for a small amount of
00:07:45
Speaker
end-to-end tests at the top, a small amount of UI tests. If you've got this layer down from that, you've got your integration tests. And then a layer down below that, you've got unit tests. And would advocate, we'd say that the unit tests give you really, really quick feedback. And you want loads of them. And you want very, very few UI tests. And your nice middle ground is this integration testing area.
00:08:14
Speaker
gives you a nice trade-off between feedback and confidence. So I was talking about this testing pyramid, and I was advocating for writing lots of unit tests, but I had no idea what a unit test was. I'd never written a unit test in my life.
00:08:31
Speaker
I moved on to a new company called Skybat and I very quickly had been tasked with a small team in developing API blueprints.
Developing API Testing Frameworks
00:08:46
Speaker
There were lots of teams that developed microservices and we were looking for a common
00:08:54
Speaker
Kind of standard yeah as lots of teams were developing them it made sense to make a kind of bootstrap and that bootstrap would contain you know nice documentation out the box that was kind of standardized.
00:09:10
Speaker
they approached me with regards to the API testing and wrote my first programming node. It was an API testing framework using open source software. I very quickly realized I had been asked to do something that I didn't really have the skills to do. I thought, why reinvent the wheel?
00:09:35
Speaker
I'd often heard of open source software and lots of great talented engineers take their time to write programs and they release them for free under different licenses and you're welcome to use them. And if they don't do quite what you want them to do, you're able to tweak them.
00:09:56
Speaker
So I picked a particular API testing tool. It was called Chacrum. And I wrote a kind of API testing framework. And we used Swagger to document our API, which for me was a refreshing change from a Jira ticket that someone had scrolled an API, a Word document that had been shared around or an email.
00:10:20
Speaker
It was very hard to work out what the master copy was at any one point. Something very interesting I found when I was doing the development of the testing framework, a developer colleague had come along and was reviewing the testing framework. He started writing tests for the testing framework, which I found really interesting. It was kind of test-ception.
00:10:49
Speaker
He was asking, as we were writing some of these custom methods and helpers, how do you know that's going to do what you want it to do? So I was interested, introduced kind of the first concept of
00:11:04
Speaker
unit testing and I was working with this developer and this was before we had SDET, software developer engineers in testing. I began to talk to him about his development career and some of his experiences and some of the pains in microservice development.
00:11:27
Speaker
And one of the big pains he had was as you develop a microservice and it would talk with another microservice, sometimes the communication between them would break down. And it might be something as innocuous as a changed field. And you'd have to go and find the team that produced that service and have a conversation with them about the changed field.
00:11:57
Speaker
Someone's got to give way. Someone's got to change their field. And that becomes much harder for a provider when they're providing a service and they've got multiple consumers.
Challenges with Microservices at Sky
00:12:10
Speaker
Absolutely. And as you're developing your microservices as a provider, you have the challenge of not just one person, one team coming to you.
00:12:23
Speaker
saying that their calls for their API have broken, but there's multiple teams. You have to start considering things like versioning and its compatibility. It becomes really difficult. Software delivery is hard enough as it is. Microservices were meant to make our lives easier, right? Exactly, yeah.
00:12:41
Speaker
We'd successfully implemented the API blueprints, but we hadn't put any form of contract testing in there at that moment. At that point, the microservice blueprint went down a storm. The developers really liked the experience of bootstrapping a new microservice. They were still feeling the pain of the contract, the breaking contract.
00:13:10
Speaker
Unfortunately, I wasn't able to solve that problem at Skybat because I moved on to Sky. We were tasked with building a new Greenfield application. It was a website that would be serving upgrades for the new flagship product, the SkyQ box in the home. And this new application was a React UI.
00:13:33
Speaker
with a GraphQL intermediary service. There was a set of microservices built with Spring Boot. It was around 20. They ultimately all talked to a single legacy backend.
00:13:49
Speaker
that was based up in Scotland in Livingston. As a kind of greenfield application with 20 micro surfaces in place and a GraphQL kind of layer, I had the unique chance to capitalize on the pains we'd felt around contract testing.
00:14:08
Speaker
So I was also quite empowered in this role, technically, to either try and do the technical things myself, so kind of build CI, CD pipelines, or ask those around me to, you know, developers around me and power them to kind of help me build the vision. So we built a contract testing solution of sorts.
00:14:36
Speaker
So one of the pains I found with integration testing, in previous organizations, I didn't always have access to the source code. So my only tools were end-to-end testing tools or integration, API integration testing tools.
00:14:54
Speaker
against real live services. So I'd have to wait for something to be developed and deployed into a test environment. A single journey through the UI front end might touch a different number of services. People would often complain about the integration test being flaky.
00:15:16
Speaker
the builder read or when I joined a particular organization we were able to deploy software but the general status quo was red builder okay and it's safe to deploy. The tests are just flaky we can just re-run them and I could understand why these integration tests were flaky.
00:15:40
Speaker
When I find a defect, I'd really like to look into the root cause. But when your integration test fails and your failure point could be any one of 20 services, like looking for a needle in a haystack. So we could see contract testing plugging that gap. So as testers, we're always trying to talk about testing at the right level and ensuring we get the right value.
00:16:06
Speaker
And also, in order to try and reduce the amount of bloat you have with testing, you want to ensure there's as little overlap as possible. When you start looking at the unit testing or the testing that developers are doing, you realize that they're not just testing the smallest units of code, but they're doing component integration testing as well.
00:16:31
Speaker
So they're looking at the challenge of testing these microservices and they create mock providers of the services that they call. They're managing their own test data. That test data
00:16:45
Speaker
can very quickly become unwieldy or can become stale. It doesn't necessarily represent the provider state at any one time. As testers with our integration testing tools, we probably got our own idea of what good test data is.
00:17:02
Speaker
and kind of test data management. We've been doing that as our bread and butter. So we're doing this component integration testing at a developer level. And we can do this in our CI pipelines, and we can get really fast feedback loops. So when we talk about shift left, we get really closer to that ideal. But in order to reduce some of the risks of those mocks becoming stale, we had the idea of contracts.
00:17:30
Speaker
And if we could share those contracts with our providers, it would be really useful. At Skye, we built a test pipeline, a CI-CD pipeline that created a shared set of mocks. And the shared set of mocks could be used by the developers.
00:17:50
Speaker
in their unit and component testing and we would also validate particular CI build against these mocks. We were able to validate the deployed services against these mocks as well. So when the service was deployed.
00:18:09
Speaker
we would call the real service and we would check, we would do some schema comparison against our mocks to try and ensure there was little drift. It was quite a complex setup. There was a lot of moving parts. We had some good documentation to support it. But whilst trying to implement all that and document it, we also needed to start a change organizational hearts and minds.
00:18:38
Speaker
I'm sure you can probably talk about some of the challenges that we've faced with getting organizations on board. Yeah, definitely. It's always difficult when you're starting from the point where you've already got your integration tests, you've already got your end-to-end tests, and also you've got to get the developers to buy into adding another level of tests. As you say, it's building that infrastructure around it.
00:19:05
Speaker
I mean, PackFlow does that for us now, and packed is a great source for that. But ultimately, the challenge of getting someone to think about how they're going about testing it in a different way, I think that's what's quite hard for people to get a grasp of is like,
00:19:21
Speaker
when you start TDD. It's a complete mindset shift and so getting people on board with that idea and then contract testing is not just the developer. It's if you're in a big organization you've got the solution architect who needs to be brought into it and then yeah it's all that stuff around it so yeah absolutely.
00:19:41
Speaker
I feel you on that one. Yeah, yeah. And that's the crux of it. It's hard for organisations to change at that kind of scale and level. And it was difficult for me to... It was a difficult sell, right? I was going to ask development teams to slow down a little bit.
00:20:01
Speaker
to implement contract testing, to stop feeling the pain of integration testing every day, to make fundamental change the way they work. I knew it would save time ultimately in terms of delivery. We could deliver things quicker with more confidence. I think that's one of the things that's a hard sell is that delayed gratification.
Changing Mindsets & Coping with Stress
00:20:24
Speaker
You know what I mean? People are happy with the current situation. It's not perfect.
00:20:28
Speaker
but they're happy to go along with it. Whereas you're saying, I will save you something, which once we've implemented it to a level, because you don't get the value straight away, you have to invest that time, you have to have quite a number of tests. As you said, you've got a number of consumers need to have all of those consumers
00:20:48
Speaker
adding in those scenarios. So it's not an immediate response. So that's the thing, is you need to sell something which is going to take time to deliver. So it is a hard sell. Yeah, I think one thing involves collaboration, first and foremost. You're asking teams to have conversations earlier and sooner about kind of documenting their APIs and agreeing their kind of use upfront.
00:21:15
Speaker
By doing that, you don't feel the pain later. So yeah, it was a big challenge to try and find out, well, what do the people in the positions of organizational power care about and how will this help them? So that worked really, really well, but I wasn't able to crack that organization or nut, I don't think.
00:21:41
Speaker
I went on a stress control course, and one of the main messages they gave me on the stress control course was, worry about the things you can control. Don't worry about the things you can't. So ultimately, I left work IT entirely to go and play on old cars. All right. Wow. Yeah. It was refreshing. It was really exciting.
00:22:05
Speaker
So, but after about four months of tinkering, I got a call from an old colleague, an old manager at Skybat, and he said, come and join us at Infinity Works as a consultant. We could definitely benefit from a bit of your test knowledge.
00:22:24
Speaker
And I definitely felt a change in a pace of life over those past four months. I miss talking to people. I miss sharing things I was passionate about.
00:22:40
Speaker
Yeah, I'd always love giving things back to community. I've written blogs in the car car kind of world before and in in the computer kind of hardware world. So yeah, it felt like a natural kind of
00:22:56
Speaker
position shift to go back into IT, but to go into the consultancy role. The consultancy role provided me with a bit of a blank canvas.
00:23:12
Speaker
Moving to the consultancy felt like a natural fit for me. We were due to be developing a, going on to a new Greenfield project, which again, again is always exciting.
Consultancy Role at Infinity Works
00:23:23
Speaker
We were replacing an old school legacy application and we were looking to build kind of a distributed system in AWS with multiple microservices, a static site served from S3.
00:23:36
Speaker
with a load of serverless Lambdas all backed by API gateway. On my first day, I went in and everyone was talking about Lambdas. And I had no idea what they were talking about, honestly. But I knew there was going to be some new challenges ahead. And straight away, I was kind of thinking, we've got some distributed systems, distributed microservices, and there's going to be contracts between each of these.
00:24:02
Speaker
So let's look at getting contract testing in early. So one of the first things I did was I, and it kind of ties back nicely to the developer advocate theme, I wondered, so I was in a team of around eight people. So there was six developers, one kind of account lead who had a lot of experience in delivery, agile delivery, and one tech lead.
00:24:32
Speaker
and myself. So I was the only tester. Yeah. And I very quickly thought this is a monumental challenge ahead of us. And I can't do this alone. So how do I get the guys on the guys and girls on board? So we had a we had a whiteboard session back when people were able to to be to me is of each other and we just talked about all the different types of testing that that people knew about.
00:25:01
Speaker
Yeah. You know, all the different types of unit testing there were, all the different types of non-functional testing, and I'll say that the subject of contract testing came up. This is where kind of the story of PACT got weaved in. So,
00:25:17
Speaker
One of the colleagues in my team, he previously worked with the Sainsbury's account and he had used PACT there. So PACT is a contract testing tool and it provides that complexity in that CI-CD setup that I previously created at Skybat.
00:25:37
Speaker
It was all neatly encapsulated in the PACT tool. So the PACT team had seen a similar problem in their organization in 2013 or slightly earlier. And in 2013, they open sourced the PACT product because they realized that other people were feeling this pain, much like we've seen in the microservice world.
00:26:01
Speaker
the tool quickly grew in popularity. Unfortunately, I hadn't heard about it at the time that I'd implemented my work at my last place.
PACT Community Involvement
00:26:12
Speaker
But I got to hear about it now and I was really excited and it looked great.
00:26:17
Speaker
It had a really strong feature set. It was supported in multiple languages, which was great. It was open source. So if it didn't do quite what I wanted it to do, I could make it... Again, going back to that thing of not reinventing the wheel.
00:26:35
Speaker
Yeah, so got really excited with the packed community. And if you've ever looked at the packed docs or packed website or any of the packed ecosystem of tools, they will lead you towards the packed Slack group. There's around just shy of 4,000 members in this group. So it's a huge community.
00:27:00
Speaker
And I've been part of it since 2018. There's 4,000 people who are involved in contract testing or feeling the pain or feeling the benefits of the PAC-2. The fact that it's open source and the team have taken their time to build something and to work with the community and understand their pain really, really resonated with me.
00:27:25
Speaker
It resonated with me from the developer advocate perspective of enabling developers to be more efficient at doing their jobs. Ultimately, the organizations they work for are not usually in the market of being a software house. They're doing something else. IKEA are selling you wardrobes, but they probably need to employ a software firm to keep everything going.
00:27:53
Speaker
So how does that translate to what you do now at PacFlow?
Role of a Developer Advocate
00:27:59
Speaker
So I think some of the key attributes of a developer advocate are
00:28:07
Speaker
Some of the three main ones I'll kind of pick out are empathy as one of them. I think being empathetic towards your end users and having an eye on what success means for them in whatever industry and whatever product it is you're delivering and you advocate for their best interests.
00:28:30
Speaker
So it might be connecting your users with your developers at a really early stage and being empathetic towards developers themselves, you know, understanding their challenges and pains and working out how you can solve them sooner.
00:28:49
Speaker
I think the second one is having a passion for sharing knowledge, especially in the tech industry. I found when I first started, I felt intimidated by those around me, people who had kind of 20, 30 years of experience in a driven brand.
00:29:09
Speaker
I'd learned some things along my way and I just wanted to talk about them. And as I spoke about them to the people around me, if it resonated with them, they amplified the message as well.
00:29:23
Speaker
And then you might think the words developer and the developer advocate might mean that you'd expect someone to be really, really technical. They're one of these rock star developers. They can code anything in any language. But I don't think you need to be because the developers themselves are really
00:29:46
Speaker
have spent their careers honing really relevant skills in different languages.
00:29:55
Speaker
they're really good at solving problems. But sometimes, because they're not connected with the users, they're not solving the right problems. So having some technical background allows you to be able to tailor your conversations, be it with a product owner, where it has to be a bit more rounded and less technical. But when you're having those conversations with your developers and tech leads, and you really want to
00:30:22
Speaker
to bring on some kind of organizational change and best practices, you need to speak a different language. So that's where having some tech skills really becomes invaluable. For sure, yeah. Definitely. I think that comes from being a tester as well. It very much helps when you can look at the code, read the code, and you can speak the same language as the developer. I think that really helps with that relationship. So yeah, that's a really good outline. Thank you for that.
00:30:51
Speaker
I'm interrupting the podcast to remind you all to like and subscribe. I hope you're enjoying the episode. Let me know on Twitter at Weege Prescott or in the comments on your preferred podcast platform. Thank you. Back to the podcast.
Tech Scene in Leeds
00:31:06
Speaker
Yeah, I just wanted to touch on where you're living in Leeds at the moment. Obviously, I'm based out of London. The tech scene here is obviously really good. But Leeds has a great hub for that as well. I did my graduate scheme there and spoke at the Leeds Testing Atelier conference or unconference, as they like to call it. The Leeds tech scene is buzzing as well. So I think we need to call out
00:31:32
Speaker
that London isn't just the only hub for techies. There are other places. Definitely. Leeds is a great city. So I've been here for around six or seven years now. I've not attended the Leeds Test in Ortele, but I do know that the Ministry of Testing also hold events in Leeds. They're actually due to be holding their latest one in April.
00:32:00
Speaker
check out Meetup to find out some more details around that. Yeah, from a tech hub perspective, it's really exciting. I think, obviously, many people have seen the news about Channel 4 opening up in Leeds, so they are sighted at the Majestic, just opposite the Leeds train station.
00:32:20
Speaker
which suffered a large fire a few years ago. It's absolutely great seeing that building all done up. We've got some amazing tech players in Yorkshire. Something that's been really exciting that I was really passionate about was at my previous role at Infinity Works, they have a really vibrant tech academy.
00:32:42
Speaker
where they take people from all different backgrounds. They run boot camp courses to get people into tech and we are then seeing the people move on from there to loads of different tech organisations and spreading the great word. So yeah, it is unbelievably amazing. Can't wait to get you up here, but equally, when I'm down in London, I'll give you a shout.
00:33:06
Speaker
Yeah, definitely. I'm sure we'll be up in Leeds soon. Also, I would love to speak to you more in future episodes of your podcast, so you can follow the journey of us at packed flow. Yeah, definitely. I think it would be great to get you on again once bi-directional has been adopted, see some case studies, hear about how it's going down and all those initiatives that you mentioned about making it easier for developers to contribute. So yeah, it'd be great to hear about how
00:33:36
Speaker
how things are going later down the line.
Invitation to Join PACT Community
00:33:39
Speaker
Yeah, in terms of same posting, if you are interested, you should come join us in the packed Slack community at slack.packed.io, or you can check out our website at docs.packedflow.io, where you can check out some of our great university tutorials and examples where you can see the bi-directional flows in action and test them out on your machine.
00:34:06
Speaker
We'd love to hear your feedback on the new feature, and if there's anything more that you wish to see, give us a shout. Yeah, good stuff. All the links and stuff will be in the show notes, so they'll be all there for you to take a look. Yeah, definitely check out the tutorials and stuff. They're really, really easy to follow and get involved. Thanks for coming on, Yousaf. Really appreciate it.
00:34:29
Speaker
No, thank you for being such an amazing champion of the patch community and we look forward to working with you more in the future, my friend. Thank you.