Testing method

gstruillou

Member
Hi list,

We are running with One World since last november and have encounted several problems for which we had (we have and we will have) to apply ESU.
As the ESU is to solve many problems and not only the problem for which we call JDE, it may have some influence on other parts of the software.
I would like to know witch strategy you have build in order to minimize the risk of having the software corrupted by an ESU. Of course we have intall several environnements (an a test environnement), but do we have to test the all software each time we apply an ESU? do we have to create a special testing group?
We will appreciate all your suggestions
Thank you

Best Regards
Gildas Struillou
Coopagri-Bretagne
OW Xe SP18 Upgrade 1
Unix Aix / Oracle
NT / Citrix
 
<FONT face=3D"Default Sans Serif, Verdana, Arial, Helvetica, sans-serif" si=
re is that JDE writes their ESUs against the latest update (i.e. Update 4).=
There is a chance that if you take an ESU that fixes something (i.e.=
P4210), there will be a problem that does not show up until you run Sales =
Update (R42800), even if the object was not included in the ESU.</DIV><DIV>=
The point is that there are some assuptions that are made by JDE when they=
create an ESU, and unless you are perfectly in line with these assumptions=
, you stand a chance to be dramatically effected.</DIV><DIV></DIV><DI=
ional area. Therefore, if you take a Sales ESU, you may not have to f=
ully test Procurement. However, if you are testing Sales, be sure to =
take the process through A/R & G/L.</DIV><DIV></DIV><DIV>If the "=
fixes" are significant enough, we will generally perform full functional te=
sting (the ENTIRE system) before moving them to production.</DIV><DIV>&nbsp=



Adam Clark
Project Manager
Golden State Foods -- Information Services
 
Back
Top