A colleague changes a field in the order form. A report gets a new column. A rule for approvals is adjusted because someone asked politely. Each change takes ten minutes to make, so nobody thinks of testing it. Then on Monday morning the form refuses to save, or the report shows last year's numbers, and the person who made the change is asked what happened.
Full test plans are too heavy for changes like these, so they are skipped. The result is that small changes cause a large share of the surprises. This article describes a check that takes about 30 minutes, needs no special software and is still honest enough to catch the common problems.
Why small changes need a check too
Software teams have a name for the worry behind this: a regression, meaning something that worked before stops working after a change (see Regression testing). Regressions are often not in the part you touched. A changed field name can break an export. A new required field can block a form that another team fills in through a different route.
The person making the change knows what they meant to do. They rarely know everything that depends on it. A short check by someone who works with the tool every day is the cheapest way to find that out before the whole team does.
Step 1: decide what counts as a pass
Before you test, write one or two sentences: what should be different after the change, and what must stay exactly the same. For example: "Orders can now carry a delivery date. Everything else about creating, editing and exporting orders is unchanged."
This stops the check from turning into a general browse through the tool. It also gives the approver something to hold the result against. If the change request already has a clear description, as suggested in a one-page intake rule for change requests, copy the two sentences from there.
Step 2: test in a place where mistakes are cheap
Ideally the check runs in a copy of the tool, not in the live one, so a failed test does not touch real customers or real data. How to set that up is described in a staging copy for an internal tool. If you do not have a copy yet, a second best is to test in the live tool with clearly marked test records that you delete afterwards. Say so in the notes, and keep this for changes that cannot send emails, charge money or alter other people's records.
Step 3: pick three real cases
The core of the check is three cases, taken from real recent work, not invented ones. Invented cases tend to be tidy, and real work is not.
- A typical case. The kind of job that happens ten times a week. Open last week's example and repeat it from start to finish. If this fails, the change is not ready.
- An awkward case. Something unusual that your team still handles: a customer with a long name, an order with a discount, a record with a missing optional field, a user with limited rights. Awkward cases are where changes usually break.
- A must-not-break case. One thing that is close to the change but should not be affected: an export, a report, an email the tool sends, a link from another system. Ask the person who knows the tool best, "What would hurt most if it silently stopped working?"
Three cases are enough because the aim is not full coverage. It is a quick, repeatable look at the places where real trouble tends to appear. If the change is larger, add cases, but keep the habit of choosing them from real work. For a new tool, or a change that touches many screens, a longer session with real work is better; see testing a new internal tool with real work.
Step 4: run it in 30 minutes
Give the check a fixed slot, ideally booked in the calendar, so it does not get squeezed out. A workable split:
- 5 minutes: read the pass description and open the three cases.
- 15 minutes: run the cases one by one, and say aloud or write down what you expect before you click.
- 5 minutes: look at what the tool produced: the saved record, the exported file, the email text.
- 5 minutes: write the result and decide.
Expecting a result before you click matters. Without it, a small difference such as a changed date format or a missing line stands out.
Who runs it and who approves
Whenever possible, the person who made the change should not be the only person who checks it. They tend to test what they built and to skip what they did not think of. Ask one colleague who uses the tool in daily work to run the three cases, and let the person who owns the process approve the release. In a very small team these may be two people out of three, and that is fine. What matters is that the approver is named before the check starts, not found afterwards.
If the change was made by an outside supplier, the same rule holds: the supplier tests their work, and someone on your side runs the three cases and gives the approval. The idea of an acceptance test, where the user side confirms the work does what was agreed, is well established (see Acceptance testing).
Write the result in three lines
The record can be very short. Put it in the change request, a shared sheet or the tool's own notes:
- What was checked: the three cases, with the record numbers or file names.
- Result: pass, pass with a note, or fail, and what was seen.
- Decision: released on a date by a named person, or sent back with a reason.
This takes two minutes and pays back quickly. When the same kind of problem appears again, you can see which case would have caught it and add it to your list of awkward cases.
What to do when the check fails
Agree on this before the first test, so nobody has to argue under pressure. The usual choices are to fix the change and run the check again, to narrow the change to the part that passed, or to drop it. Do not release with the plan to "watch it closely". If something small is accepted knowingly, write it in the notes with a date for fixing it.
Also agree how to go back if a problem appears after release despite a pass: who decides, and how the previous version is restored. A change you cannot undo deserves a bigger check than one you can undo in a few minutes.
Tell people what changed
A passed check is not the end. People who use the tool should hear what is different, briefly and in their language. A short note works better than a long document; see release notes for an internal tool for a simple format.
Common mistakes
- Testing only the new thing. The new field works, and the export that uses the old fields is broken. Always include one must-not-break case.
- Using made-up data. Tidy test data hides the problems real records show.
- The maker is the only tester. They know the intended path too well.
- No stated pass. Without it, nobody can say whether the result is good enough.
A first step
Take the next change already waiting for your internal tool. Write the two sentences about what should change and what should stay the same, choose the three cases from last week's work, book 30 minutes and name the approver. After one round, adjust the list of cases to your tool.
If your internal tool is fragile, has no test copy or nobody is sure how changes are released, that is worth fixing before more changes pile up. Our team can help with a short review of how changes are tested and released; see our custom software service.
