Date: 19 October 2020
There’s an old joke in the software development world where, instead of describing an obvious problem as a bug, you instead call it a ‘feature’. While that may be a jovial approach to accepting issues, customers and consumers distinctly fail to see the funny side.
That’s why it’s necessary to thoroughly test enterprise software system updates throughout the ecosystem before deploying to production – but the challenge is relentless, with 90-day update cycles necessitating a better way driven by intelligent automation.
The thing is that the undoubtable benefits of cloud solutions are challenged if we fail to respect the entire customer ecosystem providing the service, not just the quality of a single system invariably integrating with sometimes hundreds of end points.
Functioning systems that are ‘product tested’, but subsequently impact the integration layer, negatively impact service and perception. This is driving a need to transition to a ‘right spend’ on testing where the focus falls on high-value testing areas.
One of these areas is the continuous upgrade cycle. For many, the regular 90-day release comes with more than a few headaches because it sets off a frantic seven-to-eleven days of testing to make sure each and every integration works as it should before going into production.
The model we brought into reduced testing as the product comes fully tested from the vendor… right? Probably… wrong.
Sound familiar? Unpleasantly so?
The good news is that it doesn’t have to be that way. At Assurity, we’ve designed and delivered a far better approach by building enduring test assets at the border of the systems of record. We’ve introduced automation on high-value areas of the integration contract and made it possible to get the job done in minimal time.
That allows ample time to target testing specific to a release if required.
Why a better testing approach is necessary
First, consider what happens in the absence of automation and those enduring test assets. In most cases, businesses are forced to accept increasing levels of risk as the cost of testing teams balloon (with no tangible benefit) until a large-scale failure creates a compelling event.
There’s a lot to be done, with a hard time limit and, for most executives, there’s little motivation to spend. After all, as far as they’re concerned, they’ve invested in a fully-tested solution.
Yet, there’s a lot at stake, including security, reputation and revenue.
Even so, things tend to be tight. We’ve seen organisations needing as many as 20 or more days to get the testing done, which has these big teams working around the clock.
Protect the border
We’ve heard a lot about protecting the border with the COVID crisis swirling around us. There’s another border worth protecting and that’s the edge of your cloud ERP.
We’ve found that targeting testing at the integration layer interrogates interactions on the schema between systems. Decoupling dependencies on system change provides huge business benefit, accelerating testing on high-value areas. The enduring test assets we’ve created sit at the border because it makes them available to parties on both sides – your internal teams and then the teams of your partners who integrate with your systems.
The biggest bang for buck undoubtedly, is when these assets are in the hands of developers – after all, these are the people who understand their own systems best and know what to look for in terms of the quality of their integrations. Allowing developers to embrace these assets earlier in the software delivery lifecycle enables them to reduce defects at the earliest stage.
Also, note that because these assets are decoupled, it ‘accelerates’ automation. By that, I mean that in a traditional automation approach, you’d throw data out to a target system, typically have manual intervention and wait for a response.
The trouble is that this elongates the time taken to get the tests done because you may or may not get that response. It also plays against the primary advantage of automation (which is rendering testing ‘hands free’) because it’s prone to high maintenance; if you don’t get a response, someone has to find out why, in other words.
With the Assurity approach, when the next upgrade arrives from the vendor and it’s time for testing, teams on either side access the assets, run the automation and accelerate towards ‘good to go’. It’s faster, cheaper and, most importantly, more thorough than any testing approach yet.
A case in point
Typically, there’s around a one-to-two-week testing window at every upgrade cycle. That’s not a lot of time and yet testing is crucial to protect your services (or prepare for the nightmare of fixing in Production).
That’s probably best demonstrated by the approach to testing at one of our major government customers:
- Testing should provide assurance that there won’t be any external issues which might impact customers
- Testing should guarantee that this organisation won’t fail to provide a service to partners and its broader ecosystem
- And, finally, testing should keep the organisation out of the papers!
Broadly, this approach is one that every organisation can take on board. Like this government department, the focus of quality assurance as it relates to enterprise systems upgrades should fall on internal engagements and the integration layer.
Finally, the question everyone should be asking… Just what are the benefits of automated testing at the border? At this government organisation, the results have been measurable, clear and conclusive:
- Automated tests run in a matter of hours, not days
- Hundreds of tests are executed automatically and instantaneously – for example, 277 tests on HR Payroll integration alone and 236 on Business Process integrations
- Automated tests at the border have reduced effort by around 80%
- The frequency of testing improves dramatically with some 95% more test cases executed daily
- Automation finds the bugs – this customer has already identified around 130 defects
While the particular example I’ve referred to revolves around enterprise solutions in the Oracle cloud (and Oracle has described the results as the quickest time to market for upgrades it’s ever seen), automated testing at the border is relevant to and applicable for any cloud solutions. Whether Microsoft Dynamics, SAP, Infor, Epicor, IFS, Workday, you-name-it, the challenge is the same.
And so is the solution. Embrace investment at the border where cloud provider responsibility ends, allowing them to quality assure their products. On your side, you have enduring automated test assets called upon with every new release.
This makes the process faster, easier and more affordable certainly. But most importantly of all, automated testing de-risks (and de-hassles) one of the major issues with enterprise cloud – that infernal, inexorable upgrade cycle which, if handled poorly, will impact your customers.
Find out more about our test and QA services for Oracle Cloud ERP applications.
