Test Before You Touch: Trying Changes Safely Before They Hit the Live Process

It was a small change. Make “cost centre” a required field on purchase requests, so finance stops chasing people. It went live at 10am. By 10:15, the automation that creates requests from the supplier portal was failing silently, because it didn’t fill in cost centre. Nobody noticed until a week of supplier orders had vanished.

Live internal tools are a lot like spreadsheets in one dangerous way: anyone with edit rights can change them instantly, in front of everyone. The difference is that a tool has more moving parts connected to each change. Testing is how you find out what those parts are before your colleagues do.

Why “just be careful” doesn’t work

Most changes go wrong in places you weren’t looking. You change a field, and the thing that breaks is a report, an automation, a form, or an integration that someone set up two years ago.

In the purchase request example, the person making the change tested the form. The form worked perfectly. What they didn’t know was that requests also arrived another way. Being careful about the bit you can see doesn’t protect you from the bits you can’t.

So testing is less about being cautious and more about deliberately exercising the whole process, end to end, somewhere it doesn’t matter if it breaks.

Three places to try a change

You don’t need an engineering-grade setup. Pick whichever of these your platform supports and your change warrants.

A full copy of the tool. Many platforms let you duplicate a base, app or workspace. This gives you a sandbox: a separate copy where you can change anything without affecting live work. It’s the safest option for structural changes like new tables, renamed fields or rebuilt automations. Two cautions: copies drift out of date quickly, so make a fresh one for each significant change, and switch off any automations in the copy that send emails or touch other systems, or your customers will get test messages.

Test records in the live tool. For smaller changes, create clearly marked test records in the real system. Prefix them obviously (“TEST – do not process”) and use a dedicated test customer or project so they’re easy to filter out of reports. This lets you check behaviour against real configuration, which a stale copy may not match.

A hidden draft of the change. Some changes can be built alongside the old version and switched over when ready: a new view built but not shared, a new form at an unpublished link, a new automation created but turned off. You test the new thing while the old thing keeps running.

Find out what’s connected first

Before testing anything, spend ten minutes mapping what the change touches. For the field, table or status you’re changing, check:

• Forms that write to it.
• Automations that read it, write it, or trigger on it.
• Integrations with other systems: your CRM, accounting software, chat tool or a supplier portal.
• Views and reports that filter, group or sort by it.
• Calculated fields that use it in a formula.
• People who rely on it in a daily routine, even if no system does.

Some platforms show you dependencies. Many don’t, so you’ll be checking by hand. If your team keeps a data dictionary, as suggested in Naming Conventions and Documentation for Internal Tools, this becomes much quicker.

Whatever’s on this list goes into your test plan.

A simple test checklist

You don’t need a formal test plan document. A checklist on the change request is plenty.

1. Describe the change in one sentence, and what “working” looks like.
2. List what’s connected, from the step above.
3. Run the happy path. Create a record the normal way and take it all the way through the process, start to finish.
4. Run every other path in. Form, import, automation, integration, manual entry. Each one is a separate test.
5. Try the awkward cases. A blank optional field, an unusually long name, a record that skips a stage, an old record created before the change.
6. Check as a normal user. Admins often see and can do more than everyone else. Use a test account with ordinary permissions, or ask a colleague.
7. Check the outputs. Did the right notifications go out? Did the report still add up? Did the record reach the other system intact?
8. Clean up. Delete or archive test records, and switch off test automations.

Step 5 is where most bugs live. Step 4 is where the purchase request story would have been caught.

Get someone else to try it

You built the change, so you know how it’s supposed to work and will use it that way. A colleague who does the work every day won’t.

Ask one real user to try the change in the copy or with test records, without instructions. Watch where they hesitate. Ten minutes of this beats an hour of you testing your own work.

Plan the switch and the way back

Testing reduces risk but never removes it. Before going live, decide:

• When. Not at month-end, not on a Friday afternoon, not during your busiest hour.
• How you’ll know it’s working. A quick check an hour after launch: are records still arriving from every path?
• How you’ll undo it. Write down the exact steps to reverse the change, and take an export beforehand if the change alters data.

Changing a Live System Without Breaking Trust covers how to announce changes and handle rollback with users. Testing is what gives you something trustworthy to announce.

Where to start this week

• Find out what your platform supports: copies, test users, unpublished forms, disabled automations.
• Create a standard test customer or project in your live tool, clearly labelled, and exclude it from your main reports.
• Add the eight-step checklist to your change request template so it’s there every time.
• Pick the next pending change and map its connections before anyone touches it.