Testing retail changes in a sandbox before they hit the live POS

Change management · 7 min read

Most retail system problems are not bugs. They are changes that met real trading for the first time: a posting setup edited at head office that breaks the statement, a POS button moved during someone's lunch break in the layout, a replication job whose new filter quietly excludes half the stores. The fix is boring and it works — every change that can touch a till gets proven in a sandbox first, against a written test script, with a named sign-off and a rollback decision made before go-live.

The rule: no retail change debuts on a live till

LS Retail lists "not testing enough" among the common LS Central implementation mistakes, and the reasoning applies to routine changes just as much: insufficient testing leaves system errors and integration issues undiscovered until they stop the business operating at full potential, and testing without end users misses usability problems and workflow inefficiencies. Their recommended mix — unit testing, integration testing, and user acceptance testing — maps cleanly onto a change routine: test the setting, test how it flows to the store, then have a store user test how it feels.

Build the sandbox the change deserves

For LS Central on SaaS, a sandbox can be created by copying the production environment, which is the right default for anything touching posting, layouts, or replication: the test is only meaningful against real items, real stores, and real distribution setup. Three rules keep the sandbox honest:

• Refresh it for the change. A sandbox copied months ago tests the change against a business that no longer exists. Copy production close to the test, and remember the copy overwrites what was in the sandbox — anything in the old sandbox worth keeping has to come out first.
• One change at a time. A sandbox carrying three untested changes proves none of them. If change B depends on change A, that dependency is written on the change record, not discovered at go-live.
• Keep live systems live. Testing happens in the sandbox precisely so the production environment keeps running the business — data entry, invoicing, and the daily close never happen in the test copy.

The retail test script: transactions and posting

Run the same script for every POS-affecting change, in this order. The script is the original procedure here — its value is that it never changes, so results are comparable from one change to the next:

1. Baseline sale. Sell a normal item for cash. Note the transaction number and total.
2. Discount paths. Apply the discounts the change touches — line, total, offer, or member pricing — and one it should not touch.
3. Returns and voids. Return an item from the baseline sale, and void a line mid-transaction.
4. Tender mix. Pay part cash, part card (or the store's equivalent split), because tender handling is where posting surprises hide.
5. Post and inspect. Post the transactions and check the resulting entries against the pre-change expectation: the accounts hit, the tax treatment, and the statement totals. If posting fails, the posting troubleshooting guide is the triage path — in the sandbox, where a failure costs nothing.
6. Close the day. Run the end-of-day process in the sandbox and reconcile the statement against the script's expected totals.

A step passes only if the output matches the expectation written down before the test — "it posted" is not a pass if it posted to the wrong account.

Test the POS layout like a cashier will use it

Layout and profile changes have their own documented discipline. LS Retail's guidance for the POS user interface is to perform all the steps in a test company to make sure everything works as expected, and only then move the configured profiles and controls to the production company — with the LS Import Export WS named as the transfer method, and any control that needs changing copied from the ##DEFAULT controls into the profile before it is modified. Followed as change management, that means:

• Build the layout change in the sandbox company, never by editing the live profile.
• Have a cashier or store manager run the test script on the new layout. Button placement is a usability question, and usability questions are answered by end users — the same reason LS Retail warns against testing that excludes them.
• Transfer the verified profile set to production as one action, during a quiet window, and record which profiles moved.

Test replication, not just the change itself

A change that works at head office and never reaches the stores has not worked. What replication testing means depends on the estate:

In both cases, destinations need a valid connection setup on their distribution location before replication can reach them — check that as part of the test, not as part of the incident.

Sign-off: who says yes, and on what evidence

Sign-off is a decision framework, not a signature hunt. A change is ready for live when all four answers are yes:

1. Script passed? Every step of the retail test script produced the expected result, with the outputs (transaction numbers, statement totals) attached to the change record.
2. Store voice heard? A store user ran the POS-facing parts and raised no usability blocker.
3. Replication proven? The change demonstrably reached a test destination through the same path it will use live.
4. Rollback decided? The section below was answered in writing before the go-live window opened.

The person who built the change does not sign it off alone. The sign-off belongs to whoever owns the process the change touches — finance for posting setup, store operations for layouts — because they are the ones who will own the consequences.

Rollback thinking: decide before go-live

Rollback in retail splits into two honest categories. Settings and profiles can be reversed: a posting setup change can be edited back, and a layout can be replaced by re-transferring the previous verified profile set — which is why the previous set is exported and kept as part of the change record. Posted transactions cannot be un-posted by wishing: once a bad change has traded, the correction is reversing entries and fixing statements, which is slower and more visible than the change itself. That asymmetry drives three decisions made before go-live, never during:

• Blast radius. Pilot in one store or one terminal group first when the change allows it, so a rollback is a small event.
• Abort trigger. Name the observation that stops the rollout — first posting failure, first statement mismatch, first till complaint of a named type — and who is allowed to call it.
• Timing. Go live early in the trading day, with support watching, not in the last hour before close when a bad statement lands on tired staff. (For platform updates the same principle is enforced by the platform itself: a failed environment update restores the environment to its previous version — configuration changes offer no such safety net, which is exactly why the sandbox discipline exists.)

What success looks like

• The change record shows the full test script passed in a sandbox copied from production, with expected vs. actual totals recorded.
• A store user has used the changed POS flow and signed off the usability, not just the function.
• Replication of the change is proven to a test destination through the live path.
• The rollback decision — what reverses, what cannot, the abort trigger, and the pilot scope — is written down before the go-live window opens.
• On the first live day, the statement reconciles against expectations, the same check as the normal end-of-day routine.

FAQ

Does every change need the full script? Every change that can reach a till, a posting, or a store's data does. A report layout nobody trades on can take a lighter path — but that judgement is recorded on the change, not assumed.

Can we test in production after hours instead? That is how changes debut on live tills with extra steps. The sandbox exists so failures are free; a production "test" that posts has already spent the money.

Who keeps the test script? Whoever owns change management keeps one version. The script changes deliberately, never per-change, or results stop being comparable.