Any commerce business model usually involves selling and returns of items/products; where-in a customer walks into a Brick-to-Mortar store, looks for a product of their choice, proceeds to the billing counter and the Point of Sale process completes. A similar procedure is followed for returns also: customer walks into the Point-of-Sale (also known as the store) and the counter handles the return of the sale along with the payment return processing after receiving the product.

Electronic implementation of this model is commonly referred to as ‘E-Commerce’; this involves every aspect of the Brick-to-Mortar store functionality to be handled by an electronic counter-part system. Some of the common areas are: A website or mobile app replacing the store experience, electronic payment gateway(s) replacing the Point of Sale consoles and shipping options like Postal Service, FedEx, etc., working on product deliveries; similar methods handle returns also by returning products back to the warehouse(s).

The entire functionality of an e-commerce system is validated by End-to-End Testing Cycle i.e., every possible order and return combination is tested. End-to-end Testing is of the utmost priority since any deviation from the expected behavior would have a direct business impact. Thus, the design of End-to-End test-case(s) would require utmost priority and knowledge of all functional units and integrations of the application under test.

Let`s look at a couple of simple End-to-End test-case(s) for better understanding.

An Order Placement End-to-End Test case would look like:

“A Guest User orders for Shipping Restricted Product to California which is shipped via Overnight Priority Shipping and is paid using Amex Credit Card”

An Order Return End-to-End Test case would look like:

“A Registered user returns order due to incorrect fit for an order placed for product shipped to home at Connecticut via Express 2-Day Shipping and is paid using Proprietary Payment Card”

The above are very simple and straight forward End-to-End test case(s); some of the variables involved in constructing End-to-End test-cases are:

  1. Customer Types – Guest and Registered.
  2. Product Types – Shipping Restriction, CA65 Compliance and Drop Ship.
  3. Order Types – Gifted, Ship-to-Home and Pickup In-Store
  4. Proprietary Payment Methods used by the Store/Site.
  5. Shipping Methods like Overnight, Express and Standard.
  6. Tax and Address Validations.
  7. Order Return Reasons.

An effective End-to-End test suite should include all possible combinations of product types, customer and order types available along with address and tax validations. End-to-End Testing would focus on areas like how data flows across the various systems involved in the cycle, various integrations involved and working in-sync with the order creation process (Taxation and Address Validation systems) and the syntax and correctness of the data.

Things to consider when writing end to end test cases in DW Automation

Two of the major order fulfillment types are:

  1. Ship to Home: This is the traditional method where the ordered products are shipped using the available shipping options to the Shipping Address mentioned by the Customer.
  2. Pick up in Store: In this order fulfillment type, the customer selects the product and completes the payment; but the product is not shipped rather it is picked up by the customer from the store selected by the customer earlier.

Two of the most important integrations involved in Order Placement are:

  1. Address Validation: This integration would work actively work with validating the Shipping Address entered by the customer during Order Creation process which would prevent Order Fulfillment issues in later stages of the Order Life-cycle.
  2. Tax Validation: This integration would work with Tax calculation by a third-party integration based on the Shipping Address provided by the Customer. This integration would fetch the tax amount of an order based on items purchased and shipping address from an external system.

End-to-End Testing involves validating all the data and transmission points to verify that the data is syntactically and semantically correct i.e., the structure of the data being transmitted across the systems and the data being transmitted across the systems should remain consistent. The basic validation would involve verifying that all the above order details remain consistent through-out the Order life-cycle till Order Fulfillment i.e., Values should remain consistent and should be verified in the backend system for correctness.

Order XML File which is imported from processing the backend system should be verified for details syntax and data and finally the data being processed in the Order Management System till Fulfillment or Cancellation. The Order XML File is the only medium by which the order details transmit from the backend system to the Order management System; thus a vital area of testing would involve validation of the XML File versus the backend system.

End-to-End testing would require extensive order placement(s) and cover every possible product type, shipping method, type, payment method, customer and order type. This would require extensive manual effort and since it is a known permutation of variables for the test-suite Automation Solutions would provide a cost-effective and shorter End-to-End Test Cycles in combination with Continuous Integrations.

Govind Sripada

Govind Sripada

Retail Test specialist at Aspire Systems
Govind Sripada is an ecommerce Retail Test specialist at Aspire Systems. Primarily focused on Retail domain, his area of interest would revolve around E-Commerce (B2C and B2B), Web based: System and Integration testing and back end integration and validation.
Govind Sripada