What skills does a team need to succeed with API testing?
Let’s start with what I think is the most obvious one. Testing skills. I’ve said this before, but API testing is, well, testing. You need to approach it with all the same skills and mindset you would approach any testing task.
I think you also need someone who understand or can learn some good API testing tools. Effective API testing often involves diving deep into the API and the better you understand tools that can help you do that, the more effective you will be in your testing.
Creating a valuable API, also means you need someone who deeply understands the business or customer need for this API. The vast majority of API bugs I find are related to the API not providing the information the business needs, or providing it in ways that are difficult to find, use or understand. This does fall under general testing skills, but it is worth mentioning again as it is vitally important that APIs actually do what the business needs out of them. Sometime we can forget that when we are deep into something technical like an API, but we (should) only write these to help drive the value we are after. If they aren’t doing that, they need to be changed.
On last thing I will mention here is security. Security is important everywhere in the software development process, but I think it is especially important in APIs. If I were trying to break into a site or service, I would start with the APIs. They are designed to be scripted, which means you can use a lot of algorithmic and brute force attacks to try and break into them. You definitely don’t want to forget about security and authorization when testing an API.
There are so many tools out there for testing APIs, that it can be overwhelming. I use a few different tools, depending on what I’m trying to do. One thing that can be difficult in API testing is figuring out what routes are available in your API. This is especially true if the API is poorly documented or does not including any self-documentation.
There are a number of different tools out there that will help you discover what calls your API is making, but do you want to know what my favorite tool is for this?
The developer console.
Yup, that’s right. The developer console. There are tools like Wireshark or feature built into tools like Postman that let you ‘watch’ network traffic and figure out API calls from there, but I find that often the API calls are right there in the network tab of your console. It can be quick and easy way to get the info you need to get you started.
Today’s challenge involves reading and sharing a blog post. I read a lot of blogs and I find it to be a great way to learn and stay current with thoughts in the industry. I’ll actually share a couple of posts. The first one is more of a reference. The Web API Checklist gives a lot of useful things to think about when testing and API and is a great reference
Another great resource, if you are getting started with API testing is Katrina Clokie’s API Testing Pathway. She gives you a lot of guidance on this without specifying everything you do. I’ve found this to be a great resource and would highly recommend it to anyone interested in learning more about API testing.
What blog post or resources have stood out to you?
Today’s challenge involves sharing publicly available APIs that you can use for testing. In putting together recent courses on API testing I have spent a bit of time looking for APIs like this. The Ministry of Testing Club has a thread on sites you can use for practicing testing which was very helpful to me. There is also another thread on the MoT Club that directly asks about useful real world APIs to test against. If you are looking to practice API testing those are great places to start.
There are a lot of good resources for practice in testing GET calls, but it is a lot harder to find ways to test POST, PUT or DELETE calls. This is of course understandable, as those calls change things in the application, meaning it is hard to keep the application consistent for each user.
In recognition of this, I have tried to create some API Testing Challenges that can be used to learn testing. So far they are pretty basic and just at the starting stage, but if you want to try them out, you can go ahead and get them on Github here. They are pretty rough at this point, but feel free to use them if you want. Feedback is always appreciated as well of course!
Testing is something that it hard to learn without doing it, so I would encourage you to follow up on some of these resources. Try to ‘test’ some of the sample APIs out there and see how much you grow as a tester!
API as a term has become synonymous with client server interactions over the internet. As such APIs use the HTTP protocol to communicate. HTTP stands for HyperText Transfer Protocol, and interestingly, when you think of API calls (things like GET, POST and PUT), they are just directly using commands built into HTTP. These commands are not something that are defined in some API standard outside of the protocol. They are actually part of the protocol itself. This article gives a nice summary of HTTP at a high level.
If you want to dive a bit deeper into the detail of this, you can follow along with this tutorial. If you are testing APIs, it is probably a good idea to grasp at a basic level how HTTP works. Honestly, if you are testing anything client/server based on the web it is probably a good idea to have a basic understanding of this stuff. I must confess that I really hadn’t read much on HTTP before. I’m thankful for this challenge that pushed me to do this!
Today’s challenge is to begin reading an API testing book and share something from it by the end of the month.
I’ve downloaded this book to my kindle. It looks like it is more about building an API than testing one, but I’m thinking that learning how to build a good API is a good step in learning how to test one.
I will share a review once I have complete the book
I recently wrote an article about how API testing is exploratory, so I won’t spend too much time on this one, but I do want to re-iterate that all testing involves exploration.
When I approach any new testing task (including API testing), I start with exploration. How else are you supposed to figure out what to do? My approach to this in an API is similar to any other area I might be exploring. I start with some piece of information I know (perhaps an API end point) and do something with it (GET the request) and then look at the results of that and see if there is anything interesting or that seems to be out of place. I then follow up on that, making notes along the way, until that line of inquiry has died down.
I will talk to developers and other testers and consult documentation to try and find new starting points and follow them down various branches as they seem interesting, occasionally circling back as I learn more about the application. I take streaks of learning and keep expanding on them as needed until I am satisfied that I have a reasonable understanding of the state of the feature and can articulate it to those that need to know about it.
I use tools along the way of course. Things like Postman and Python and Curl and developer tools in the browser. Anything really that will help me answer the questions I’m curious about and give me insights into other things that might interesting. The tool set might differ in API testing, but the principles are the same. Follow your curiosity. Pay attention to what is happening. Ask lots of questions. Make notes. Grow your mental map. Try new things. In a word, Explore!
Ministry of Testing has another 30 days of testing challenge, this time around API testing. Looks like fun, and I’ve been doing a lot of API testing lately, so I’ll follow along and see how many of them I can do over the next month.
The first one on the list is to define what API testing is. I actually see two distinct parts to API testing. In one case you could consider it to be testing of APIs themselves, but in another case you could look at it as testing an application or service using the APIs.
I tend to think of API testing in the second sense, although of course there is overlap between the two. To me, API testing is about using the API to help you discover useful information about the product. That might sometimes be finding actual bugs in the API, but often it can mean using the API to drive testing of other things, or finding issues in the way different parts of the service work together.
Not a formal definition, but that’s the way I think about it. How do you approach it?