Jason Ioannides, API Testing: From Entry Level to a PhD in 40 mins

What an amazing webinar! Today I watched an Association of Software Testing (AST), API Testing: From Entry Level to a PhD in 40 mins with Jason Ioannides. With a name like that, I expected to get a lot of information, but not the level that I actually received!

About the Webinar

From the Webinar Site:

"Have you seen a recent job posting for a Tester or QA Engineer? The majority of job descriptions have some requirement for API Testing experience. That’s how important and in-demand the skills are for testing (let alone automating) an API. What do you do if this is all new to you? What about if you have some experience but are looking to level up? Look no further.

"Jason Ioannides from API Fortress will quickly walk through the basics of what an API is, and then dive into what parts of an API can break, some real world examples, and a list of good practices to add to your checklist. This talk is for everyone from beginners to the more advanced user of Postman/SoapUI/REST-Assured". - API Testing

API Testing: From Entry Level to a PhD in 40mins

https://youtu.be/KfQ95yLi58Y


The webinar was moderated by Chris Kenst who started taking questions from the internet audience and, ah, I kinda got carried away.

Excellent work, @ckenst, moderating the @AST_News webinar, “API Testing from Entry Level to PhD” with Jason Ioannides from @apifortress. Very insightful! Sorry for bombarding you with 20-30 questions. I, ah, seem to do that a lot. https://t.co/UcurGo2EtS via @YouTube

— T.J. Maher (@tjmaher1) November 6, 2018

Chris is a volunteer BBST Instructor with the Association for Software Testing(AST), a co-instructor of BBST with Kaner, Fiedler & Associates. (Find out what Chris Kenst is doing now).

About the Speaker

"Jason Ioannides is a native of Brooklyn, and the solution engineer at API Fortress. He is a trained Node and Python developer that graduated from George Washington University. He loves both his dog named Taco, and the food".

Notes on the Webinar

The talk was amazing, giving you a good foundation on what an API is, from the ground level working you all the way up.

For those who don't know, an API is an Application Programming Interface, a content delivery method that focuses on moving data from one place to another, from a database to a microservice. APIs expose the business logic of an app to the outside world... Stuff such as user data, where you can access the the data without needing to get under the hood.


Data can come in many forms:

1. REST/JSON api: JSON is Javascript Object Notation
2. XML/ SOAP: XML: Extensible Markup Language
3. Plaintext
4. GraphQL: Still JSON but Jason thought it was still worth mentioning

"GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. GraphQL provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need and nothing more, makes it easier to evolve APIs over time, and enables powerful developer tools" - GraphQL.org
What are the benefits of REST?

• Browser clients are more supportive of REST, which now makes up 70% of the API environments out there. REST APIs are often more performative, allowing you to serialize and deserialize without taxing the browser.

What is serialization and deserialization in REST?

From Stack Overflow: "JSON is a format that encodes objects in a string. Serialization means to convert an object into that string, and deserialization is its inverse operation.

"When transmitting data or storing them in a file, the data are required to be byte strings, but complex objects are seldom in this format. Serialization can convert these complex objects into byte strings for such use. After the byte strings are transmitted, the receiver will have to recover the original object from the byte string. This is known as deserialization.

"Say, you have an object

{foo: [1, 4, 7, 10], bar: "baz"}

"serializing into JSON will convert it into a string:

'{"foo":[1,4,7,10],"bar":"baz"}'

which can be stored or sent through wire to anywhere. The receiver can then deserialize this string to get back the original object.

 {foo: [1, 4, 7, 10], bar: "baz"}.

What are the benefits of SOAP?

• Less required coding in the application layer for security, trust.
• Greater transaction reliablity (ACID complience)
• Simpler across frameworks or proxies without modifications to the protocol itself. 

"In computer science, ACID (Atomicity, Consistency, Isolation, Durability) is a set of properties of database transactions intended to guarantee validity even in the event of errors, power failures, etc. In the context of databases, a sequence of database operations that satisfies the ACID properties (and these can be perceived as a single logical operation on the data) is called a transaction. For example, a transfer of funds from one bank account to another, even involving multiple changes such as debiting one account and crediting another, is a single transaction" . - Wikipedia

What happens in an API when it is accessed?

• Requests go from a Client to a Server. Transffered via HTTP, Hypertext protocol.
• Once the Client request gets to the server, the server issues a query to the database along with user credentials.
• The database then passes information back to the server, a response, to the client.

When Things Go Wrong

Jason went through 4 test cases about what API testing can detect.

Rules for API testing:

1. Keep it DRY. Don't repeat yourself. Parameterize data wherever you can. Makes the test more flexible, increasing the work to be leveraged by other teams

2. Make your intensions clear. How am I going to remember what the test is for? How will teammates know what is being tested if you are not available? We don't want to have to redo work. Collaboration has problems when code is not properly documented.

3. Act like the consumer would. Not just the customer... the consumer may be another microservice. Stop creating test cases in a vacuum. Use real user data whenever possible. It is more than just pinging an API and seeing things get returned back.

Many APIs exist in the scope of a system. If a microservice passes data into an API, pass a feed into the API. Simualate the user workflows to find the holes.

4. Eliminate Static Data sources. Data that exists for the purpose of the test. Use live data whenever possible. Cloned instances of databases. If live data is unavailble, use mock responses that match your expected responses. Write a mock server such as Jango for Python. Express for NodeJS.

Thank you, Jason for an excellent presentation!


Happy Testing!

-T.J. Maher
Sr. QA Engineer, Software Engineer in Test
Meetup Organizer, Ministry of Testing - Boston

Twitter | YouTube | LinkedIn | Articles