Tryon Info Dock Blog

Testing WMS - Seven Considerations - Tryon Solutions

Written by James Prior | Mar 26, 2020 3:48:15 PM

Seven Considerations When Testing Your Warehouse Management Software

Here at Tryon Solutions we have many grizzled warehouse management software (WMS) veterans, most of whom are also experienced in the realm of software testing, and more specifically, test automation.  We polled, poked, and prodded our grizzliest of grizzled WMS vets to find out what are some of the most important considerations when testing your warehouse management software.

 

  1. Data management. A truly automated test includes data setup and housekeeping, and this part is almost always the most work.  An automation engineer working with a cross-functional team designing test cases should have the “data conversation” when creating the tests, as using valid data that mimics the “real world” is just as crucial as the warehouse business process itself – and having to manually create and reset test data is not reaping the full benefits of test automation.

 

  1. Using dedicated testing environments. Manual testers plugging away in the same environment used by automated tests often results in false positives, data nightmares, and other chaos…For example, if a manual tester deletes a location that is also being used by an automated test then the automated test will probably fail when it moves inventory to a non-existent location.

 

  1. Writing tests for more than one environment. When creating test scripts/features they should – ideally – be able to work across various WMS environments within a company assuming the warehouse business processes aren’t drastically different.  I’ve heard horror stories of automation engineers writing a suite of test scripts against one environment assuming that they will work elsewhere, and then later finding they can’t be used at other warehouses due to small nuanced differences in processes (which could be accounted for in the script by making it more flexible), hardcoding when variables should have been used, and/or different data configuration elements.  Its easier to write tests from scratch against a variety of environments, then to go back and modify an entire test suite after the fact.

 

  1. Ensuring the testing team is truly cross-functional and that all have “bought in” to the program. For example, an automation engineer isn’t going to write scripts/features to test out the terminal receiving process that are worth a salt without the involvement of at least one employee from the loading dock (in this case the subject matter expert) who is intimately familiar with the company’s inventory receiving process and knows from experience what is likely to go wrong, what needs to be validated, and also believes in what the automation engineer is doing.

 

 

  1. Creating regression and performance tests for the most critical business processes while focusing on their most common paths (aka smoke testing) before fleshing out the test suite with edge cases, negative tests, and more permutations. Target what absolutely MUST work first.  For example, an online Blu-ray store should consider starting off their test suite with an order fulfillment test for their best-selling movie.  They should also – and admittedly this is optional – burn all copies of the Cats movie.

 

  1. Performing true end-to-end tests complete with related integrations, in addition to the modular test case suite.  Its critical to validate the system from start-to-finish as a user in order to check the full application flow as well as the accuracy of the data movements and other integrations and connections in-between.  The modular tests can be used to help create the end-to-end tests if they were properly designed.  Be sure to choose a test automation solution that makes creating end-to-end tests easier – feel free to contact us for more information on that!

 

  1. Buying the strongest coffee available by law, and if that doesn’t cut it then look into illegal coffee options.

 

Did we miss another warehouse management software consideration for automated testing? Let us know on social media @TryonSolutions!

This post was written by:

James Prior
Sales Ops Manager

James has been working in software pre-sales and implementation since 2000, and more recently settled into working with a pre-sales team and occasionally writing blog posts. Drop him a line at: james.prior[at]tryonsolutions[dot]com.

Recommended Content

 

 

13 Burning Questions for a Pioneer in Warehouse Modernization

    We continue our "Burning Question" interview question series with Trevor Blumenau.   Trevor is a professional engineer with a master’s degree in robotics from UC Berkeley and has 25 years of R&D experience in warehouse/manufacturing processes,...

A Guide to Warehouse Management System Tiers

  We’ve defined what a Warehouse Management System is and exhaustively covered supply chain execution acronyms, and so now we must tackle a somewhat nebulous and potentially confusing related subject:  Warehouse Management System tier classifications.  What is...

Why Would You Need a Labor Management System?

  Delivering a product to the right place at the right time efficiently can take more than just having a Warehouse Management System (WMS) in place.  In today’s ultra-competitive environment, which includes an uncertain labor market, your warehouse must fully...

13 Burning Questions for a Captain of WMS Industry: Erhan Musaoglu

    We’ll now be interspersing "Burning Question" interviews with experienced WMS professionals and industry leaders into our “Info Dock” Blog, and to kick-off our interview series we scored the latter with a true captain of industry in the WMS space:  Erhan...

Why Would You Need a Transportation Management System?

  Delivering a product to the right place at the right time can require more than just a system that optimizes everything within the walls of a warehouse, and so let's answer the question:  Why would you need a Transportation Management System?  Meeting customer...