API Testing

Question 1

What is an API?

Answer 1

API ⇒ Application Programming Interface.

API is the middle layer that is between the application User Interface and Database.

API handles data transfer between UI to Database and vice versa.

Question 2

What are the differences between REST and SOAP?

Answer 2

SOAP ⇒ Simple Object Access Protocol.
* Only works with XML.
* Only has 1 HTTP method as ‘POST’.
* WSDL (web services description language) provides detailed information about the SOAP services.
* Envelope structure. (message to server)
* UDDI registry.

REST ⇒ REpresentational State Transfer.
* Accepts multiple data transfer methods: GET, POST, PUT, PATCH, DELETE.
* Faster performance.
* More flexible.
* Set of architectural guidelines.

Question 3

What is the difference between an API and a Webservice?

Answer 3

All Webservices are API’s that use the internet. (using HTTP protocol)

There are API’s that do not use the internet and they are just called API’s.

Example of API that does not use the internet:
The Windows API is a collection of functions and routines that allow software applications to interact with the Windows operating system. It doesn’t rely on internet connectivity and is used for various tasks such as file operations, user interface interactions, and system management.

Question 4

What do you validate when you are testing an API?

Answer 4

1. HTTP Status code
2. Response Body Validation
3. Schema Validation

Question 5

What are tools that can be used to perform API testing?

Answer 5

Manual:
* Postman
* Ready API
* SoapUI

Automation:
* Rest Assured library

Question 6

What are the key differences between API and UI testing?

Answer 6

When we test the User interface of the application we can clearly see whether our test has passed or failed since User interface is visible.

API requests will travel to the server, the server will process the request, however the result of the request can only been seen within the API response body.

Question 7

Can you automate API testing, if so how?

Answer 7

There are many libraries that allow API automation testing.

I began automating API’s using POSTMAN with JavaScript. Currently, I am using REST Assured library with JAVA to automate API’s.

Question 8

What is URI?

Answer 8

URI ⇒ Uniform Resource Identifier — is a sequence of characters that distinguishes one resource from another. In the API it is the endpoint that is considered URI.

Question 9

What are the REST API HTTP methods you are familiar with?

Answer 9

• GET ⇒ retrieve data from server,
• POST ⇒ create/insert/provide data to server,
• PUT ⇒ update based on a parameter,
• PATCH ⇒ update or create a new row if it does not exist,
• DELETE ⇒ remove the resource.

Question 10

What is meant by Client and Server?

Can you provide a basic flow of an API Request/Response?

Answer 10

Client ⇒ Any device that submits the triggers the API requests.
Server ⇒ A server that process API requests.

|

• Step 1: Gather details of API from the documentation.
• Step 2: Create the API request call.
• Step 3: Trigger the API call.
• Step 4: Server reviews and Provides API response.
• Step 5: Perform validations for your API.

Question 11

What are the main differences between XML and JSON?

Answer 11

XML ⇒ Bulky uses tag based structure, more secure, lower performance.
JSON ⇒ Data structure, faster performance, lower security.

Question 12

What is HTTP protocol?
What is HTTPS protocol?

Answer 12

HTTP ⇒ HyperText Transfer Protocol.
HTTPS ⇒ HyperText Transfer Protocol Secured.

Question 13

What are request Headers?
Can you provide an example?
Are Headers always required?

Answer 13

Headers provide extra information to the server in order to process the request.

Content-type ⇒ Application/Json
Authorization ⇒ Token

Depends on the configuration of the API whether headers are mandatory or not.

Question 14

If you had to make a REST request what is the information you need?

Answer 14

• Endpoint / URI
• What Method using ⇒ POST,GET, PUT, PATCH, DELETE
• Headers ⇒ ask what headers are needed.
• Request Body ⇒ ask if you need a request body.
• Authorization ⇒ if it is provided in API

Question 15

Can you explain how this Web service works?

Answer 15

A web service typically works:

• Service Definition: The provider defines the functionalities and interfaces of the web service, including the methods that can be invoked and the data formats for communication.
• Service Publication: The provider publishes the web service on a network, making it accessible to clients. This is usually done by deploying the web service to a server or a cloud platform.
• Client Access: Clients access the web service using its endpoint URL and a description document such as a WSDL (Web Services Description Language) file. Clients can be written in any programming language and can run on different platforms.
• Request-Response Cycle: Clients make requests to the web service by sending HTTP requests (typically POST or GET) with XML or JSON payloads containing the necessary data. The web service processes the request, performs the required actions, and sends back an HTTP response with the result data.
• Data Exchange: The communication between clients and the web service usually involves exchanging data in a standardized format such as XML or JSON. This allows different systems to understand and interpret the exchanged data consistently.
• Error Handling: The web service handles errors and exceptions gracefully by returning appropriate HTTP status codes (e.g., 200 for success, 400 for bad request, 500 for internal server error) and error messages in the response payload. Clients can parse the response and take appropriate action based on the status code and error message.

Question 16

What should I expect if the Webservice is successful vs. unsuccessful?

Answer 16

When a Webservice call is Successful, you can expect:

• A response with an appropriate HTTP status code (e.g., 200 OK).
• The requested data or action result in the response payload.
• Consistent and well-structured data format (XML, JSON) that conforms to the service’s specifications.

When a Webservice call is UNsuccessful, you can expect:

• An HTTP status code indicating the type of error (e.g., 400 Bad Request, 500 Internal Server Error).
• An error message or description in the response payload explaining the cause of the error.
• Possible reasons for failure include invalid input data, authentication/authorization issues, server-side errors, or network connectivity problems.

RESUME: Overall, successful web service interactions should result in the desired outcome as specified by the service’s functionality, while unsuccessful interactions should provide meaningful error information to help diagnose and resolve issues.

Question 17

What are the different ways API requirements are communicated to you?

Answer 17

• Option 1: Acceptance Criteria.
• Option 2: Tools like Swagger.
• Option 3: Traditional Documentation.
• Option 4: Talk to developers.

Question 18

What are the parameters you have heard of with REST Webservices?

Answer 18

1. QUERY / REQUEST PARAMETERS ⇒ is not part of URL and passed in key+value format those parameters must be defined by API developer:
   http://34.223.219.142:1212/ords/hr/employees?limit=100
2. PATH PARAMETERS ⇒ is a part of URL and followed by the end of full resource url:
   http://34.223.219.142:1212/ords/hr/employees/100

Question 19

What is your step by step process to testing a REST Webservice ?

Answer 19

Step 1: I will review the API requirments in documentation to get familiar with the API’s details and understand its purpose within in the application.

Step 2: I will plan Test Cases based on reviewing the Acceptance Criteria.

Step 3: I document my Test Cases in my test management tool JIRA X-Ray.

Step 4: I create all my API tests in POSTMAN and execute them from my collection.

Step 5: For each API test case I check and verify the following:
* Data accuracy: I check the request and response body whether those are as written on API documentation in terms of data type and data structure.
* HTTP status code: For example, creating a resource should return 201 CREATED and unpermitted requests should return 403 FORBIDDEN, etc.
* Response headers: HTTP server headers have implications on both security and performance.
* Response body: Check valid JSON body and correct field names, types, and values - including in error responses.
* Authorization checks: Check authentication and authorization.
* Error messages: Check the error code coverage in case API returns any error.
* Response time: Implementation of response timeout.

Step 6: If there are any bugs I will work with my development team on ensuring timely fixes.

Question 20

How do you test REST API?

Answer 20

I also do a Positive and Negative testing of API.

Steps for Positive testing:
* Sending valid request parameters,
* Sending valid headers,
* Sending valid request JSON body,
* … and Verify that response status code IS EQUAL 200 - Successful and JSON response body data is also matching the expected data.

Steps for Negative testing:
* Sending invalid request parameters,
* or Sending invalid headers,
* or Sending invalid request JSON body,
* … and Verify that response status code IS NOT a 200 - Successful and JSON response body data contains ERROR message.

Question 21

Have you heard of JSON Path?

Answer 21

JSON Path is a query language that allows you to navigate and query JSON (JavaScript Object Notation) data structures.

Question 22

What is the Objective of API testing?

Answer 22

ANSWER #1:
API testing involves APIs directly and checks whether the API meets expectations in terms of functionality, reliability, performance, and security of an application. My first concern is functional testing which ensures that the API functions correctly.

|

ANSWER #2:
The main objectives in functional testing of the API are:
* To ensure that the implementation is working correctly as expected - no bugs!
* To ensure that the implementation is working as specified according to API documentation.
* To prevent bugs between code merges and releases.

Question 23

What is the difference between API Authorization and Authentication?

Answer 23

Authentication - is the process of verifying the identity of a user, system, or entity.

Authorization - is the process of determining what actions or resources a user, system, or entity is allowed to access or perform after successful authentication.

Question 24

What type of API Authentication / Authorization security protocols are you familiar with?

Answer 24

Yes, I am familiar with the following:

1. Basic auth - Basic Authentication is a simple authentication scheme built into the HTTP protocol. It is a widely used method for securing APIs and web services. Basic Authentication involves sending a username and password in the HTTP request header to authenticate a user or client.
2. API Key - are unique tokens issued to clients for authentication. Clients include the API key in the request header.
3. Bearer Token - is a type of access token that is used in the OAuth 2.0 authentication framework to allow a client to access a protected resource on behalf of a resource owner (typically a user). Bearer tokens are called “bearer” because the token bearer (the client) can present the token to the resource server and obtain access.
4. OAuth 2.0 - is a token-based authentication protocol that allows third-party applications to access resources on behalf of a user.

Question 25

Have you faced any challenges doing API testing?

Answer 25

1. Authentication and Authorization:
   Challenge: Testing APIs that require authentication (e.g., OAuth, API keys) and verifying proper authorization for different user roles can be complex.
   Solution: Implementing automated tests that handle authentication and authorization scenarios, and using testing tools that support these authentication methods.
   |
2. Dynamic Data:
   Challenge: APIs often deal with dynamic data, such as timestamps or unique identifiers, making it challenging to create stable and repeatable tests.
   Solution: Use techniques like parameterization, data-driven testing, or generating dynamic test data to handle variations in API responses.
   |
3. Handling State:
   Challenge: APIs may be stateless, requiring proper handling of state-related information to execute certain workflows successfully.
   Solution: Develop test cases that handle state management or use setup and teardown procedures to create and reset necessary data.
   |
4. Documentation Accuracy: Challenge: Incomplete or inaccurate API documentation can lead to misunderstandings and incorrect test implementations. Solution: Collaborate with developers to ensure accurate and up- to-date API documentation. Consider automated tools to generate documentation from API specifications.
   |
5. Error Handling:
   Challenge: Ensuring that the API returns meaningful error responses and that the client can handle these errors appropriately.
   Solution: Develop test cases to validate error responses for different scenarios, such as invalid input or authentication failure.