View Full Version: Sample Testing Matrix

LawsonTalk > General > Sample Testing Matrix


Title: Sample Testing Matrix
Description: Patch Testin


bbhiemer - May 6, 2008 07:21 PM (GMT)
We are ISeries and finally making the move to install MSP2, and then we are going to use the patch installer to install every patch on a monthly basis. Would anyone have a testing protocol they use after patch installs? We are only running HR and PR, SEA. Please send any samples you may have to tkahl@gmrc.com.

Thanks.

schroncd - May 6, 2008 08:51 PM (GMT)
B A D
I D E A


Lawson has ALWAYS stated you should only install patches to fix issues that you have encountered. It is niether wise nor efficient to install them all.

I applaud your monthly patching sessions, but for your own sanity and the health of your system DO NOT try to install them all.

3monkeys - May 7, 2008 03:51 PM (GMT)
Even if you're only using HR and PR modules your testers/users would be constantly testing their applications. I agree with Dave that you may not want to adopt the practice of applying every patch that comes out, even on a monthly basis. It really isn't worth the hassle. You'd be applying and testing patches that don't apply to your setup (Canadian payroll issues, for example).

Keep up with MSPs and only apply the patches you need to correct a problem you're having.

Aside from that, our testers in HR/PR typically test their "key processes", including running a full test payroll. Don't forget to actually print a sample of the PR checks, even if on blank stock.

-GW

bbhiemer - May 7, 2008 07:14 PM (GMT)
Thanks for those replies, a bit of history maybe... we have always only applied fixes that we find problems for however every time we have to apply one of those we end up spending weeks with Lawson because we find out there was another patch that actually put in some change that we were not aware of. We can not rely on their scrips in the info of have to apply following first, so we thought we would give their way a try for a while.

kate - May 9, 2008 07:28 PM (GMT)
-- schroncd, what do you think? --

For the record: I'm an HR Application consultant, and I know there's more technical stuff going on with the system than I'll ever understand.

HOWEVER...

...a comment below from bbhiemer got my attention (in the quote below, changes to "every time" are mine):

QUOTE
...bit of history maybe... we have always only applied fixes that we find problems for however every time we have to apply one of those we end up spending weeks with Lawson because we find out there was another patch that actually put in some change that we were not aware of.  We can not rely on their scrips in the info of have to apply following first...



Recent clients for my HR/PR consults are ISeries, and when PATCHES are discussed, I hear the same thing from all of them, including phrases like:
every time
can not rely

ouch

Does Lawson know how PAINFUL this is for their ISeries clients?

bbhiemer - May 12, 2008 02:53 PM (GMT)
I should have also said that Lawson is now recommending strongly that for ISeries clients ARE to install every single patch regardles of what modules you are using etc. They have been saying this for about the last year instead of just apply what is broke.

roguewolf - May 12, 2008 05:48 PM (GMT)
I was considering this question over the weekend. I don't know why and I am not sure I would be comfortable with the answer if I did know. In any case, I come down pretty firmly on the side of putting every patch in.

For the sake of full disclosure: We are an AIX/db2 shop and currently do NOT put every available patch in. If only I ran the world...

So here is my justification. Every single time we call in an issue to GSC, the very first question we are asked is "what version?" This happens before GSC even attempts to duplicate the issue. If we do not match up to the latest version of the screen/pd/lib in question, what's the first step? Update, of course. This is true even if programming/logic is the same and all the ctp is going to do is change is the version number of the screen (I can remember a half-dozen times that this has been the case).

So, if GSC is not really even going to look into an issue until you have the latest version, it seems to me that, in the larger picture, you are actually saving yourself time and energy.

I do generally agree with the sentiment that if something ain't broke, don't fix it. However, if your testing is thorough, repeatable and complete, you should be able to automate the process and identify specific issues prior to going into your production box.

I have more thoughts on this, but I think I will see how this thread progresses first.

In any case, best of luck,



Hosted for free by InvisionFree