How to create a practical test plan

You've just rolled out a change to your custom FileMaker system — a new field, a tweaked script, an updated API connector — and two days later a customer calls because invoices are being calculated wrong. Nobody caught it, because nobody actually tested it beyond "does it open without an error." This is the moment most business owners and IT managers realize they don't have a test plan; they have a hope plan.

A practical test plan isn't a 40-page QA document nobody reads. It's a short, living checklist that tells you exactly what to check, in what order, before any change goes live — so you catch the invoice bug yourself, in a test environment, instead of your customer catching it in production.

Why do most custom software projects skip proper testing?

Because testing feels like it slows things down, and custom business software is usually built by small teams under real deadlines. A solo in-house developer or a two-person Loggix-style team is focused on shipping the feature the business is waiting for. Testing gets reduced to "I clicked around for five minutes and it looked fine."

The problem is that custom systems — a FileMaker maatwerk solution, a tailored ERP module, an API connector between your webshop and your accounting package — don't fail loudly. They fail quietly. A rounding error in a price calculation. A webhook that silently stops firing after a field name changes. A permission setting that lets the wrong role edit invoices. None of these throw an error message. They just produce wrong data that someone downstream has to clean up, usually weeks later when it's much harder to trace back.

This is exactly the risk covered in Loggix's broader guide on how to make custom business software reliable and transferable — a solid test plan is one of the concrete mechanisms that makes reliability actually happen, rather than just being a nice intention.

What does a "practical" test plan actually mean?

Practical means three things:

1. It's specific to real workflows, not generic software checklists. You test "create an order, apply a discount code, send the invoice to Exact Online" — not "test the order module."
2. It's proportional to risk. A cosmetic layout tweak needs a five-minute check. A change to how VAT is calculated needs a much deeper pass, because the cost of getting it wrong is a compliance problem, not a UI glitch.
3. It's repeatable by someone other than the developer who wrote the code. If only the original developer can run the test, it's not a test plan — it's a memory.

How do you build a test plan step by step?

Step 1: List the business processes that touch the system

Start from the reader's actual operations, not the software's menu structure. For a FileMaker-based order system, that might be: order intake, discount/pricing logic, stock reservation, invoice generation, and the API sync to the accounting package. Each process becomes a section of your test plan.

Step 2: Write test cases as "if this, then that" scenarios

Instead of "test the discount field," write: "If a customer with a 10% loyalty discount orders 3 units of product X at €50, the invoice total should show €135, not €150." Concrete numbers make a test case something anyone can actually run and verify — and something an AI-assisted test runner or a junior tester can execute without guessing what "correct" looks like.

Step 3: Separate happy-path tests from edge-case tests

• Happy path: the normal, expected flow — a standard order, a standard invoice, a standard sync.
• Edge cases: the situations that actually break systems — an order with quantity zero, a customer with no email address, two users editing the same record at the same time, a connector call that times out halfway through.

Most production bugs live in the edge cases, not the happy path, because the happy path is what developers naturally test as they build.

Step 4: Assign each test case a severity level

Not every failed test should block a release. A three-tier system works well in practice:

• Blocker — data corruption, financial miscalculation, security/permission issue. Release is stopped.
• Major — a workflow breaks but there's a manual workaround. Fix before release if possible.
• Minor — cosmetic or edge-case-only issue. Log it, fix it in the next cycle.

Step 5: Decide who tests, and when

The person who wrote the script should not be the only person who tests it — they already believe it works, which is exactly why bugs slip through. Build in a second pair of eyes: another developer, a power user, or a designated tester on the business side who knows the workflow but not the code.

Step 6: Re-run the plan after every meaningful change, not just before big releases

A one-line script fix can silently break something in a completely different module — FileMaker's global variables and shared scripts make this especially easy. Keep a "regression set" of your most critical test cases (invoicing, permissions, key integrations) and run that set after every deployment, big or small.

What should actually go into the document itself?

Keep it in a format your team will actually open — a shared spreadsheet or a simple table in your project management tool works better than a Word document nobody updates. Each row needs:

Field	Example
Test case ID	INV-014
Process	Invoice generation
Scenario	Order with loyalty discount + partial stock
Expected result	Invoice total €135, partial-fulfillment flag set
Severity	Blocker
Tested by	(name, not "developer")
Result	Pass / Fail / date

How does this apply differently to AI-assisted features?

If you're adding AI inside FileMaker — for example a Klai-style AI layer that drafts customer responses, summarizes records, or classifies incoming data — testing needs an extra dimension: consistency, not just correctness. A traditional script either returns the right number or it doesn't. An AI feature can be "right" in ten different phrasings and still occasionally produce something off-tone, factually wrong, or inconsistent with company policy.

For AI-assisted workflows, add test cases that specifically probe:

• Boundary inputs — empty fields, extremely long text, non-English input, if relevant.
• Consistency over repeated runs — does the same input reliably produce an acceptably similar output?
• Fallback behavior — what happens if the AI service is slow or unavailable? Does the workflow degrade gracefully or does it hang?

How does this apply to layout and interface changes?

Interface tools such as FMBetterforms let teams build modern, responsive layouts inside FileMaker — but a layout change is still a change, and it deserves its own lightweight test pass. A form that looks perfect on a desktop browser can silently clip a field or break tab order on a tablet used on the warehouse floor. Add a short device/browser checklist to your plan for any UI change: desktop, tablet, and the specific browser your field staff actually uses.

What's a good minimum test plan if you have almost no time?

If a full plan feels like too much right now, don't skip testing — shrink it. A minimum viable test plan covers just three things, every single release:

• Does the core financial calculation (price, discount, tax, total) still produce the right number?
• Can the record be created, edited, and deleted by each user role without permission errors?
• Does the critical integration (payment, accounting, webshop) still send and receive data correctly?

That's roughly fifteen minutes of manual checking, and it will catch the majority of the bugs that actually reach customers.

FAQ

Do I need dedicated QA software to do this properly? No. A shared spreadsheet with the columns above, reviewed before every release, covers 90% of what small and mid-sized custom software teams need. Dedicated QA tools help once you have a large team and frequent releases, not before.

Who should own the test plan — the developer or the business owner? The developer maintains it technically, but the business owner or process owner should review the test cases at least once, because they know which scenarios actually happen in daily operations and which are theoretical.

How often should the test plan be updated? Every time a new feature, integration, or workflow is added. An outdated test plan gives false confidence — it tests what the system used to do, not what it does now.

What's the single biggest sign a test plan isn't practical enough? If running it takes longer than the team is realistically willing to spend before every release, it will get skipped. Shrink the scope to the highest-risk cases rather than abandoning it entirely.

A practical test plan is one of the clearest ways to protect the reliability of custom software as it grows — and it's exactly the kind of structure that keeps a system transferable between developers over time. If your team is building or modernizing a FileMaker maatwerk solution, an ERP workflow, or an API connector between systems, Loggix can help set up a test plan that fits how your business actually works — and, where useful, bring in AI-assisted tooling or hands-on consultancy to make sure changes go live with confidence instead of crossed fingers.