Test Scripts

I am currently working on a project where the user group purchased the validation package from a 3rd party vendor. In doing a pre-execution review of the test scripts, there are a few things that I know isn’t the right way to handle them, but I also know that the user group will not blindly accept my “we need to make sure that we cover X, Y and Z” and I need to prove it.

X would be - tests steps that start with “Verify or modify the following” and you are changing test configuration within a test

Y would be - test steps that have multiple expected results - if you make a change you will get this, if you didn’t change anything you will get this (see X above)

Z would be - I have granted access to a user that they are allowed to access a new site within the system, however it is never tested that they can actually access it, or that if they don’t have access to a site they are not able to access that sight.

I was “brought up in validation” going with - 1 action 1 expected result, systems should be configured before testing starts and you are to test the configuration that you are going to be using and not changing it on the fly, and if you state that you have a role that should be able to do something you test that someone without that role cannot do the task.
I need to find a quick - none fda/gamp-ese that will help support me.

any ideas? adivce?

Gosh, kind of hard to know where to start.

First off, why does the user community care how the package was validated?

Do you have a set of user requirements? If not, just exercising a canned validation package won’t give you a validated product in your environment / for your use.

Somewhat along those lines, do you have a validation plan? Is there anything there you can ‘fall back’ on to justify what you know needs to be done?

I think the general approach to canned validation packages is that you, indeed, tailor them to meet your installation. And there should be nothing preventing you from supplementing the package with tests to verify your specific requirements (I’m trying to address the user / access question).

Without knowing more about what you’re doing, what your company culture is, etc., it’s hard to give useful advise. Hopefully this helps some.