by Barry Burke
There is an age-old comparison of quality versus quantity that resonates within the world of testing. Of course, when it comes to testing it’s not a case of quality or quantity, but both.
Quality of output is assessed using functional testing. IE: if input = A+B, output = C. For ERP software like JD Edwards EnterpriseOne it’s important that every workflow delivers a predictable and consistent result. When updates or code changes are applied, functional testing plays a key role in ensuring the continued quality of output, and that all dependent workflows continue to work as expected.
However, functional testing alone is not enough to test the resilience and predictability of your system. Running a sequence of simulated functional tests is not an accurate reflection of the real-world demands that are likely to be placed on your systems. This is where quantity comes in.
Enterprise software applications, and the platforms or infrastructure used to deliver them, need to be able to deliver the same reliable outcome to thousands of concurrent users. The only way to establish this reliability is to conduct load testing.
The failure of customer-facing systems can be embarrassing – we’ve all seen the headlines detailing website crashes during periods of unexpectedly high demand, or customer service applications stretched to breaking point following extreme weather conditions. Of course, the connected nature of most organizations means that even the failure of a seemingly insignificant internal system is likely to impact on the customer experience.
Remember, testing is not an activity, it’s a process. It takes place throughout the software development lifecycle and is particularly important when systems are being upgraded or business processes are evolving. At its heart, change involves risk and testing is all about mitigating risk.
Recognizing the risk
During exceptionally busy periods, systems do not always perform as expected. That’s why stress testing or load testing your JD Edwards E1 system is so important.
Systems should never be designed with the lowest levels of utility in mind, they should always be built to perform during periods of sustained, heavy use. After all, it is during periods of highest demand that any systems failure has the greatest impact.
Capacity-related systems failures are less common than functional errors, but you shouldn’t fall into the trap of thinking less likely means lower risk. Once a system is in production, any downtime could have a significant impact on everything from customer satisfaction to production timescales and revenue generation.
The larger your organization, the more connected systems or the more varied the workflows, the more important load testing becomes. In the real world, your systems may need to cope with hundreds, thousand, or even millions of concurrent workflows (in the case of large-scale consumer-facing websites of e-commerce platforms).
Load testing in a JD Edwards E1 environment typically takes place towards the end of any development cycle. Resilience can only be established once functionality has been defined.
Function versus Frequency
Load testing allows you to measure more than just the continuity of a desired outcome, it allows you to assess any latency or hang-time that may result from higher volumes of use. Again, this goes back to the user experience. Availability is one thing, but so is performance.
Load testing also needs to take into account the fact that not all users are the same. The broader the spectrum of users, the greater the chance of a variation in “input behaviour”. Straightforward functional testing often assumes all interactions are the same. Load testing a real-world scenario would involve a degree of individuality that would more accurately reflect user behaviour.
Test Automation
If conducted manually, load testing can be a burden on both time and financial resources. That’s why it lends itself so well to test automation. However, in order to get most value out of automated load testing, analysts need to be able to simulate and repeat a wide range of interactions.
When selecting a test automation product, it makes sense to choose one that is designed with your specific software in mind. A generic solution is likely to require either a lot of customization or compromise on quality. As with any testing solution, it’s important to be able to monitor performance in real-time and to extract and analyze test results down to a forensic level of detail.
DWS has designed Dimension LoadTest™ to address these challenges. It provides a powerful, accessible and easy to use tool for JD Edwards EnterpriseOne (JDE E1) load testing. It allows customers to easily simulate load and do the work of hundreds of users in a fraction of the time, reducing overall test resource by more than 95%!
If you are a current user of JD Edwards EnterpriseOne and would like to find out more about test planning and automation, contact us now.
