Will Your TMS Still Work After an Update?

Imagine a routine TMS update changes how a surcharge is calculated. A shipment gets billed incorrectly, and your customer is the first to notice.

Now your team has to correct the invoice, check whether other shipments were affected, and explain the mistake. One small software change has created work for operations, finance and customer service.

That's what makes update testing so important. Your TMS needs to keep getting the details right while shipments are moving, invoices are due and customers are waiting. A useful testing process checks both the change itself and the work around it.

At Neurored, we approach this systematically: define the correct result, check affected workflows, record what happened and assess the issues that remain. AI helps us draft tests, while our quality assurance (QA) engineers review them before use. Here's how that process helps us judge whether an update is ready.

What Does a Correct Result Look Like?

Before anyone can say a test passed, they need to agree on what a correct result looks like.

Consider the surcharge example. Which shipments should the new rule apply to? What determines the amount? What should a particular shipment be charged?

If those answers aren't clear, a test might pass even though it's checking the wrong calculation. That's a dangerous kind of reassurance.

At Neurored, our QA engineers work with documented requirements and product knowledge maintained alongside Product Owners and Business Analysts. If something is unclear or missing, the test-design process flags it for review. The team can raise a task in Jira to get clarification from the product team before relying on the test.

This matters because even a carefully executed test is only as useful as the rule it's checking. Getting that rule right from the beginning helps catch misunderstandings before they affect real shipments and invoices.

[post|Are You Paying the Carrier Rate You Agreed To?|See how connected contract terms and invoice checks help close the gap between negotiated rates and actual charges.|https://cdn.prod.website-files.com/699ee1f3535208d5a990b4ca/6acf988b9ff0548dd7b12152_Cover_Carrier%20Contract%20Management%20Guide.jpg|Find the rate gaps|https://www.neurored.com/blog/carrier-contract-management/]

What Else Could an Update Break?

The new surcharge calculation works correctly. But what happens when that charge needs to reach the billing system? Or when several employees are processing shipments at once?

An update can affect more than the feature being changed. Depending on what's involved, the testing team may also need to check connected systems, user permissions and how quickly the TMS responds under a normal workload.

Here's what those checks mean for your day-to-day operations:

In software testing, checking that existing features still work is called regression testing. Checking that connected systems exchange the right information is called integration testing.

Both serve a practical purpose: making sure an update doesn't interrupt the work your team already depends on.

The testing should reflect what changed and the problems it could cause. That might mean checking a calculation, confirming a handoff to another system or seeing how the TMS responds when multiple people are working at once.

One useful question to ask your provider is: "Which of our everyday workflows could this update affect, and how did you check them?"

A specific answer, tied to the tasks your team actually performs, tells you far more than a general assurance that the update has been tested.

[post|One Shipment. Three Systems. Where Does the Data Slip?|See how disconnected bookings, shipping instructions, and cargo weight submissions create rework and missed deadlines.|https://cdn.prod.website-files.com/699ee1f3535208d5a990b4ca/6acf988b956c398f110ac605_Cover_Ocean%20Ebookings%20Salesforce.jpg|Find the workflow gaps|https://www.neurored.com/blog/ocean-ebooking-salesforce/]

Who Checks AI-Drafted Tests?

AI can produce a convincing-looking test even when it has misunderstood the requirement. That's why human review is essential.

Neurored developed Titan, an internal AI tool, to help our QA engineers prepare tests more consistently. It brings together product knowledge, feature requirements and information supplied by the QA team to draft what needs to be checked.

Each draft specifies:

• Starting conditions: What must already be in place.
• Steps: What the tester needs to do.
• Inputs: What information needs to be entered.
• Expected results: What the software should do.

For our surcharge example, that means defining the shipment details, the actions to perform and the exact charge the TMS should calculate.

But producing a well-structured test is only the beginning. Our QA engineers review the drafts against the requirements, check for missing conditions and correct anything that doesn't make sense.

This review matters especially when the rules are complex or the documentation is incomplete, areas where Titan can struggle. The accuracy of its drafts also depends on having reliable, up-to-date product information.

Once reviewed and approved, the tests move into Xray, Neurored's test-management tool. Each stays linked to its original requirement in Jira, so the team can trace a test back to the change it was designed to check.

Titan helps us prepare more consistent tests and reduce manual preparation. Our QA engineers determine whether those tests are appropriate, and the results of running them provide the evidence needed to assess the software.

[post|Your Vendor Uses AI. Who Checks Its Work?|Learn what to ask about human review, product knowledge, and safeguards behind AI-assisted software changes.|https://cdn.prod.website-files.com/699ee1f3535208d5a990b4ca/6acf988b9cb52bf08ec76bbd_Cover_AI%20in%20Logistics%20Software.jpg|See the questions to ask|https://www.neurored.com/blog/ai-in-logistics-software/]

What Did the Tests Find?

A well-written test is a plan. A recorded result is evidence.

At Neurored, our QA process includes running tests, recording the outcomes and reviewing the documentation. This helps establish what the software actually did against what it was supposed to do.

Consider the surcharge example. The test record should show the shipment details, the expected charge and the amount the TMS calculated. If the figures don't match, the record makes that failure visible.

These results help answer the questions that matter to a TMS owner: What was checked? Which tests passed? Which failed? And what could those findings mean for daily operations?

Without recorded results, "we tested the update" offers little to judge. With them, the team has evidence to explain what happened and identify what still needs attention.

What Risks Remain Before Release?

An update can pass many tests and still have unresolved problems. The important question is what those problems could mean for your operations.

An issue that adds an extra manual step is very different from one that produces incorrect charges or delays shipment information reaching another system. Both deserve attention, but the consequences aren't the same.

That's why release readiness involves more than counting how many tests passed. The team needs to understand which workflows were checked, what problems remain and how serious their consequences could be.

Established software testing guidance, including the ISTQB Foundation Level syllabus, also considers test results and unresolved defects when assessing whether testing is complete.

A good readiness assessment brings these findings together and explains how they informed the decision to release.

Even if every planned test passes, that doesn't prove the software has no defects. What testing provides is evidence to make a considered decision, with a clearer understanding of the risks involved.

What Should You Ask Your Provider?

The next time your TMS provider announces an update, pick a workflow your business depends on, such as calculating shipment charges or passing information to a billing system.

Then ask four questions:

1. What should this workflow do after the update?
2. Which parts of it did you test?
3. What passed, what failed and what remains unresolved?
4. How did those findings influence the release decision?

The answers should make sense to the people managing shipments, invoices and customer commitments. They should show that your provider understands what's at stake and has checked it deliberately.

At Neurored, we bring together detailed product knowledge, AI-assisted test design, human review and recorded results to assess changes to the software our customers rely on.

Book a demo to discuss your most important freight workflows and how Neurored approaches testing the TMS that supports them.