Api Testing and Mock Servers with Pricilla Bilavendran

Welcome to the Test Guild Automation Podcast where we all get together to learn more about automation and software testing with your host, Joe Calantonio.

Hey, it's Joe and welcome to another episode of the Test Guild Automation Podcast and today we'll be talking with Priscilla all about API testing, mock servers and a whole bunch more. She has a lot of expense, a lot of different things, so we're probably going to touch on a bunch of different topics, if you don't know. Priscilla is a passionate test engineer with a decade of experience in quality engineering. She has experience with different flavors of testing like functional testing, EDI testing, ETL testing, automation and API testing. She's also a Postman Supernova and speaks at various events regarding API and postman, so we'll probably touch on that as well. She's also passionate about cloud computing, which is a really hot topic once again. Hopefully we'll get our opinion on that. She is an AWS community builder and she also has is one of the global ambassadors of Women Tech Network and she believes in coexistence in harmony and she has a certified mentor that helps many engineers through her mentoring sessions. So she has a lot of experience. She's an active community contributor through her blogs, webinars and workshops and podcast interviews like this. So really excited to have her on the show. You don't want to miss this episode. Check it out.

The Test Guild Automation Podcast is sponsored by the fantastic folks at Sauce Labs, the cloud based test platform that helps ensure you can develop with confidence at every step from code to deployment. For Every framework, browser, OS, mobile device and API. Get a free trial. Visit testskill.comSourceLabs and click on the exclusive sponsor section to try it for free today. Check it out. Hey Priscilla, welcome to the Guild.

Thank you so much for having me, Joe.

Awesome to have you. You have quite an awesome bio. So is there anything though I missed in your bio that you want the Guild to know more about?

No, you pretty much covered everything. Maybe just a bit to add on about my family stuff. Like I have a 4 year old who keeps me busy all time. So other than that, so you know how things work, right? So whenever he is actually in a dormant state, I will be hyperactive because that is where I have to start working on my community stuff and blogging and everything. So that's where. And of course he's again a good contributor. Sometimes I get a spark from him as well. So I should admit that. Other than that, yeah, I love to speak with the budding test engineers, Joe, especially because I Always feel like some things would have been better if I got to know all these things as a younger QA myself. So I always feel like giving all those points to the budding test engineers to get them or to give a good awareness for them to have a good knowledge about all the existing platforms, how to work and even about the communities which I wasn't aware few years back. Of course the communities were into existence for years, but I came about to know about them only for past few years. So this is all I would love to do and meeting all the testers from all over the world and speaking at the conferences like whatever I know and just trying to educate people more on that.

Love it. So you do a lot of mentoring. So you do say there's a lot of points that come up that you wish you knew when you started. So is there anything that comes up a lot that you notice that a lot of newer testers may struggle with?

Exactly Joe. One thing which I feel is like their strong fundamentals about testing. When I interview most of the young QA professionals, right, they all say like they were into automation testing directly. Hey Priscilla, I agree, what are your questions are. But I was, I actually started my career as an automation tester. I'll be like, okay, I'm so happy that you are so fortunate enough to start your career as an automation tester. But basics are mandatory, right? For anything the basics are mandatory. So that is where I still see some people are lagging. For our upcoming testers we should tell them like what is the importance of getting to know more about the testing basics and the process starting it might be painful, but in the long run process is going to pay you for. Like so this is one point which I'm keep on preparing the young test engineers and some people are, they are really good enough Joe but they aren't aware of the platform, like when, where, who to reach. So this kind of guidance is also much needed for them. So that's how it's all going with this mentoring session as well.

That's interesting. So I know when I speak with testers sometimes when they go on interviews they get hammered with a really technical, it's almost like a developer interview. So they need to know all these like things that they probably would never use as a tester. I don't even think they get asked questions testing related. So you're seeing actually that obviously that's an issue. But when you're experienced, when you interview people, you do ask them questions about testing and things around the fundamentals in that area.

Exactly. Yeah. I strongly believe those fundamentals are going to keep give a value add for your automation even. First you should know what is testing, what are the testing principles and only then you will know the value of automation. I always believe that Joe, that's why.

So I apologize, we're completely off topic. So what do you think people need to know then or have in place before they can do automation testing?

Then okay, for them to get started. First thing they should have a strong system knowledge. They should know what that system is all about. Like what is the upstream, what is the downstream, what are the tech stack, what the application is built upon, whether it is React or Vue, whatever it is, they should know the tech stack of the application before getting their hands dirty. I always believe this Joe. Like they should first understand the A to Z of the system and then they should come up like okay, so what are the feasible scenarios for automation, what are the non feasible scenarios? Because 100% automation is a myth. Right? So they should first know what is feasible, what is non feasible. And based on the tech stack of the application they should device their framework, what tool or what framework they have to use for their front end automation.

Cool. So you know you said they need to know a tech stack. I know a lot of companies are moving to cloud native and you are a cloud computing expert. So any advice you give to testers, is there anything unique about a cloud based application that may be different than an application they may have more experience with like a server application or something?

Not that much Joe. Like your normal application knowledge will definitely fit in when you're testing for the on whether it is on prem or cloud, whether it's going to be the same way. Only thing is like when it comes to cloud I believe there are a lot of low code, no code tools are also available. Like you don't want to literally go for your complete lines and lines of code. I know they're already doing a revolution. So in that place I always suggest like it's not rather to give it a try because don't follow the crowd just because everyone is using Selenium just because everyone is using Cyprus. Just don't go for it. Give it a try for the low code, no code tool. I know they are into the market for few years, I know because there is no long run history. Like how do they maintain the long run scripts and what do they do with the scripts which is in the shelf for long years. I don't know that. But it's no harm in giving it A try to them so that I believe these kind of working out with those tools and providing the feedback to those low code, no code platforms. Right. That is ultimately going to save your time one day.

That's interesting. I agree. I think it's controversial though. So hey, let's dig into that a little bit. So you've tried low code. So what happens whenever I mention low code and no code? I get a lot of people just freaking out on Twitter and LinkedIn. A lot of them say it's not really testing, it's not automation, it's not really doing anything smoke and mirrors. But like you said, I know a lot of vendors that are low code, no code. They have to provide some value because they're in existence and companies are investing in them. And obviously there's going to be certain parts of the application where it makes sense to maybe use that type of technology as opposed to other areas. So I guess my question is you've actually seen low code no code solutions work for you.

Actually we are also doing poc Jo, because you know we are also being into traditional automation thing. So we are doing POC right now. So even I'm. I met a few of my friends through mentoring session and they're also looking for kind of advice in this area. So I currently that's why I'm telling like I even I I'm so curious in long run how these low code no code tools are going to work. I'm also curious along with you as an audience, I'm so curious how are they going to maintain the scripts like for the long run what are they going to do the scripts in the shelf and how it's going to be like the dashboard or whatever it is, even the application upgradation, whatever it is when it comes to that even I'm so curious about it. So maybe it's time we all should give them an opportunity and just try to get to know more about them.

So when you're interviewing people or mentoring someone and they say hey, keep hearing about AI, I keep hearing about machine learning, I keep hearing about no code, low code solution. Is there going to be a job for me as a tester in the future?

Okay, yeah, they have heard it. Even I have that question also because every day something even like every new trend is coming up. But as a tester what I should do, one thing I realized is like Joe testers when compared to developers actually they are forced to live as jack of all trades because that's the specialty of testers. I don't Know why? Because if you ask a developer to learn a new programming language like say hey come on, actually we are tiring all those dot net applications and we have to move to JS or something, they will literally resist. Some people might learn, but they'll take time. But I have seen this beauty in testers. If you ask them to learn a new programming language because they might have worked Selenium with C Sharp and if you ask them to work with Selenium in Java, they just ask you for one or two months joke and they'll pick it up. So that's the specialty of testers. They are jack of all trades, I always believe. So when it comes to that aspect. I believe whatever technology or whatever trend is coming on the fundamentals, why it is coming into picture, we should know the history of it, analyze the history, why it is coming into picture and what it is going to replace and not only going to replace in what way it is going to help your testing and testers. So just understand the basics of it unless and until if you have your scope like in your organization or in your project, if there is a scope for a machine learning or low code or no code API, whatever it is, if there is a scope for those technologies or software trends in your company, then try to dig deeper, then that is what I advise to them to do.

Absolutely. So in my career I've seen myself more as like a toolsmith, like creating tools to help people do their testing. But when you talk to a real tester, I think they undervalue themselves. They're usually the people that know the whole application inside it out. They know all the intricacies, they know how to build infrastructure where a developer is usually just focused on one piece of things. So like they have so much knowledge that I can't imagine ever replacing a true tester because they, they're like you said, they know the tech stack, they know everything. So it's. I'm just amazed that I think they don't get enough love that they should for sure. So I guess another thing people struggle with is as you said during interviews ago, I. I'm an automation engineer. How many people do you think focus just when they see automation on like GUI automation and. And don't think about other types of automation that can help like API testing and things like that.

Mostly people are like kind of they are focused into one thing unless and until they are given an opportunity. You are right, people will be focusing too much towards Selenium and Java unless and there is another person a Senior test lead or manager coming and saying to them, hey guys, come on. It's not only Selenium Cypress is also there, come on. Test Cafe is also there. So unless and until somebody is coming and telling to them, of course they are not getting that enthusiasm to learn. But that is why I'm forcing them to be part of the testing communities. Like come here. It's not about always giving, right Joe? Because first you can volunteer, can come see, just sense the feel like what's happening around you. It's not just about one tool, a technology, whatever tool which you think as, oh my God, this is going to be my one stop solution. Other tester will think like no, my God, it's a trash, I'm not going to use it. So people opinions are totally different. So all these things you will get to know only when you interact with different setup of people. Right. So that is why I always push them to do it. So you are right, there are certain set of person, maybe I can say like 30 to 40% they are thinking like only this is the way and this is how I'm going to be. And this is the only tool for automation. There are still some people.

So that's.

Hard to fix though like you said, you encourage them to try other things for sure. But I just know from my long experience I used to fall in love with the tools really easily and then over time as you get older, those tools go away and then not out of a job, but you have to pivot quickly. But sounds like you're saying, hey, be open minded, try tools, use the right tool for the job. It doesn't mean you have to use the most popular tool and that's always the right choice, right?

Exactly right.

Cool. So how did you get then into API testing? Because it seems like you're an API testing evangelist almost as well.

Yeah Joe, I can say that it's, it's a kind of love at first sight. You will not believe because 2019, if I'm not wrong, my lead it was initially what we were doing is John. It was a new program as such which we were doing for the client and wherein like my test lead forced us to learn APIs. Because what we were literally doing is like we are called as integration team but we are doing the work of manual testers. Then he forced us to learn APIs and then we asked the developers about all those postman collections. Just give it to us, maybe we can start playing around with the APIs. So how I get started is like initially we had a Documentation for one of the client application. And based on that documentation I built my postman collection and then we automated the test data process through APIs. And that's how I learned a lot about it Joe, because I had to do go through the documentation. To go through the documentation I should have the technical knowledge of APIs and what works and what not works before that. I know I have heard about that term, but I haven't get into this much deeper. So after that getting that documentation, we tried to turn that into a postman collection and then we tried to automate the test data process. Like instead of creating the test data manually through front end, we started automating the test data via APIs. And that comes like many because Postman has many inbuilt features like dynamic variables and all those things. It was very cool to play around like okay, test data are like very different. I'm not just going to create like how to say a simple 001 or 002 test data. I have an option to mix and match. Using this dynamic variables I was able to create a variety of test data which was pretty, which was actually pretty looking in the front end. So that's where I realized like APIs are more powerful. I remember doing all these backend injections when I was working as an ETL test engineer. So when it comes to API again just a single hit is going to create hundreds and thousands of test data for me. And when I'm seeing that in front end that gave me a different field job. And this JSON structure and all those things is a totally new to me. So I started learning about all those things. And then I always have a habit of story making Joe. Like whatever it comes into picture, I always make my own story. So that is how I started learning more about APIs. Okay, so this is a starting point, this is the ending point. So how to a layman, a person who is totally new to API and API testing, how do I explain to them? Only if I'm successful in that I'm a good API tester, I'm an accomplished API tester, so I always. It's not just for APIs, whether it is for any technology. If you ask me to like Priscilla, go and learn this, go please just go and try this. No, I always do this. Like I used to create my own story and I'll ensure that if I'm able to explain this to a new person who's totally new to that technology, then I will have a confidence. Okay, now I'm able to connect all my dots. So in that way I'm a good tester in that technology or in that tool. So that way I started my API testing career.

Very cool. So do you notice API testing replacing UI tests that may take long to run or like you said, you use it maybe automate tests that you couldn't automate using a UI test.

Okay, there are some advantages and disadvantages of API testing, right? So when it comes to that, I might say like it's not completely going to replace the UI testing, but it'll help you to reduce the load of UI testing. Because more of the things when you're trying to capture in the previous level, of course your UI testing load is going to be reduced. Like maybe if your API testing is done extensively or exhaustively, your UI can be more focused on user like whatever, like the based on the user feel or like how does your user or a client wants to see that all those cosmetic and all this beautification issues, right? Maybe you can try to focus on that. So that is one of the things it's not completely going to replace. But you know, more of the like everybody is like they are completely moving on to this micro services based architecture, right? So once in a while of course all your applications are going to touch any of your APIs in that case. So obviously API testing is going to grow. So I believe API literacy is mandatory for every tester.

So as far as that API literacy, then what does someone need to know about APIs do you think fundamentally to really understand them? Especially as they start diving into microservices and whole architectures that are like plus.

First they should know in their day to day life whatever they are using, what are the APIs they are touching starting. If you are using your iPhone like you might, you might use your face recognition for unlocking or you might use your Google authentication for your any of your websites and all those things they should know that first, like where APIs are coming into picture in your day to day life. So this is what is an API. Then they should know more about like what are the latest trends, like what is the rest, what is soap, what is GraphQL, what are the protocols they are following it on, what are the design procedures? And when it comes to testers, of course they are more focused towards the HTTP status codes, what are they going to do? And then what are the kinds of assertions like as an API tester, what are the types of API testing? There are a lot of types, right? Validation testing, functional testing, penetration testing or security testing. It Starts from. So as an API tester I should get into all these details. But do not stop with that knowledge. You have to bit extensively try to know what is an API design, what is a schema, how they are developing it. Maybe you can try to have a basic hands on about developing a simple API about any of the. Because it's all we have all the tutorials outside. So you can just try to go ahead and create a simple API. Try to understand what is open API, what is, what is a split. They are using many terminologies right when it comes to developers. So try to understand that in that way when you go for a combat or when you go for a discussion with your developer, it becomes meaningful. Like they'll try to listen to you more.

Awesome. So in the pre show we talked a little bit about mock servers. So as you were saying microservices and things like that, a lot of times you may be consuming like a third party dependency and how do you test that? So I guess my question first is what is a mock server? And then what does the mock server do? Does that help you with these third party dependencies that you may not be able to test and your test in staging environments?

Exactly. You're right Joe, it has Mock servers are nothing but they are going to mimic. You are going to design in a very basic term how to say is like there is going to be a server, it will respond in a way how you asked or how you designed it to respond. That's it. Whatever the instructions you provided that to do, it will respond in the same way. So that's the beauty of mock server. Even if you stress it or load it, whatever. Like if you. Even if you hit on asynchronously it's going to respond you with the same set of responses. That's the beauty. But usage is totally dependent upon every situation. Because as you said, third party integrations is one of the usage. Because when you are trying to integrate few APIs and the third party application is telling like we have some security issues, maybe you can't test that in your test environment. During production we'll give access to you and you can integrate that. In that case what we'll do is from that third party we'll get a sample API response, we'll try to mock that and with that sample API response we'll get a mock URL. That's how we call it as a mock server. And that mock server is going to return the same HTTPs response every time you're going to hit as if it is coming from the third party the same way. Just one use case, Joe. Because I always believe mock servers are one of the underestimated topics because it's just one of the use case. It has lot of use cases. There might be a kind of known issue. Say for example, you are integrating n number of APIs and there isn't one API which is totally unstable and everyone is aware and developers are working on that. But I have to go through that API in that case. If I'm using that real time API, obviously most of the times I'm going to get the service unavailable error message which is going to fail all my test cases. So what I can do is I have a defect in place and people know that API is unstable and I can actually create a mock server for that API or I can just mock that. I'm just going to mock that API. Literally. I'm going to copy the response and I'm just going to design a server which is going to give me a proper 200 okay response every time. And my integration or my end to end API test cases are just going to be in a flow and it's all going to be getting passed. So there are multiple use cases about mock servers.

Nice. So in that particular scenario I guess some people will be worried because they'll say, well, it's not the real API. Am I just covering up a real issue? But it seems like it's a known issue. You don't do that for all cases. It just may be a flaky API you know they're working on. It just allows you to continue working. So it's almost like it can help you shift your automation left earlier because you don't necessarily have to wait maybe for an API to be done. If you know the specs, you can mark it out and then use that for your test to start automating. And then as the developers start making them go live, you could start incorporating the live APIs, replace the mocks. I'm just thinking of other scenarios. Is that something you commonly see as well?

You are right. What we do in that case is like mostly we used to get the sample response from the developers. Joe, the probability of changing those responses is actually very, very less because that is an approved design, a kind of design for them as well. Right. So it's a kind of approved one. If something is going to change in the sample response, it's a requirement change, a kind of requirement change. So definitely it's not going to happen. A very rare case it might happen, but when it is happening as well, of course we have to update the script, but so far fortunately we haven't faced that. So once we finalize, the developer is going to give us sample response and we are going to create a mock server and we'll be trying to integrate along with the API calls.

I would also think, and I could be wrong, that a mock server would help you be able to do better test coverage because maybe you can mimic error cases that you couldn't meet with the Live API. So I assume can you create a mock server that rather than do happy paths, it returns some garbage and you see how your application maybe handles that?

Yeah, we can do that. We can. Because some APIs are like kind of example. Like when you take Salesforce APIs, you can't make too much of negative testing over there because even for example authorization and all those things when you want to hit the API, when you're trying to break the API and you don't and you want to do too much of negative testing, of course you are right. It's better to go with the sample or mock the responses and mock the servers so that like how to say, as you mentioned, the coverage is also taken care and the real API is also not damaged to some extent.

So how do you create a mock server? Sounds great. Is it difficult? Is it depending on what library using? If you're using Selenium, you may use one library as opposed to. I know Postman, I don't just have something built in for mock servers.

Yeah, Postman have a built in option. It is very simple, Joe. It's very simple. It sits in a fraction of seconds. I can just create it. So it is very simple. And sometimes I use Moki Moki IO as well. So it is also a very handy tool. So these tools, Postman and Mocky IO is what we use it for. Handy.

So if you're using Slim, are you able to use Postman in the same workflow like you said you were saying, use APIs to do data population. Is there any way they talk to one another? Once again, I'm just talking out of.

No, do not happen with my case. No, no, it happened. Happened.

But do you see that as a use case? Maybe if someone's using slim, they can use like a library that calls an API, creates the data for them before it starts doing its functional tests. Probably might be a good use case.

Yeah, I think there can be. I don't know how they are integrating. I believe mostly that's why they are switching on to rest assured like if they wanted to integrate, I believe so.

Postman. A lot of people love it. You seem to really enjoy it. Why do you like it so much? Is it because it's easy or because it has a lot of different functionality that you need?

Okay, first thing, Joe, When I started, I KNEW Nothing about APIs, right? So that was a tool which helped me to learn. Okay, so this is a request, this is a body, this is where you are going to provide your authorization. So it made me, it was like a companion for me. Right. So that's how I started loving that tool. It's not just I have an official, like a kind of collaboration with them. I'm not boasting about it. It happened in 2019. It really happened. Just because the tool made me comfortable towards API testing, I started loving API testing. Right. So even today, people who are actually trying to switch from manual to automation and they have a kind of compulsion to learn API testing, I suggest them to start with Postman. I'm not marketing. I'll tell them, like, start with Postman and then just try to understand how do you build a request? Because that gives you a pictorial or visual imagination kind of thing. Like, because APIs are kind of invisible guys, right? So, but this tool will give you look and feel about that. So once you get a look and feel about APIs and you know all these terminologies, then you can learn whatever tool, whatever framework based on your project requirements.

So, yeah, I love this goes in your whole philosophy of don't be a tool snob, use the tool, learn it, and then you can take those skills that you learned and transfer it to other skills. It's not like you're going to be locked in to Postman. It's just you're saying, use it to learn and then take what you've learned and apply it to another tool. And that learning will apply to anything. So you actually aren't just focusing on a tool, you're just using that tool to learn a skill that you then can apply to multiple tools? That's what it sounds like.

Exactly. Yeah.

Awesome. Love it. Okay, Priscilla, before we go, is there one piece of actual advice you can give to someone to help them with their API automation testing efforts or Postman efforts or whatever? And what's the best way to find or contact you?

Okay, my LinkedIn. I'll share it. I'm probably very active and if they want to talk with me. Also, Joe, most of my weekends I'm spending for mentoring sessions, they can book a call. I don't know if you ask me why I'm doing this, I don't have an answer. But I love but I love doing this. I don't know other than my vacation times, most of my weekends are always open so they can book a call and I would love to help them.

How they book a call with you? Is it through LinkedIn?

They just contact you and I have a calendar.

Okay.

I have tagged in there in my mentoring profile as such so they can book it.

Awesome. And Priscilla, one piece of actual advice that someone listening to this can put into place right away. You already gave a bunch of actionable advice, but is there one thing you think if someone did right away after hearing this they would learn or be able to pick up API testing better or whatever?

One thing is we have lot of people of course like you. You are effortlessly like selflessly helping people creating all these podcasts and there are many people outside who are helping through communities and all those things. Even though there are lot of platforms and lot of knowledge available, it is actually you to get started. Like once you decide like I have to learn this and I have to make a progress, of course you are going to do that. So that is how mentoring is going to help you Joe. Because I used to keep an eye on my mentees, I used to ask them monthly ones that hey, what happened? You said you are about to start a blogging, is that done? So I used to maybe find a mentor, keep your learning on track. And I believe this is the common advice too like get out of your comfort zone. And as testers, the technology advancements are really growing so of course we have to run along with that. So be open to anything and just don't judge anyone. So I believe right now I'm just kidding, only these things.

Thanks again for your automation awesomeness. The links to everything of value we covered in this episode, head on over to test guild.com a402 and while you're there, make sure to click on the Try for Free Today link under the exclusive sponsor section to learn all about Sauce Labs awesome products and services. And if the show has helped you in any way, why not rate it and review it in itunes? Reviews really help in the rankings of the show and I read each and every one of them. So that's it for this episode of the Test Guild Automation Podcast. I'm Joe. My mission is to help you succeed with creating end to end full stack automation awesomeness. As always, test everything and keep the good. Cheers.

Thanks for listening to the Test Guild Automation Podcast head on over to testguild.com for full show notes, amazing blog articles, and online testing conferences. Don't forget to subscribe to the Guild to continue.