30 Days of API Testing Challenge

I listen to a lot of podcasts (coding and testing related mostly) in my spare time and while listening to Ministry of Testing podcast I heard about these 30 day testing challenges they have. 

I decided to got with the 30 days of API testing challenge first as the topic of API's interests me greatly - in terms of both professional and personal curiosity. 

Day 1

Found a definition of API testing: “API testing involves testing the application programming interfaces (APIs) directly and as part of integration testing to determine if they meet expectations for functionality, reliability, performance, and security.”

Day 2

For API exploratory testing I'd use Postman, the course I started on it seems like a good idea now.

Day 3

I started reading a book on API testing, by Alan Richardson, the dude behind the Evil Tester podcast, the name ain't "good" but the content is! 😀

Day 4

I really like the MDN's explanation of HTTP protocol, so here it is: MDN - An Overview of HTTP

Day 5

Here's a few publicly available API's that can be used for learning purposes.

Day 6

Today I read an interesting blog post with 10 tips for API testing, here it is.

Day 7

Made a GET and POST request, yea I'm an expert! 😆

Day 8

Checked out the API forum thread over at MoT and kept reading the book about API's I started a few days ago.

Day 9

To discover the API calls our app is making we can use tools such as Fiddler.

Day 10

My favorite API testing tools are Postman and Fiddler, because they're pretty intuitive and easy to use.

Day 11

There are several different types of API

Day 12

For a team to succeed in API testing they need:

• Good overall testing skills
• Programming knowledge
• Database knowledge
• Use of tools like Postman, Swagger, Fiddler SoapUI, etc.

Day 13

Some of the tools (I used only Postman, thus far) that can be used for API automation are:

1. SoapUI
2. Katalon Studio
3. Postman
4. Tricentis Tosca
5. Apigee
6. JMeter (mostly used for load testing, though)
7. Rest-Assured
8. Assertible
9. Karate DSL

Day 14

• Mock: an object on which you set expectations
• Stub: Similar to mock, but it doesn't provide the ability to verify that the method has been called.
• Fake: a class the implements an interface, but has no fixed data or logic.

Day 15

Today I tried a new API tool, a Chrome extension: Talend API Tester - Free Edition.

Day 16

Started writing little API tests, in Postman, using JavaScript.

Day 17

I found 5 API testing experts on Twitter to follow:

1. @GregPaskal
2. @AutomationSbS
3. @ptrthomas
4. @mittsh
5. @honzajavorek

Day 18

A bit on HTTP headers:

• authority : the host/domain or the request
• method : POST method.
• path : relative path of content.
• accept : certain media types which are acceptable for the response.
• accept-encoding: similar to accept, but restricts the content-codings that are acceptable in the response
• accept-language : set of natural languages that are preferred as a response to the request
• content-length : the size of the entity-body, in decimal number of OCTETs, sent to the recipient or, in the case of the HEAD method, the size of the entity-body that would
• have been sent, had the request been a GET
• content-type : indicates the media type of the entity-body sent to the recipient
• cookie : contains a name/value pair of information stored for that URL
• user-agent : contains information about the user agent originating the request
• Form Data - timings: The responded time from API(millisecond)

Day 19

I found an useful video on exploratory API testing for response validation, on one of my favorite Youtube channels.

Day 20

Thus far, I've used Fiddler, Postman, Chrome DevTools and Visual Studio for API testing, the reasons are twofold, API testing helps me at work and I enjoy learning about it, it's much more interesting to me than UI testing.

Day 21

Completed the exercise by chaining API calls in Postman, used this site for practicing.

Day 22

My biggest frustration with API testing is that I don't know everything about it! 😆

Day 23

My favorite resource for understating status codes is this one - HTTP Cats

Day 24

The best API bug I've found wasn't a bug at all, I forgot to add the authorization in Postman and I kept wondering why the browser client and Postman client returned two different responses... Yea I'm that smart! 🤪

Day 25

Today I read about security testing of APIs.

Day 26

I showed a co-worked some of the stuff I do in Postman and in turn he showed me how to use an internal (Swagger based) API resource.

Day 27

For someone just getting started with API testing I'd recommend the following Medium article.

Day 28

API performance testing can be done with tools like JMeter, I read an interesting article about it today.

Day 29

I use Chrome Dev Tool practically every day while testing, here's how to get started.

Day 30

Completed exercise four using Postman, I plan to return to it in order to experiment some more. Signing up for a trial of API Fortress as bonus.

If you want to take this particular challenge you can find the checklist here. 

In case you get stuck on something, or have anything to share, the forum community is very friendly.

At the time of this writing I'm taking the 30 Days Of Automation In Testing challenge. If you'd like to join in on this learning journey, I tweet about my progress (almost) daily and keep track of it on GitHub in a tiny weeny markdown file.

Thanks for stopping by!