This is Part 4 of our automation series. Read Part 1 to understand of how to get started with automation, part 2 for insight into reducing the flakiness of your automated tests, part 3 to learn about CI for automation testing.

There are various terminologies and jargon thrown around testing, some of them are actually not even directly related to testing. However if you have read our previous post you realize we try to explain complex concepts using really simple language and funny diagrams. It is an active choice that we made when we first started discussing the blog series. These small choices have a resounding impact when executed perfectly.

There are many levels of testing, and we would dedicate the next few posts in discussing those, as we cannot combine all levels of testing in one post.

The smallest level of automation testing that a full-stack tester should know is API automation testing. APIs have slowly become the backbone of various products and services. At PayPay we are powered by these REST APIs of different micro-services working in unison.

Skeleton of the AUT

Since most of the applications, be it web or mobile, are powered by REST APIs, it is a good strategy to have your tests targeting them. Your tests should emulate the same behavior as your AUT (Application Under Test) when making the requests to backend services.

Try to find out the sequence of these requests made by each screen, and categorize your tests based on either screen or a user scenario. Asking your front end developer friend to share the API specification or architecture design diagram helps you to understand that. Once you have that then you can start creating your tests based on the same sequence of requests as that of your AUT.

For example, if your AUT has a login screen, then find out all the APIs and their sequence of requests, for this case, maybe just a single API request for login with username and password as payload would be called.

API automation testing helps Paypay catch bugs at lower environments like Staging and Sandbox, at the same time it doubles as a monitoring system for Production. For the next level of testing will be covered in the next month’s post.