Background
The following QA checklist is intended to be used on a typical e-commerce, B2C implementation of iPaaS.com, but should provide ideas for how to test other implementations (checklists for other use cases will be created in the future). The below list is not extensive but is meant to provide guidance on creating a comprehensive test plan for a company prior to go live in iPaaS.com.
This document was written with the following assumptions about the person or team conducting the testing:
They have completed iPaaS.com training.
They understand the customer’s requirements for how they will use iPaaS.com.
They have worked with e-commerce sites and tested integrations in the past.
They understand the integration’s capabilities and are familiar with the mapping collections.
This document will grow and change as more implementations are completed, so please check back for the most current version.
Overview & Notes
At a high level, you should be testing data flowing through each mapping collection to ensure it comes into iPaaS.com and flows out to the appropriate systems as intended.
A few notes on things to test for and be cognizant of:
Testing should include running both positive and negative tests for filters (i.e. data that will meet the criteria and data that will be excluded due to the criteria).
Ensure any data that is synced bi-directionally is tested carefully so that it only overrides the data you intend it to. Please note that the ability to do this is dependent on the integration.
Testing should include match functionality where needed (i.e. creating a customer with the same email address, creating a product with the same SKU, etc).
Make sure that linkages come through, for instance:
A category is assigned in one system should be assigned in another (i.e. customer, products, etc.)
A customer and/or company is linked to a transaction in one system is linked in another (if the integration and software support it).
When testing linkages, test for data that already exists and when it does not. For instance, test a transaction linked to a customer when the customer exists and when they do not already exist in a destination system.
For systems that allow you to interact as both a guest and logged-in, both states should be tested. For instance, on an e-commerce site, a test order should be placed in both a logged-out and logged-in state.
Delete mapping collections are not listed below, but they should be tested where applicable.
NOTE: Delete mappings and workflows are an important part of data hygiene and can cause issues if not properly implemented, especially when it comes to items like duplicate data.
Ensure data is transformed as expected via dynamic formulas and that you test enough data that you have confidence that it meets the requirements.
The below data types list is intended to be followed in the below order, but errors may cause you to revisit another section (i.e. you may need to come back and add a shipping method you did not notice was missing till you try to apply it on an order). This type of correction does not mean you need to retest everything else you have already confirmed.
Some items that should be tested that are not included below include:
Delete mappings
Product categories
Customer categories
Variant options
Data Models
As noted above, this list is intended to be followed in the order outlined to avoid as many dependency issues as possible.
Locations
Ensure all Locations are created (either manually or via initialization) and connected via external ID when applicable.
Note: If location groups are needed they should be created and have locations linked to them as well.
Payment Method
Ensure all Payment Methods are created (either manually or via initialization) and connected via external ID when applicable.
Shipping Method
Ensure all Shipping Methods are created (either manually or via initialization) and connected via external ID when applicable.
Products
Creation
Where: In the product source of truth system (typically the ERP, but might be the POS)
What: Create different products and ensure they flow to iPaaS.com and any destination systems. Products should have different:
Types (simple, variant, kit, etc)
Options (if needed)
Custom fields populated
Tax classification
Categories
Inventory levels in different locations
Confirmation
Ensure they appear as expected in iPaaS.com and in any destination systems.
Inventory is set correctly and the product is set to display based on inventory rules
The product has the correct categories
Custom fields are populated as intended
All fields are populated as intended
Variants are showing with the correct options
Repeat the above steps if multiple platforms support product add functionality.
Update
Where: In the product source of truth system (typically the ERP, but might be the POS)
What: Update different products and ensure they flow to iPaaS.com and any destination systems. Products should have different:
Types (simple, variant, kit, etc)
Variants
Add option, inclusive of inventory
Remove option
Custom fields populated
Tax classification (if needed)
Categories
Add
Remove
Inventory levels in different locations
Completely removing inventory
Updating a value that would result to show/hide product
Confirmation
Ensure they appear correctly in iPaaS.com and in any destination systems, inclusive of:
All fields in the product header
Inventory
Categories
Product displaying based on set rules
Custom fields
Repeat the above steps if multiple platforms support product update functionality.
Customer
Creation
Where: In the customer source of truth system. This may be an e-commerce platform, a CRM or other system.
What: Test the creation of a new customer in the source of truth platform and ensure it is created correctly in any destination platforms. Customers should have different:
Names
Email address
Linked to orders and not
Linked to other customers and companies and not (as needed)
Addresses that are set to primary billing and shipping addresses
Categories
Confirmation:
Ensure core customer details (name, email, etc) come through
Ensure customer is linked to an order (if it is setup to)
Ensure customer relationships are coming through as correct (as needed)
Ensure addresses come through with the correct primary shipping and/or billing designation
Ensure customer categories are set appropriately
Data is transformed as intended via dynamic formulas
Repeat the above steps if multiple platforms support customer add functionality.
Update
Where: In the customer source of truth system. This may be an e-commerce platform, a CRM or other system.
What: Test the update of an existing customer in the source of truth platform and ensure it is created correctly in any destination platforms. Test updating the following types of data:
Names
Email address
Linked to orders and not
Linked to other customers and companies (as needed)
Addresses that are set to primary billing and shipping addresses
Categories
Confirmation:
Ensure core customer details (name, email, etc) come through
Ensure customer is linked to an order (as needed)
Ensure customer relationships are coming through as correct (as needed)
Ensure addresses come through with the correct primary shipping and/or billing designation
Ensure customer categories are updated appropriately
Data is transformed as intended via dynamic formulas
Repeat the above steps if multiple platforms support customer update functionality.
Transactions
Create
Where: In the transaction source of truth system. This may be an e-commerce platform, an ERP or other system. Note that different transaction types (orders, tickets, etc) may have different source of truth systems.
What: Test the creation of a transaction in the source of truth platform and ensure it is created correctly in any destination platform. Test updating the following types of data:
Transaction header
Taxes: test transactions with various different taxes
Taxable order (test tax code and tax rule)
Non-taxable order (test tax code and tax rule)
Line Items
Line item discounts: test transactions with and without line item discounts
Gift card purchase
Purchasing mixed types of products on a single transaction
Discounts: test transactions with and without discounts
Payments: test transactions with each payment type, especially with gift cards (if applicable).
Test multiple payment types on a transaction (i.e. gift card and credit card on one transaction.
Test authorize and capture flows
When mapping or translating payment methods by name, test orders have been placed for each name in use and/or handling added for unmapped names.
Addresses
Notes: Test with and without notes
Related documents: test with and without them
Custom fields
Shipping method:
An order with each shipping method
A BOPIS order (if needed)
For each store where BOPIS is available
An order with some items shipping and some items as BOPIS
When mapping or translating shipping methods by name, test orders have been placed for each name in use and/or handling added for unmapped names.
Confirmation:
Ensure customer is linked to company and/or customer (if needed)
Ensure all values in the header are correct
Ensure all line items are correct and discounts are appropriately applied
Ensure gift card is created (if applicable)
Ensure payments are correctly applied
Ensure gift card balance is adjusted (if applicable)
Ensure addresses come through with the correct primary shipping and/or billing designation
Ensure notes come through correctly
Ensure related documents are coming through correctly
Ensure custom fields are coming through as intended.
Data is transformed as intended via dynamic formulas
Repeat the above steps if multiple platforms support transaction create functionality.
Update
Where: In the transaction source of truth system. This may be an e-commerce platform, an ERP or other system. Note that different transaction types (orders, tickets, etc) may have different source of truth systems.
Note: Not all customers or systems allow for full or partial updates to transactions.
What: Test the update of a transaction in the source of truth platform and ensure it is created correctly in any destination platform. Test updating the following types of data:
Transaction header: Ensure it updates when other data updates (i.e. if a line item is changed that the total is updated)
Taxes:
Taxable order (test tax code and tax rule)
Non-taxable order (test tax code and tax rule)
Line Items: add and remove line items
Line item discounts: add and remove line items with and without line item discounts
Add and remove a gift card purchase
Purchasing mixed types of products on a single transaction
Discounts: add and remove discounts
Payments:
Test authorize and capture flows based on transaction status updates
When mapping or translating payment methods by name, test orders have been placed for each name in use and/or handling added for unmapped names.
Transaction tracking: Add one or more tracking IDs to the transaction.
Test as part of a transaction update as well as independently when needed.
Addresses
Notes: Test adding and removing notes
Related documents: Test adding and removing related documents
Custom fields: Test adding and removing content in custom fields
Shipping method:
Changing the shipping method on the transaction
Change an order with BOPIS items to have the BOPIS items shipped
Change an order with shipped items to BOPIS
Transaction cancellation
Transaction refund
Confirmation:
Ensure customer is linked to company and/or customer (if needed)
Ensure all values in the header are correct
Ensure all line items are correct and discounts are appropriately applied
Ensure payments are correctly applied and the transaction is captured in the correct state (if needed)
Encusre gift card balance is adjusted (if applicable)
Ensure addresses come through with the correct primary shipping and/or billing designation
Ensure notes come through correctly
Ensure related documents are coming through correctly
Ensure custom fields are coming through as intended.
Data is transformed as intended via dynamic formulas
Repeat the above steps if multiple platforms support transaction update functionality.