by Barry Burke
Planning Your E1 Upgrade Testing
In the first blog in this series I explained how the DWS Dimension Analyze service is used in the planning phase to produce extremely accurate forecasts of the upgrade effort required. It can also reduce your modified footprint by up to 75%, thereby reducing your upgrade effort and costs.
In the second blog I addressed the execution of your upgrade and explained how you can deliver your upgrades on time, on budget and with minimal defects by using the DWS Dimension Professional service.
In this third blog I will address the challenges of planning the testing of your upgrade and show you how you can minimize your testing effort by focusing on just what needs testing.
In particular, I will focus on:
- Why a new approach to testing is required
- Key challenges to planning your E1 testing
- A new approach
As you will know, Oracle has been promoting the concept of the code current for its JD Edwards customers.
You will probably also be aware DWS has been a keen supporter of this strategy and our existing software led services take a lot of the effort, hassle and cost out of upgrading, then staying code current.
Last year, to find out why more people haven’t already adopted a code current policy DWS conducted research among more than 100 JD Edwards customers.
We asked the very specific question “What issues are stopping a code current policy?”.
The top reason given, for 76% of responders, was that testing is difficult and time-consuming.
Testing, therefore, will be a key challenge that you need to address when carrying out your next EnterpriseOne upgrade.
But surely there are testing solution options out there in the market place. Yet most users resorted to manual testing rather than use the existing solutions. Why is that?
Well, it turns out that the current testing options available have their own problems; with the top issues being…
- the need for specialist staff
- the fact that changes to the code will require complex changes to the testing solution
- testing is too time-consuming and too complex.
There is clearly a need for a new solution as most people are relying on manual testing, there are few solutions available and those solutions that are available tend to be expensive and are far too complex for the typical JD Edwards customer.
Test Planning Challenges
The biggest dilemma facing your Quality Assurance team is how to identify precisely what needs testing. To do this you need to know exactly what has changed in the ESUs you are installing, which objects those changes ESUs affect and to be able to identify all the dependencies in your E1 system from all the affected objects to truly understand the full impact of those changes.
Once you have identified the full impact of those changes you need to assess by how much any object has been affected, so you can determine how thoroughly you need to test each individual object. For example, is it just a yes / no dialog box that has been repositioned or are there major changes to a whole business process?
Equally importantly, you need to be clear regarding what does not need testing, so you don’t waste time, effort and money testing things that have not been impacted at all.
So what tools can you use to solve these key challenges to PLANNING your E1 testing?
Well, until January this year it would appear that there was absolutely nothing. You may be surprised at that, as E1 is such a mature product. Although, if you really understand the complexities of the interdependencies of the objects, menus and menu items inside E1, it is no surprise at all.
This really was a very tough nut to crack, although DWS now has a very clever solution to the test planning problem. It is a product called Dimension Focus.
What it does in a nutshell is:
- Identifies what needs to be tested – and how thoroughly
- Identifies what does not need to be tested
It does so by investigating the programs that you use, and how they would be affected by the ESUs. Dimension Focus has the ability to analyse the lower level objects that are used by these programs, so for example, all the tables, business views and business functions etc.
Dimension Focus also knows about the interdependencies between these objects and can build up a multi-level hierarchy of how they are all interlinked.
Using this clever analysis, it identifies those objects that would be directly changed as a result of installing the ESUs. So these are the objects that Oracle has modified. This could as small as 5% of the total number of objects in your system, or less, even if you are installing a large number of ESUs. And also, due to the cumulative nature of ESUs, just because an object is included in an ESU, this doesn’t necessary mean that it has changed compared to the version of the object that you currently have installed. However, Dimension Focus will be able to figure that out, and exclude any objects that haven’t actually changed.
Using our knowledge of the interdependencies, we can also identify the top level programs that are affected by changes in the lower level objects.
The result of all this is to potentially reduce the number of programs that need to be retested by giving you the reassurance that they have not been impacted at the code level by any changes that Oracle has made.
In the fourth Webinar in this series I will show you how you can automate your testing without the need for expensive technical specialists.
Then in the final one I will address the issues involved in staying code current.
If you would like to register for any of the live webinars that support this series of blogs, or to view any of the event recordings, please use the registration links below.
Date Title & Registration
1 January 28th Planning your E1 Upgrade
2 February 11th Executing your E1 upgrade
3 February 24th Planning your E1 Testing
4 March 10th Automating your E1 Testing
5 March 23rd Keeping your E1 code current