What to test in a sandbox before you go live

A checklist for before you go live. The negative cases are the ones that find real problems.

A checklist for before you go live. The negative cases are the ones that find real problems.

Test the negative case first

Everybody checks that the thing they built now happens. Far fewer check that it does not happen to tickets it should not touch, and that is where the damage is.

For every rule: one ticket that should match, one that should not.

The checklist

1. Does it fire when it should? The obvious case.
2. Does it leave everything else alone? The important one.
3. What about a ticket with no value in the field it reads? Usually the largest group.
4. What happens on the second update? Triggers can fire again and loop.
5. Where does it sit in the order? An earlier rule may already have changed the ticket.
6. Who gets an email? Count the notifications, including to agents.

Empty fields are the classic

A condition on a field completed on a fifth of tickets behaves differently on the other four fifths. Testing only with a completed field tests the minority case.

Watch for loops

A trigger that updates a ticket can cause a trigger to fire, including itself. In a sandbox that is a curiosity; in production it is thousands of notifications.

Have somebody else try it

You test the path you built. A colleague will do the thing you did not anticipate, which is the whole point.

Write down what you tested

Then it is repeatable next time you change the same area, and it is evidence if somebody asks whether this was checked.

See also

• Deploying a configuration from one environment to another
• What a sandbox is and what it is for
• The order of triggers and why it matters