In this post we will talk about different type of test scenarios and validation check points need to be considered while testing APIs.
In overall API testing is quite different as compared to Functional Testing. The main objectives in functional testing of the API are:
to ensure that the implemented functionality is working as expected with no deviation i.e., defects
to ensure that the implemented functionality is working as specified according to the requirements.
API test cases may differ in case-to-case basis based on your requirement and application functionality. However, some of the API test cases could be subset of your Functional test cases.
Here is a series of generic test scenarios you should considered for writing test cases for API testing ,I have categorized them for better understanding.
Test Scenarios
Positive Tests (happy path flows).
Execute API call with valid required parameters
Execute API call with valid required parameters AND valid optional parameters.
Boundary value testing.
Extended positive testing with optional parameters.
Negative testing with valid input (that attempts illegal operations).
Attempting to create a resource with a name that already exists.
Attempting to delete a resource that doesn’t exist.
Attempting to update a resource with illegal valid data.
Negative testing with invalid input
Missing or invalid authorization token.
Missing required parameters.
Invalid value for endpoint parameters
Invalid values in HTTP headers.
Unsupported methods for endpoints.
Malformed content in request.
Wrong content-type in payload.
Overflow parameter values i.e., Validate the keys with the Min. and Max range.
Overflow payload – huge JSON in request body.
Empty payloads.
Illegal characters in parameters or payload.
Using incorrect HTTP headers.
Security Test
Authentication
Authorization - ensure API responds to correct authorization and refuses unauthorized ones.
Permission tests
Field Level Access.
Resource Level Access.
API should refuse calls to endpoints which are not permitted for user’s role.
Schema Validation
Verify the Field Type.
Verify the Mandatory Fields.
Compare Field length between Source and Target.
Performance
Check API response time, latency etc. in isolation and under load
Load Tests (positive), Stress Tests (negative).
Find capacity limit points and ensure the system performs as expected under load, and fails gracefully under stress.
Usability Tests
Now let see what kind of validation checkpoints one should consider while designing the test cases which will help you to mark test case execution result as Pass or Fail. I have categorized it in positive and negative cases.
Validation Checkpoints
Positive
Request should return 2XX HTTP status code.
200 OK for GET requests.
201 for POST or PUT requests creating a new resource.
200, 202, or 204 for a DELETE operation.
Response is a well-formed JSON object
Response structure is according to data model (schema validation: field names and field types are as expected, non-nullable fields are not null, etc.)
For GET requests, verify there is NO STATE CHANGE in the system (idempotence).
For POST, DELETE, PATCH, PUT operations
Performing appropriate GET request and inspecting response.
Refreshing the UI in the web application and verifying new state.
Verify that HTTP headers are as expected, including content-type, connection,cache-control, expires, access-control-allow-origin, keep-alive, HSTS and other standard header fields – according to spec.
Response is received in a timely manner (within reasonable expected time) as defined in the test plan.
Negative
Verify that an erroneous HTTP status code is sent (NOT 2XX).
Verify that the HTTP status code is in accordance with error case as defined in spec.
Verify that there is a clear, descriptive error message/description field
Ensure error is received in a timely manner (within reasonable expected time).
In next blog, I will provide insight into What Test Approach, Best practices and Tool set should be considered for API Testing.
Komen