Learn about JSON, XML format, HTTP methods, the requests, responses, how to handle the error … (because I don’t know about API so it will take a lot of efforts)
Get the basic knowledge about tools for API testing such as Postman, Katalon …
Define test case and apply API testing for a sample API testing project such as load testing to check the performance on the website
I think the approachment for API Exploratory Testing is based on many aspects, one of that is Software Development Life Cycle (SDLC). Different SDLCs have different approaches. For example:
In traditional Waterfall/V-model: The testers collect requirement, apply the testing technique to generate Test Cases/Test Scripts. After the program is completed its Built Stage, they execute the Test Suite and collect the results.
In Agile, the Test Ideas are not mainly come from reading Requirement, but also from exploring the working software. More cases are tested, and so more results are gotten. The testers will have more knowledge about the product, so they can explore it better, generate better Test Cases/Test Scripts.
In DevOps culture, the SDLCs can be shorter than in Agile model (for faster delivery, better stability, etc…) and also more challenges. The testers will need CI/CD documents, explore the whole system (not just only the product), so they can generate even better Test Suite that covers more and costs less. They will have more time to understand the system, or learn new thing. Combining API Testing with other skill sets/knowledge will bring more positive change to the product.
Thank all for sharing. I’m a automation tester and not familiar with API testing as well as exploratory testing. After researching about exploratory testing and reading some of your opinions, I found my own approach as below:
Read/ Explore the documentation if it is available and try to understand
Ask around for what the intended uses are and what applications we know of are currently using our API
Review the code for the API or go over the API with the developer if possible
Know the endpoint, and what are the operations it supports
Compare responses with their requests
Experiment with different variations of params to see the API behaviour.
Identify example messages from typical user journeys to derive variations of those journeys (e.g in/valid tokens).
Checking if the API will justify the purpose for which it was developed after being integrated with the Application.
Document the complete testing process so that it can be referred by the developers and can be used in future for testing
Exploratory testing is simultaneous learning, test design, and test execution
(Exploratory Testing Explained by James Bach, v.1.3)
Exploratory testing is more like an approach or mindset than a methodology, it’s the way to understand product/features deeply and widely with the purpose of finding bugs through investigation and learning freedom based on tester’s skill, experience and adaptability.
In my opinion, via seeking and reading about API Exploratory Testing, I think it is use automation tools to test APIs within Exploratory approach. Besides, because API is almost automated test, it assists about reproduction and regression what’s tested, which is a difficult when applying exploratory in manual testing.
I’m a newbie in API testing. After researching about exploratory testing an API on the Internet as well as referring your comments. I would like to share my own apinion about API exploratory testing approach as below:
Prerequisite:
Know the different between web service and API.
Know types web service likes SOAP/ REST.
The format of the API request/response ( XML, JSON,…)
What is a HTTP API request/response.
Is there a documentation of each service? How it works? What business function service perform?
When it comes to exploratory testing, there are some misconceptions that ET (Exploratory testing) is only used with GUI testing and intended for Devs;even some are surprised when ET is mentioned in API. Below is my approach for API ET after reading some articles related:
Before jumping to write API testcases, do the following preparation steps underneath: 1. Try to get familiar with API concepts:
HTTP => used to transfer web based information
Servers and Clients, Requests and Responses
Creating HTTP methods (get, put, post,delete,…)
How data (input/output) is formed in requests/responses (XML (Extensible Markup Language) and the more recent JSON (JavaScript Object Notation))
Status codes: are divided into 5 classes
1xx (Informational): The request is received and continues to be processed
2xx (Successful): The request is successfully received, understood, and accepted
3xx (Redirection): Further action needs to be taken to complete the request
4xx (Client Error): The request contains the wrong syntax or cannot be fulfilled
5xx (Server Error): The server fails to fulfill an apparently valid request
Authorization (who can access the API?)
Endpoints
Pick up an automation tool that u find most comfortable to practice
2. To do API testing:
Read API docs carefully before writing API testcases
Pick up a few scenarios to write API testcases(not too complicated)
Determine inputs, outputs, responses
Organize your endpoints
Choose suitable verification methods:
Compare the whole response body content with the expected information
I am new to this terminology so I did some research on Google and come up with this.
Exploratory testing is a systematic approach for discovering risks using rigorous analysis techniques coupled with testing heuristics. A lot of times we test before there’s a graphical user interface or finalized features available, and exploring is the mindset that helps us uncover things we do not know.
Let us assume for 1 minute that we are not so lucky to actually have a documentation for the API, no swagger, no collegues who did the implementation no nothing. Well if this is the case they the fun really starts because we must get creative
For me the process would be the following
Filter the calls to the the backend - Since the API has to be used by the current application that I am testing if I review carefully the requests made to the backend after a few tries I may find a pattern. I may be able to see that specific URL ( endpoint) that is appearing over and over
Write down all of the enpoints found
Differenciate betwenn the different verb available per enpoint ( GET, PUT, POST, DELETE etc)
Playing with GET
Try all different kinds of parameters ( no parameters, a lot of parameters that make no sense, the parameters that you can see in the request, there is no limit, be creative)
Definetly check and note down the errors codes
Write down in RED the requests that generate a response starting with 5 ( 500 is always nice )
Playing with POST and PUT
Here the body is the most import
You need to find out what the standard body is for the request
Once that is known sending variations of that body is key ( different values for the parameters, no all parameters, no parameters)
Besides writing the response from you requsts you need to make sure that the Operation was performed succesfully. You can check the update either in the UI or via a GET Request
Playing with DELETE
Be very carefull where you delete item from ( one request and the data is gone)
You need to find out what the standard body is for the request
Besides writing the response from you requsts you need to make sure that the Operation was performed succesfully. You can check the update either in the UI or via a GET Request
Once you know now some enpoints and how to use them you can check if they work the same also on different systems ( if there are any)
Depending on the authorization of the API you can try to see if you can go around it. Different users, different API, using expired tokens. This all depends on context
Last but not least is performance. You have now several enpoints and you are not afraid to use them so you make a few thousand requests per minute ( think Black Friday sale) and see how the API and the application react.
For me it is always fun to do exploratory testing. The less you know the more you can find out. It is not always easy but in the end it is always fun.