API Testing with Postman

Summary

This summary outlines the testing of the Urban Grocers API, focusing on:

Adding products to a kit.
Calculations for fast delivery.

A total of 57 tests were conducted: 28 for the first requirement and 29 for the second.

(👇 Full test case data sheet available 👇)

Google Sheets Test Case Data

Requirement 1: Adding Products to a Kit

CLICK IMAGE TO ENLARGE

Key Findings

Total Tests: 28
Parameters: Tested scenarios around the 30-item limit, invalid product IDs, and kit IDs.

Major Bugs

Verifying Body Response When Requesting An Excess of 30 Items

In addition to using Postman, I wrote JavaScript scripts and ran them through Node.js to manually test the same API scenarios. These scripts replicate the Postman tests, ensuring the Urban Grocers API correctly adheres to the 30-item limit for kits. You can view the scripts in my GitHub repository: Click here!

Exceeding 30 Items:

The API incorrectly allowed multiple quantities of the same product to be added to a kit, causing it to exceed the 30-item limit (expected HTTP 400, received HTTP 200).
Interestingly, when adding multiple different products, each with a single quantity, to a kit that had under 30 items (causing it to exceed 30), the API behaved correctly & returned HTTP 400.

CLICK IMAGE TO ENLARGE

Bug Report in JIRA

CLICK IMAGE TO ENLARGE

Requesting Non-existent Product IDs

The system accepted non-existent product IDs (e.g., product ID 407 which does not exist) and responded with HTTP 200 OK instead of the expected HTTP 400 Bad Request.
This could lead to users believing they have successfully added a valid product to their kit when, in fact, the product does not exist in the system.

CLICK IMAGE TO ENLARGE

Bug Report in JIRA

CLICK IMAGE TO ENLARGE

Invalid Inputs

The system was tested with various invalid product IDs and kit IDs (e.g., using Latin letters, symbols, decimal points, non-Latin letters).

Requirement 2: Fast Delivery Calculations

Test Cases Overview

Total Tests: 29

Focus: Parameters for the fast delivery method.

Detailed Requirements PDF

Test Scenarios

Valid Middle-Ground Input: Tested the system with valid, middle-range parameters to ensure basic functionality.

Minimal Product Weight and Middle Values for Other Parameters: Ensured the system accepted orders with minimal weight and middle-range product counts and delivery times.

Minimal Product Weight and Count: Verified that the client delivery cost remained $0 for orders with minimal weight and product count within limits.

Product Weight Exceeding Maximum Limit:

Scenario: Tested fast delivery with product count within limits but weight slightly over the limit (6.01 kg).

Expected: Host delivery cost $6, client delivery cost $9.

Observed: Client delivery cost was incorrectly charged $6 instead of $9.

Bug: The system failed to apply the excess client delivery cost correctly when the product weight exceeded the maximum limit.

Product Count Exceeding Maximum Limit:

Scenario: Tested fast delivery with weight within limits but product count slightly over the limit.

Expected: Host delivery cost $6, client delivery cost $9.

Observed: Client delivery cost was incorrectly charged $6 instead of $9.

Bug: The system failed to apply the excess client delivery cost correctly when the product count exceeded the maximum limit.

Inconclusive Tests

Two tests were deemed inconclusive, pointing to a significant flaw in the design of the API's cost calculation system.
These tests highlighted a gap in the defined ranges for host delivery cost:

Ordering Fast Delivery with Product Weight Slightly Below the Upper Limit (2.59 kg).

Results

CLICK IMAGE TO ENLARGE

Major Flaw in Design:

The current requirements have a gap between the $3 price range (0-2.5 kg) and the $6 price range (2.6-6 kg). This ambiguity creates uncertainty in expected outcomes for product weights that fall within this gap (e.g., 2.51 kg and 2.59 kg).

Conclusion

Overall, the system demonstrated significant issues with both the 30-item limit for kits and incorrect handling of delivery cost calculations. The bugs identified indicate areas where the API's functionality and validation mechanisms need to be strengthened.