Aspire Systems and an anonymised specialty retailer: POS functional testing case analysed

Verdict: what is checkable

Client profile as published

Client

a globally recognized American retail chain, well-known for selling home décor, furniture, textiles, accessories, and gifts (the vendor's description; the vendor does not name the client)

Segment

Specialty retail

Region

United States

Channels

stores and ecommerce

Size indicators

operate in 35 states; around 360 stores

The client description and size indicators are quoted from the source; segment, region and channels are this site's classification. [ev-1141]

Systems in scope

• POS (point of sale: the till software and hardware that rings up store sales, takes card payments and prints receipts.) (Veras POS): named in The Need section; platform named in the Technology Snapshot
• OMS (order management system: software that routes, splits and tracks customer orders across stores, warehouses and carriers.) (IBM Sterling OMS): named in The Need section; platform named in Aspire's Solution and the Technology Snapshot
• Ecommerce platform (Open Commerce Platform (OCP)): named in Aspire's Solution and the Technology Snapshot
• Payments (Cybersource, PayPal): named in the Snapshot of our solution table
• Integrations: named in The Need section (integration with third parties) and the Snapshot of our solution table (POS and OMS integration for BOPIS (buy online, pick up in store: an order placed on the web or in an app and collected at a physical store.) and STS orders)

Where the source names each system is quoted or summarised from the case page. [ev-1141]

Problem as stated

The retailer runs a POS and an order management system in its stores, tied to a back office server, and wanted end-to-end testing to validate and modernize them. It needed separate regression suites (the set of tests rerun before each release to check that existing features still work after a code change.), more than 800 test scenarios written within a fixed timeframe, validation of feature-heavy work items, and checks on third-party integrations. [ev-1141]

time-efficient, inexpensive and effort-intensive (quoted from the source)

Approach

Testing types

functional and api (main scope: functional)

Team shape

three resources during peak periods; offshore and onshore teams

Duration

not stated

Engagement model

not stated

Tooling named in the source

DameWare, Postman, IBM HTTP API tester, Jira

Metrics claimed

What the case does not say

• Baseline before the engagement.
• Measurement method.
• Duration over which the metric held.
• Cost.
• What was out of scope.
• Date of the work.

Reading notes for a buyer

This case speaks to the scenario “POS rollout across stores” and feeds dimension D2 (Retail system coverage) of the methodology. A question to put to Aspire Systems:

How was the coverage claim measured across POS, BOS and OMS, and against which list of requirements? [ev-1141]

Source and verification

Source

American Retailer’s POS, OMS and BOS systems made error-free with Aspire’s E2E testing with 100% coverage

Published

not dated by the vendor

Verified

2026-10-30

Evidence grade

secondary

Corroborating sources

none found

Vendor profile: Aspire Systems. System facet: OMS and WMS testing vendors.