test_cases (table) Content
| TC-0012 | GRP-003 | Verify that the response for System & Dashboard is of integer type. | Verify that the response for System & Dashboard is of integer type. | arun-ramanan@netspective.in | 15-12-2024 | Manual | 2024-12-15 | ["cycle-count"] | High | --- FII: TC-0012 groupId: GRP-003 title: Verify that the response for System & Dashboard is of integer type. created_by: "arun-ramanan@netspective.in" created_at: "2024-12-15" test_type: "Manual" tags: ["cycle-count"] priority: "High" --- | ### Description This test case checks the API response to ensure that the values for "System" and "Dashboard" are returned as integer values. The API should return the expected response structure, with "valueInteger" containing integer values. ### Pre-Conditions: - The `/dashboard` API endpoint is operational and accessible. - Authentication (if required) is provided, and the request can be successfully executed. - The API response contains the `extension` field with the expected data structure. ### Test Steps: 1. **Step 1**: Send a GET request to `/dashboard` API endpoint. 2. **Step 2**: Review the JSON response from the server response to ensure the fields for System and Dashboard are of integer value. ### Expected Result: - The response body contains the proper value. | Dashboard Test Cases | SUT-003 | Group of test cases designed to validate the integration capabilities of Dashboard, focusing on data ingestion, processing integrity, and reporting functionalities to ensure compliance and performance standards are met. | arun-ramanan@netspective.in | 2024-11-01 | ["integration testing","data validation","reporting"] | passed | |
| TC-0005 | GRP-003 | Verify that the dashboard Count field is present inside the Response Data. | Verify that the dashboard Count field is present inside the Response Data. | arun-ramanan@netspective.in | 15-12-2024 | Manual | 2024-12-15 | ["cycle-count"] | High | --- FII: TC-0005 groupId: GRP-003 title: Verify that the dashboard Count field is present inside the Response Data. created_by: "arun-ramanan@netspective.in" created_at: "2024-12-15" test_type: "Manual" tags: ["cycle-count"] priority: "High" --- | ### Description This test case verifies that the API endpoint `/dashboard` returns the correct response data, specifically ensuring that the `Daily_Cycle_Count` field is present in the JSON response. ### Pre-Conditions: - The API endpoint `/dashboard` is accessible. - The API server is running and available to respond to GET requests. - Proper authentication, if required, is provided for the request. ### Test Steps: 1. **Step 1**: Send a GET request to the `/dashboard` API endpoint. 2. **Step 2**: Check the response to verify that the `Dashboard_Count_Url` is present in the `extension` section of the returned JSON data. 3. **Step 3**: Ensure that the corresponding value of `valueInteger` is 3 under the `Dashboard_Count_Url`. ### Expected Result: - If the cycle count is available, the API should return a `200` status code with the following JSON data: | Dashboard Test Cases | SUT-003 | Group of test cases designed to validate the integration capabilities of Dashboard, focusing on data ingestion, processing integrity, and reporting functionalities to ensure compliance and performance standards are met. | arun-ramanan@netspective.in | 2024-11-01 | ["integration testing","data validation","reporting"] | passed | |
| TC-0007 | GRP-003 | Verify that if the System Count field in the response is not an integer and contains special characters, decimals, or leading zeros, it should throw an error. | Verify that if the System Count field in the response is not an integer and contains special characters, decimals, or leading zeros, it should throw an error. | arun-ramanan@netspective.in | 15-12-2024 | Automation | 2024-12-15 | ["cycle-count"] | High | --- FII: TC-0007 groupId: GRP-003 title: Verify that if the System Count field in the response is not an integer and contains special characters, decimals, or leading zeros, it should throw an error. created_by: "arun-ramanan@netspective.in" created_at: "2024-12-15" test_type: "Automation" tags: ["cycle-count"] priority: "High" --- | ### Description This test case is designed to verify the behavior of the API when the "System_count" field in the response is provided with non-integer values, such as special characters, decimals, or leading zeros. The API should throw a 400 Bad Request error when the field contains invalid data. ### Pre-Conditions: - The API endpoint `/dashboard` should be functional. - The API should be accessible and return a valid JSON response. ### Test Steps: 1. **Step 1**: Send a GET request to `/dashboard` API endpoint. 2. **Step 2**: Review the JSON response from the server that the "valueInteger" field under the "System_count_Url" extension contains a value that is not an integer (e.g., contains special characters, decimals, or leading zeros). ### Expected Result: - The response should contain a 400 Bad Request status code. - An error message should be provided indicating that the "System_count" value is invalid. | Dashboard Test Cases | SUT-003 | Group of test cases designed to validate the integration capabilities of Dashboard, focusing on data ingestion, processing integrity, and reporting functionalities to ensure compliance and performance standards are met. | arun-ramanan@netspective.in | 2024-11-01 | ["integration testing","data validation","reporting"] | failed | |
| TC-0009 | GRP-003 | Verify that the System Count in the response is greater than 0. | Verify that the System Count in the response is greater than 0. | arun-ramanan@netspective.in | 15-12-2024 | Automation | 2024-12-15 | ["cycle-count"] | High | --- FII: TC-0009 groupId: GRP-003 title: Verify that the System Count in the response is greater than 0. created_by: "arun-ramanan@netspective.in" created_at: "2024-12-15" test_type: "Automation" tags: ["cycle-count"] priority: "High" --- | ### Description This test case ensures that the API response for the `/dashboard` endpoint includes a valid `System_Count` value that is greater than 0. The test will confirm that the value in the response is correctly populated. ### Pre-Conditions: - The `/dashboard` API endpoint is operational and accessible. - Authentication (if required) is provided, and the request can be successfully executed. - The API response contains the `extension` field with the expected data structure. ### Test Steps: 1. **Step 1**: Send a GET request to `/dashboard` API endpoint. 2. **Step 2**: Review the JSON response from the server response contains the `extension` field, which should include a `Daily_Cycle_Count_Url` entry and the `valueInteger` should be greater than 0. ### Expected Result: - The value of `valueInteger` should be greater than 0 (in this example, `2`). | Dashboard Test Cases | SUT-003 | Group of test cases designed to validate the integration capabilities of Dashboard, focusing on data ingestion, processing integrity, and reporting functionalities to ensure compliance and performance standards are met. | arun-ramanan@netspective.in | 2024-11-01 | ["integration testing","data validation","reporting"] | passed | |
| TC-0010 | GRP-003 | Verify that the Dashboard Count in the response is greater than 0. | Verify that the Dashboard Count in the response is greater than 0. | arun-ramanan@netspective.in | 15-12-2024 | Manual | 2024-12-15 | ["cycle-count"] | High | --- FII: TC-0010 groupId: GRP-003 title: Verify that the Dashboard Count in the response is greater than 0. created_by: "arun-ramanan@netspective.in" created_at: "2024-12-15" test_type: "Manual" tags: ["cycle-count"] priority: "High" --- | ### Description This test case ensures that the API response for the `/dashboard` endpoint includes a valid `Dashboard_Count` value that is greater than 0. The test will confirm that the value in the response is correctly populated. ### Pre-Conditions: - The `/dashboard` API endpoint is operational and accessible. - Authentication (if required) is provided, and the request can be successfully executed. - The API response contains the `extension` field with the expected data structure. ### Test Steps: 1. **Step 1**: Send a GET request to `/dashboard` API endpoint. 2. **Step 2**: Review the JSON response from the server response contains the `extension` field, which should include a `Lifetime_Cycle_Count_Url` entry and the `valueInteger` should be greater than 0. ### Expected Result: - The value of `valueInteger` should be greater than 0 (in this example, `2`). | Dashboard Test Cases | SUT-003 | Group of test cases designed to validate the integration capabilities of Dashboard, focusing on data ingestion, processing integrity, and reporting functionalities to ensure compliance and performance standards are met. | arun-ramanan@netspective.in | 2024-11-01 | ["integration testing","data validation","reporting"] | passed | |
| TC-0011 | GRP-003 | Verify that the Dashboard Count is always greater than or equal to the System Count. | Verify that the Dashboard Count is always greater than or equal to the System Count. | arun-ramanan@netspective.in | 15-12-2024 | Automation | 2024-12-15 | ["cycle-count"] | High | --- FII: TC-0011 groupId: GRP-003 title: Verify that the Dashboard Count is always greater than or equal to the System Count. created_by: "arun-ramanan@netspective.in" created_at: "2024-12-15" test_type: "Automation" tags: ["cycle-count"] priority: "High" --- | ### Description This test verifies that the Dashboard Count, which represents the total number of cycle counts done up to the current date, is always greater than or equal to the System Count, except for the first time. ### Pre-Conditions: - The `/dashboard` API endpoint is operational and accessible. - Authentication (if required) is provided, and the request can be successfully executed. - The API response contains the `extension` field with the expected data structure. ### Test Steps: 1. **Step 1**: Send a GET request to `/dashboard` API endpoint. 2. **Step 2**: Review the JSON response from the server response contains the `extension` field, which should include a `System_Count_Url` and `Dashboard_Count_Url` value. ### Expected Result: - The response body contains the proper structure: | Dashboard Test Cases | SUT-003 | Group of test cases designed to validate the integration capabilities of Dashboard, focusing on data ingestion, processing integrity, and reporting functionalities to ensure compliance and performance standards are met. | arun-ramanan@netspective.in | 2024-11-01 | ["integration testing","data validation","reporting"] | passed | |
| TC-0006 | GRP-003 | Verify that the Dashboard Count field is present inside the Response Data when sending a GET request to the /dashboard endpoint. | Verify that the Dashboard Count field is present inside the Response Data when sending a GET request to the /dashboard endpoint. | arun-ramanan@netspective.in | 15-12-2024 | Automation | 2024-12-15 | ["cycle-count"] | High | --- FII: TC-0006 groupId: GRP-003 title: Verify that the Dashboard Count field is present inside the Response Data when sending a GET request to the /dashboard endpoint. created_by: "arun-ramanan@netspective.in" created_at: "2024-12-15" test_type: "Automation" tags: ["cycle-count"] priority: "High" --- | ### Description This test case ensures that the API endpoint /dashboard returns the Dashboard Count field as part of the response data. The field should be present inside the extension array, with a valid value of type integer. ### Pre-Conditions: - Ensure that the API is up and running and accessible. - The **/dashboard** endpoint should return a valid response with relevant data. ### Test Steps: 1. **Step 1**: Send a **GET** request to the `/dashboard` endpoint. 2. **Step 2**: Inspect the response to check if the **Dashboard Count** field is included inside the **extension** array in the returned JSON data. ### Expected Result: 1. If the **Dashboard Count** field is present, the response should have the following format: - Status Code: `200 OK` | Dashboard Test Cases | SUT-003 | Group of test cases designed to validate the integration capabilities of Dashboard, focusing on data ingestion, processing integrity, and reporting functionalities to ensure compliance and performance standards are met. | arun-ramanan@netspective.in | 2024-11-01 | ["integration testing","data validation","reporting"] | passed | |
| TC-0008 | GRP-003 | Verify that if the Dashboard Count field in the response is not an integer and contains special characters, decimals, or leading zeros, it should throw an error. | Verify that if the Dashboard Count field in the response is not an integer and contains special characters, decimals, or leading zeros, it should throw an error. | arun-ramanan@netspective.in | 15-12-2024 | Automation | 2024-12-15 | ["cycle-count"] | High | --- FII: TC-0008 groupId: GRP-003 title: Verify that if the Dashboard Count field in the response is not an integer and contains special characters, decimals, or leading zeros, it should throw an error. created_by: "arun-ramanan@netspective.in" created_at: "2024-12-15" test_type: "Automation" tags: ["cycle-count"] priority: "High" --- | ### Description This test case is designed to verify the behavior of the API when the "Dashboard Count" field in the response is provided with non-integer values, such as special characters, decimals, or leading zeros. The API should throw a 400 Bad Request error when the field contains invalid data. ### Pre-Conditions: - The API endpoint `/dashboard` should be functional. - The API should be accessible and return a valid JSON response. ### Test Steps: 1. **Step 1**: Send a GET request to `/dashboard` API endpoint. 2. **Step 2**: Review the JSON response from the server that the "valueInteger" field under the "Dashboard_Count_Url" extension contains a value that is not an integer (e.g., contains special characters, decimals, or leading zeros). ### Expected Result: - The response should contain a 400 Bad Request status code. - An error message should be provided indicating that the "Dashboard Count" value is invalid. | Dashboard Test Cases | SUT-003 | Group of test cases designed to validate the integration capabilities of Dashboard, focusing on data ingestion, processing integrity, and reporting functionalities to ensure compliance and performance standards are met. | arun-ramanan@netspective.in | 2024-11-01 | ["integration testing","data validation","reporting"] | passed | |
| TC-0002 | GRP-004 | Verify Missing "Username and Password" Blocks Login to API | Verify Missing "Username and Password" Blocks Login to API | arun-ramanan@netspective.in | 15-12-2024 | Automation | 2024-12-15 | ["login"] | High | --- FII: TC-0002 groupId: GRP-004 title: Verify Missing "Username and Password" Blocks Login to API created_by: "arun-ramanan@netspective.in" created_at: "2024-12-15" test_type: "Automation" tags: ["login"] priority: "High" --- | ### Description This test case verifies that the API does not allow login when "username" and "password" fields are missing in the request payload. ### Pre-Conditions: - The API is accessible. - The testing environment is set up. - The API endpoint for login is known. ### Test Steps: 1. **Step 1**: Send a POST request to the API login endpoint without including the "username" and "password" fields in the request body. - Example Request Body: ```json { "username": "", "password": "" } ``` 2. **Step 2**: Observe the response from the API after submitting the request. ### Expected Result: - The API should respond with a **400 Bad Request** or **401 Unauthorized** error, indicating that both "username" and "password" are required. - The response should contain a meaningful error message, such as: "Error: Missing 'username' and 'password' fields. Please provide valid credentials." | Login Test Cases | SUT-003 | Group of test cases designed to validate the integration capabilities of focusing on data ingestion, processing integrity, and reporting functionalities to ensure compliance and performance standards are met. | qa-lead@example.com | 2024-11-01 | ["integration testing","data validation","reporting"] | failed | |
| TC-0004 | GRP-004 | Verify Empty Payload Block Login to API | Verify Empty Payload Block Login to API | arun-ramanan@netspective.in | 15-12-2024 | Automation | 2024-12-15 | ["login"] | High | --- FII: TC-0004 groupId: GRP-004 title: Verify Empty Payload Block Login to API created_by: "arun-ramanan@netspective.in" created_at: "2024-12-15" test_type: "Automation" tags: ["login"] priority: "High" --- | ### Description This test case validates that the API rejects a login attempt with an empty payload. ### Pre-conditions: - The API is running and accessible. - User is not logged in. ### Test Steps 1. **Step 1**: Send a POST request to the API's login endpoint with an empty payload (`{}`). - **Request**: - URL: `https://localhost/api/login` - Method: POST - Payload: `{}` 2. **Step 2**: Verify the status code of the response. 3. **Step 3**: Check the response message for appropriate error handling (e.g., "Invalid input" or "Payload cannot be empty"). ### Expected Result - The response status code should be `400 Bad Request`. - The response body should contain an error message indicating that the payload is empty, such as `"error": "Payload cannot be empty"`. ### Actual Result | Login Test Cases | SUT-003 | Group of test cases designed to validate the integration capabilities of focusing on data ingestion, processing integrity, and reporting functionalities to ensure compliance and performance standards are met. | qa-lead@example.com | 2024-11-01 | ["integration testing","data validation","reporting"] | failed | |
| TC-0001 | GRP-004 | Verify Successful Login to the API | Verify Successful Login to the API | arun-ramanan@netspective.in | 15-12-2024 | Automation | 2024-12-15 | ["login"] | High | --- FII: TC-0001 groupId: GRP-004 title: Verify Successful Login to the API created_by: "arun-ramanan@netspective.in" created_at: "2024-12-15" test_type: "Automation" tags: ["login"] priority: "High" --- | ### Description To verify that a user can successfully log in to the API using valid credentials. ### Pre-Conditions: - The API is up and running. - The user has valid login credentials (username and password). - API authentication endpoint is accessible. ### Test Steps: 1. **Step 1**: Send a POST request to the login API endpoint with valid credentials (username and password). - **Endpoint**: `POST /api/login` - **Request Body**: ```json { "username": "validUser", "password": "validPassword123" } ``` 2. **Step 2**: Verify that the request returns a 200 HTTP status code indicating success. 3. **Step 3**: Verify that the response contains a valid authentication token in the response body. - The token should be a non-empty string. ### Expected Result: - **HTTP Status Code**: 200 OK - **Response Body**: - The response should contain a success message or an authentication token. - The authentication token should be in the correct format (e.g., JWT). - Example response: { "message": "Login successful", "token": "<token>" } | Login Test Cases | SUT-003 | Group of test cases designed to validate the integration capabilities of focusing on data ingestion, processing integrity, and reporting functionalities to ensure compliance and performance standards are met. | qa-lead@example.com | 2024-11-01 | ["integration testing","data validation","reporting"] | passed | |
| TC-0003 | GRP-004 | Verify if Missing "Password" Details Block Login to API | Verify if Missing "Password" Details Block Login to API | arun-ramanan@netspective.in | 15-12-2024 | Automation | 2024-12-15 | ["login"] | High | --- FII: TC-0003 groupId: GRP-004 title: Verify if Missing "Password" Details Block Login to API created_by: "arun-ramanan@netspective.in" created_at: "2024-12-15" test_type: "Automation" tags: ["login"] priority: "High" --- | ### Description This test case verifies that if the "password" detail is missing from the request, the API should block the login attempt. ### Pre-conditions: - The API is up and running. - The API endpoint for login is known and accessible. - Valid user credentials (username) are available. ### Test Steps: 1. **Step 1**: Send a login request to the API with the "username" field populated but the "password" field missing. - **Request**: - Method: POST - Endpoint: `/api/v1/login` - Body: `{ "username": "testuser", "password": "" }` 2. **Step 2**: Check if the login attempt is blocked, and an appropriate error message is returned (e.g., "Password is required"). ### Expected Result: - The API should reject the login attempt with an error response, indicating that the "password" field is required. - **Response**: - HTTP Status Code: `400 Bad Request` - Response Body: `{ "error": "Password is required" }` | Login Test Cases | SUT-003 | Group of test cases designed to validate the integration capabilities of focusing on data ingestion, processing integrity, and reporting functionalities to ensure compliance and performance standards are met. | qa-lead@example.com | 2024-11-01 | ["integration testing","data validation","reporting"] | passed | |
| TC-0015 | GRP-005 | Ensure that the `MRC result` field exists within the response data when a GET request is sent to the `/search` endpoint. | Ensure that the `MRC result` field exists within the response data when a GET request is sent to the `/search` endpoint. | arun-ramanan@netspective.in | 15-12-2024 | Automation | 2024-12-15 | ["wild-cycle"] | High | --- FII: TC-0015 groupId: GRP-005 title: "Ensure that the `MRC result` field exists within the response data when a GET request is sent to the `/search` endpoint." created_by: "arun-ramanan@netspective.in" created_at: "2024-12-15" test_type: "Automation" tags: ["wild-cycle"] priority: "High" --- | ### Description This test verifies that the `MRC result` is included in the response data returned by the `/search` endpoint. The test ensures the correct structure and expected values are returned, demonstrating successful execution and compliance with the API requirements. ### Pre-Conditions: - The `/search` API endpoint is operational and accessible. - Authentication (if required) is provided, and the request can be successfully executed. - The device has completed the wild cycle procedure, and relevant data is available in the system. ### Test Steps: 1. **Step 1**: Send a GET request to `/search` API endpoint. 2. **Step 2**: Review the JSON response from the server response data contains the `MRC result` object with the expected attributes. ### Expected Result: - The response data includes the proper structure. | Search API Test Cases | SUT-003 | Group of test cases designed to validate the integration capabilities of Search API, focusing on data ingestion, processing integrity, and reporting functionalities to ensure compliance and performance standards are met. | qa-lead@example.com | 2024-11-01 | ["integration testing","data validation","reporting"] | passed | |
| TC-0016 | GRP-005 | Ensure that the 'Result' field exists within the response data when a GET request is sent to the `/search` endpoint. | Ensure that the 'Result' field exists within the response data when a GET request is sent to the `/search` endpoint. | arun-ramanan@netspective.in | 15-12-2024 | Automation | 2024-12-15 | ["wild-cycle"] | High | --- FII: TC-0016 groupId: GRP-005 title: "Ensure that the 'Result' field exists within the response data when a GET request is sent to the `/search` endpoint." created_by: "arun-ramanan@netspective.in" created_at: "2024-12-15" test_type: "Automation" tags: ["wild-cycle"] priority: "High" --- | ### Description This test verifies that the 'Result' is included in the response data returned by the `/search` endpoint. The test ensures the correct structure and expected values are returned, demonstrating successful execution and compliance with the API requirements. ### Pre-Conditions: - The `/search` API endpoint is operational and accessible. - Authentication (if required) is provided, and the request can be successfully executed. - The device has completed the wild cycle procedure, and relevant data is available in the system. ### Test Steps: 1. **Step 1**: Send a GET request to `/search` API endpoint. 2. **Step 2**: Review the JSON response from the server response data contains the 'Result' field exists within the response data. ### Expected Result: - The response data includes the proper structure. | Search API Test Cases | SUT-003 | Group of test cases designed to validate the integration capabilities of Search API, focusing on data ingestion, processing integrity, and reporting functionalities to ensure compliance and performance standards are met. | qa-lead@example.com | 2024-11-01 | ["integration testing","data validation","reporting"] | passed | |
| TC-0013 | GRP-005 | Ensure that the information retrieved for the search listing. | Ensure that the information retrieved for the search listing. | arun-ramanan@netspective.in | 15-12-2024 | Manual | 2024-12-15 | ["wild-cycle"] | High | --- FII: TC-0013 groupId: GRP-005 title: "Ensure that the information retrieved for the search listing." created_by: "arun-ramanan@netspective.in" created_at: "2024-12-15" test_type: "Manual" tags: ["wild-cycle"] priority: "High" --- | ### Description This test case verifies the accuracy and completeness of the information retrieved from the `/search`. The objective is to ensure that the data returned for the last procedure cycle is consistent, up-to-date, and complete, including all relevant details about the procedures performed, device information, and the status of each procedure. ### Pre-Conditions: - The `/search` API endpoint is operational and accessible. - Authentication (if required) is provided, and the request can be successfully executed. - The device has completed the search API procedure, and relevant data is available in the system. ### Test Steps: 1. **Step 1**: Send a GET request to `/search` API endpoint. 2. **Step 2**: Review the JSON response from the server response should include a JSON object with a "resourceType" of "Bundle," containing an array of entries with relevant details about each procedure performed. The procedures should have accurate "performedDateTime," "outcome," "status," and associated references. ### Expected Result: - The response should contain a "Bundle" resource with "Procedure" entries showing the completed procedures, accurate "performedDateTime" and "outcome" data. - No missing or incorrect data for any procedure performed. | Search API Test Cases | SUT-003 | Group of test cases designed to validate the integration capabilities of Search API, focusing on data ingestion, processing integrity, and reporting functionalities to ensure compliance and performance standards are met. | qa-lead@example.com | 2024-11-01 | ["integration testing","data validation","reporting"] | passed | |
| TC-0014 | GRP-005 | Ensure that the "Performed Date & Time" of the procedure is present in the response data. | Ensure that the "Performed Date & Time" of the procedure is present in the response data. | arun-ramanan@netspective.in | 15-12-2024 | Automation | 2024-12-15 | ["wild-cycle"] | High | --- FII: TC-0014 groupId: GRP-005 title: Ensure that the "Performed Date & Time" of the procedure is present in the response data. created_by: "arun-ramanan@netspective.in" created_at: "2024-12-15" test_type: "Automation" tags: ["wild-cycle"] priority: "High" --- | ### Description Verify that the API response contains the correct "Performed Date & Time" field when sending a GET request to the `/search` endpoint. ### Pre-Conditions: - The `/search` API endpoint is operational and accessible. - Authentication (if required) is provided, and the request can be successfully executed. - The device has completed the wild cycle procedure, and relevant data is available in the system. ### Test Steps: 1. **Step 1**: Send a GET request to `/search` API endpoint. 2. **Step 2**: Review the JSON response from the server response should include the "PerformedDateTime" field with the correct date and time. ### Expected Result: - The API response should include the "PerformedDateTime" field with the correct date and time in the following format: "PerformedDateTime" : "2015-02-07T13:28:17-05:00" | Search API Test Cases | SUT-003 | Group of test cases designed to validate the integration capabilities of Search API, focusing on data ingestion, processing integrity, and reporting functionalities to ensure compliance and performance standards are met. | qa-lead@example.com | 2024-11-01 | ["integration testing","data validation","reporting"] | passed | |
| TC-0025 | GRP-006 | Ensure that an appropriate error is returned when an incorrect API endpoint is provided. | Ensure that an appropriate error is returned when an incorrect API endpoint is provided. | arun-ramanan@netspective.in | 15-12-2024 | Automation | 2024-12-15 | ["integrity testing"] | High | --- FII: TC-0025 groupId: GRP-006 title: "Ensure that an appropriate error is returned when an incorrect API endpoint is provided." created_by: "arun-ramanan@netspective.in" created_at: "2024-12-15" test_type: "Automation" tags: ["integrity testing"] priority: "High" --- | ### Description This test verifies that the API responds with an error message and the appropriate HTTP status code when a request is made to an invalid or incorrect endpoint. ### Pre-Conditions: 1. API server is running and accessible. ### Test Steps: 1. **Step 1**: Send a GET request to an incorrect endpoint (e.g., `/logins`). 2. **Step 2**: Observe the response status code and verify it matches the expected error code (e.g., `404 Not Found`) and Confirm that the error message does not reveal sensitive server or API information. ### Expected Result: - The server responds with an HTTP status code of `404 Not Found`. - The response body includes an error message such as `{"error": "Endpoint not found"}`. - No sensitive server or API details are exposed in the error response. | Integrity Test Cases | SUT-004 | integration of APIs Validation and Testing | arun-ramanan@netspective.in | 2024-11-01 | ["Compatability testing"] | passed | |
| TC-0024 | GRP-006 | Verify if server connection is refused, it should throw an error. | Verify if server connection is refused, it should throw an error. | arun-ramanan@netspective.in | 15-12-2024 | Automation | 2024-12-15 | ["integrity testing"] | High | --- FII: TC-0024 groupId: GRP-006 title: "Verify if server connection is refused, it should throw an error." created_by: "arun-ramanan@netspective.in" created_at: "2024-12-15" test_type: "Automation" tags: ["integrity testing"] priority: "High" --- | ### Description This test case ensures that when the server connection is refused, the application or client properly handles the scenario by throwing an appropriate error message. ### Pre-Conditions: - The server endpoint should be temporarily set to reject connections (e.g., through firewall rules or server configurations). - Test environment with necessary tools (e.g., Postman or playwright scripts) must be configured. ### Test Steps: 1. **Step 1**: Send a request (GET/POST/PUT depending on the API) to the target endpoint. 2. **Step 2**: Capture the JSON response from the API. 3. **Step 3**: Compare the response body against the schema defined in the IG using a schema validation tool. 4. **Step 4**: Verify that all required fields are present and adhere to the expected data types and formats. ### Expected Result: - The response body conforms to the schema specified in the IG, including: - Required fields are present. - Data types and formats match schema definitions. - No additional or unexpected fields are included unless allowed by the schema. | Integrity Test Cases | SUT-004 | integration of APIs Validation and Testing | arun-ramanan@netspective.in | 2024-11-01 | ["Compatability testing"] | passed | |
| TC-0026 | GRP-008 | HTTPS-001 - Ensure the API Requires HTTPS for All Connections. | HTTPS-001 - Ensure the API Requires HTTPS for All Connections. | arun-ramanan@netspective.in | 15-12-2024 | Manual | 2024-12-15 | ["security testing"] | High | --- FII: TC-0026 groupId: GRP-008 title: "HTTPS-001 - Ensure the API Requires HTTPS for All Connections." created_by: "arun-ramanan@netspective.in" created_at: "2024-12-15" test_type: "Manual" tags: ["security testing"] priority: "High" --- | ### Description The API should enforce secure communication by requiring all client-server interactions to use HTTPS. This ensures that data exchanged between the client and server is encrypted, preventing interception or tampering by unauthorized parties. APIs that allow HTTP connections expose sensitive data, such as authentication credentials or personal information, to potential attackers. ### Pre-Conditions: - The API server must be accessible over both HTTP and HTTPS. - Testing tools such as Postman or cURL should be configured to make HTTP and HTTPS requests. - Ensure no network-level redirection is applied. ### Test Steps: 1. **Step 1**: Send an HTTP GET request to the API endpoint. 2. **Step 2**: Verify the server responds with a redirection (HTTP 301 or 308) to the HTTPS endpoint. 3. **Step 3**: Send an HTTPS GET request to the same endpoint. 4. **Step 4**: Verify the server responds with a 200 OK status code and the expected resource. 5. **Step 5**: Check if the response includes the Strict-Transport-Security (HSTS) header. ### Expected Result: - All HTTP requests are redirected to HTTPS with a 301 or 308 status code. - HTTPS requests successfully return the expected resource with a 200 OK status code. - The response includes a valid Strict-Transport-Security (HSTS) header. | Security Test Cases | SUT-006 | API Security Testing Execution Report - OWASP Compliance | arun-ramanan@netspective.in | 2024-11-01 | ["Compatability testing"] | ||
| TC-0023 | GRP-002 | PLN-002 | Ensure that the response body adheres to the schema defined in the Implementation Guide (IG) for the API endpoint. | Ensure that the response body adheres to the schema defined in the Implementation Guide (IG) for the API endpoint. | arun-ramanan@netspective.in | 15-12-2024 | Automation | 2024-12-15 | ["compliance testing"] | High | --- FII: TC-0023 groupId: GRP-002 projectId: PRJ-001 test_execution: EXE-002 planId: PLN-002 title: Ensure that the response body adheres to the schema defined in the Implementation Guide (IG) for the API endpoint. created_by: "arun-ramanan@netspective.in" created_at: "2024-12-15" test_type: "Automation" tags: ["compliance testing"] priority: "High" --- | ### Description This test verifies that the JSON response from the API matches the schema requirements outlined in the IG. Any deviations from the schema should be identified and flagged as errors. ### Pre-Conditions: - API endpoint is accessible and operational. - The expected response schema is defined in the IG. - A tool or script for schema validation (e.g., Postman, JSON Schema Validator) is available. ### Test Steps: 1. **Step 1**: Send a request (GET/POST/PUT depending on the API) to the target endpoint. 2. **Step 2**: Capture the JSON response from the API. 3. **Step 3**: Compare the response body against the schema defined in the IG using a schema validation tool. 4. **Step 4**: Verify that all required fields are present and adhere to the expected data types and formats. ### Expected Result: - The response body conforms to the schema specified in the IG, including: - Required fields are present. - Data types and formats match schema definitions. - No additional or unexpected fields are included unless allowed by the schema. | Compliance Test Cases | SUT-002 | Comprehensive FHIR Conformance Validation and Testing | arun-ramanan@netspective.in | 2024-11-01 | ["Compatability testing"] | passed |
| TC-0019 | GRP-007 | Verify that the API responds with a throughput of less than 10 seconds per transaction under defined load conditions. | Verify that the API responds with a throughput of less than 10 seconds per transaction under defined load conditions. | arun-ramanan@netspective.in | 15-12-2024 | Automation | 2024-12-15 | ["performance testing"] | High | --- FII: TC-0019 groupId: GRP-007 title: "Verify that the API responds with a throughput of less than 10 seconds per transaction under defined load conditions." created_by: "arun-ramanan@netspective.in" created_at: "2024-12-15" test_type: "Automation" tags: ["performance testing"] priority: "High" --- | ### Description This test measures the time taken by the API to process and respond to a transaction. The goal is to ensure the API meets performance standards by maintaining a response time of less than 10 seconds for each transaction under specified load scenarios. ### Pre-Conditions: - The server is online and reachable. - API endpoint is accessible and configured in the test environment. - Necessary performance testing tools are installed and configured. ### Test Steps: 1. **Step 1**: Send a request to the API endpoint. 2. **Step 2**: Verify the Record the response time for each transaction during the test execution and analyze the test results to calculate the average, median, and 95th percentile response times. ### Expected Result: - The API responds to each transaction with a throughput of less than 10 seconds under the defined load conditions. | Performance Test Cases | SUT-005 | API Performance Testing Plan for Single-User Interactions | arun-ramanan@netspective.in | 2024-11-01 | ["Compatability testing"] | ||
| TC-0018 | GRP-007 | Ensure that the API responds without any errors while fetching the complete response, maintaining an error rate of 0%. | Ensure that the API responds without any errors while fetching the complete response, maintaining an error rate of 0%. | arun-ramanan@netspective.in | 15-12-2024 | Automation | 2024-12-15 | ["performance testing"] | High | --- FII: TC-0018 groupId: GRP-007 title: "Ensure that the API responds without any errors while fetching the complete response, maintaining an error rate of 0%." created_by: "arun-ramanan@netspective.in" created_at: "2024-12-15" test_type: "Automation" tags: ["performance testing"] priority: "High" --- | ### Description This test verifies that the API operates without generating any errors during its operation under normal load conditions. The focus is to ensure stability and reliability by ensuring that the error rate remains zero throughout the transaction. ### Pre-Conditions: - The server is online and reachable. - API endpoint is accessible and configured in the test environment. - Necessary performance testing tools are installed and configured. ### Test Steps: 1. **Step 1**: Send a request to the API endpoint. 2. **Step 2**: Verify the Track the error rate using the Jmeter testing tool and Capture the results, including response time, throughput, and error rate. ### Expected Result: - The API should fetch responses successfully for all requests. - The error rate during the test should remain 0%. | Performance Test Cases | SUT-005 | API Performance Testing Plan for Single-User Interactions | arun-ramanan@netspective.in | 2024-11-01 | ["Compatability testing"] | ||
| TC-0020 | GRP-007 | Verify Endurance Test Response for a Specified Test Duration. | Verify Endurance Test Response for a Specified Test Duration. | arun-ramanan@netspective.in | 15-12-2024 | Automation | 2024-12-15 | ["performance testing"] | High | --- FII: TC-0020 groupId: GRP-007 title: Verify Endurance Test Response for a Specified Test Duration. created_by: "arun-ramanan@netspective.in" created_at: "2024-12-15" test_type: "Automation" tags: ["performance testing"] priority: "High" --- | ### Description The endurance test will validate the system's reliability, stability, and ability to handle prolonged usage without performance degradation, memory leaks, or resource exhaustion. ### Pre-Conditions: - The server is online and reachable. - API endpoint is accessible and configured in the test environment. - Necessary performance testing tools are installed and configured. ### Test Steps: 1. **Step 1**: Set up the performance test environment, ensuring all test prerequisites are met (e.g., hardware and software configurations). 2. **Step 2**: Configure the endurance test in the Jmeter performance testing tool and Specify the test duration (e.g., 8 hours)also set the expected load (e.g., number of concurrent users, transactions per second). 3. **Step 3**: Start the endurance test and monitor the system’s behavior throughout the specified duration and Capture and analyze key performance metrics, such as response time, throughput, memory usage, CPU utilization, and error rates. 4. **Step 4**: Compare the observed results with expected thresholds for response times and other performance metrics. ### Expected Result: - The system should maintain consistent response times within acceptable thresholds throughout the test duration. - No significant increase in error rates, memory leaks, or resource utilization (e.g., CPU, disk, and memory). - All transactions should be successfully completed without degradation in service quality. | Performance Test Cases | SUT-005 | API Performance Testing Plan for Single-User Interactions | arun-ramanan@netspective.in | 2024-11-01 | ["Compatability testing"] | ||
| TC-0017 | GRP-007 | Verify that the API responds within the benchmark time when communicating with the server. | Verify that the API responds within the benchmark time when communicating with the server. | arun-ramanan@netspective.in | 15-12-2024 | Automation | 2024-12-15 | ["performance testing"] | High | --- FII: TC-0017 groupId: GRP-007 title: "Verify that the API responds within the benchmark time when communicating with the server." created_by: "arun-ramanan@netspective.in" created_at: "2024-12-15" test_type: "Automation" tags: ["performance testing"] priority: "High" --- | ### Description This test case ensures that the API meets the performance benchmark by responding within the expected time when interacting with the server. It validates that the response time is consistent and does not exceed acceptable limits under specified conditions. ### Pre-Conditions: - The server is online and reachable. - API endpoint is accessible and configured in the test environment. - Benchmark response time is predefined (e.g., ≤ 500ms). - Necessary performance testing tools are installed and configured. ### Test Steps: 1. **Step 1**: Send a request to the API endpoint. 2. **Step 2**: Verify the response time for each request in the Jmeter testing tool. ### Expected Result: - The API responds within the benchmark time for all requests (e.g., ≤ 500ms). - No significant deviations or delays are observed across multiple iterations. | Performance Test Cases | SUT-005 | API Performance Testing Plan for Single-User Interactions | arun-ramanan@netspective.in | 2024-11-01 | ["Compatability testing"] | ||
| TC-0022 | GRP-001 | Verify that the API server is connected and running successfully on a Linux machine. | Verify that the API server is connected and running successfully on a Linux machine. | arun-ramanan@netspective.in | 15-12-2024 | Automation | 2024-12-15 | ["compatability testing"] | High | --- FII: TC-0022 groupId: GRP-001 title: "Verify that the API server is connected and running successfully on a Linux machine." created_by: "arun-ramanan@netspective.in" created_at: "2024-12-15" test_type: "Automation" tags: ["compatability testing"] priority: "High" --- | This test ensures that the API server can start, establish connections, and respond to API requests when hosted on a Linux machine. It validates basic server functionality and compatibility with the Linux environment. ### Pre-Conditions: - The Linux machine must have the required dependencies installed. - The API server code and configuration files must be deployed correctly. - The server's network settings must allow incoming and outgoing connections. ### Test Steps: 1. **Step 1**: Start the API server by connecting the tailscale connection. 2. **Step 2**: Open the automation script and send a GET request to the API endpoint. 3. **Step 3**: Review the API response for a valid status code (`200 OK`) and response body. ### Expected Result: - The API server starts without errors and logs indicate successful initialization. - The API response includes: - Status code: `200 OK` - Response body: Contains a valid JSON object or expected response content. | Compatability Test Cases | SUT-001 | Comprehensive Cross-Browser Testing for APIs | arun-ramanan@netspective.in | 2024-11-01 | ["Compatability testing"] | passed | |
| TC-0021 | GRP-001 | Ensure that the API endpoint is accessible under the Linux platform using Chrome, and Firefox browsers. | Ensure that the API endpoint is accessible under the Linux platform using Chrome, and Firefox browsers. | arun-ramanan@netspective.in | 15-12-2024 | Automation | 2024-12-15 | ["compatability testing"] | High | --- FII: TC-0021 groupId: GRP-001 title: Ensure that the API endpoint is accessible under the Linux platform using Chrome, and Firefox browsers. created_by: "arun-ramanan@netspective.in" created_at: "2024-12-15" test_type: "Automation" tags: ["compatability testing"] priority: "High" --- | ### Description This test verifies the accessibility of the all API endpoint from the Linux platform when accessed via different browsers (Chrome, Firefox, and Edge). The test ensures the endpoint responds correctly and consistently across all specified browsers. ### Pre-Conditions: - The Linux system is set up with Chrome, Firefox installed. - The test environment is configured, and the API endpoint is available. - Network connectivity is established. ### Test Steps: 1. **Step 1**: Launch the Chrome browser on the Linux system. 2. **Step 2**: Enter the URL for the all API endpoint and press Enter. 3. **Step 3**: Observe the response and validate it matches the expected output. 4. **Step 4**: Repeat steps 1-3 using Firefox browsers. ### Expected Result: - All API endpoint should return a valid JSON response in all browsers. | Compatability Test Cases | SUT-001 | Comprehensive Cross-Browser Testing for APIs | arun-ramanan@netspective.in | 2024-11-01 | ["Compatability testing"] | passed |
(Page 1 of 1)