Advice on exclusion of 7.5.2 of the ISO 9001:2000 Standard

[KateE]

Hi All,

We have had our QMS in place (and registered for 4 years) and throughout that time we have had an exclusion for 7.5.2 of the standard.

Basically the company I work for is a sofware company that provides messaging solutions and results and reporting solutions for health organisations such as the NHS.

Although we do thorough testing of the products before they are released and installed on site, we can not test every aspect and bugs / issues are found by customers when they use the software.

I know that we have passed surveillance audits every year, but part of the reason that this has happened (i feel) is because the external auditor we have had has no idea about our industry (its very specialised) and little knowledge of programming / IT as a whole so is easily bamboozled by jargon.

I don't think we should be excluding this clause, but I'm struggling to get my head around it - can anyone offer any advice?


Thanks
Kate.

 

[Big Jim]

Re: Advice on 7.5.2 of the ISO 9001:2000 Standard

I'll be interested to see how others perceive this as well.

I've always leaned toward this clause applies to tangible product rather than something more intangible such as software. In the AS standard there is an added note that this applies to "special processes". Some of the things that are usually considered to be "special processes" are welding and plating since the outcome is not fully evident from subsequent inspections without destructive testing.

Although I do see the need for robust validation of software, I don't picture such testing as destructive.

My thinking may not be sufficient so I'm anxious to hear other perspectives.

 

[bobdoering]

Re: Advice on 7.5.2 of the ISO 9001:2000 Standard

Although we do thorough testing of the products before they are released and installed on site, we can not test every aspect and bugs / issues are found by customers when they use the software.

My interpretation is that you have design criteria for your software. You validate that the software meets that criteria prior to sale. If the customer finds an issue that was not a part of that criteria, that is not quite the same as verifying the function of the software that can not be verified in-house and must be verified in the field.

On the other hand, beta testing may qualify for meeting this. Do you do any of that?

There may very likely be other opinions. I am betting on it!

 

[KateE]

Before we install sofware on site we do alpha testing (those who wrote the code testing it before moving onto the next phase) and then beta or peer testing (other people doing a full test of the code and the version release). BUT, because of the nature of our business, we can't test the interaction of some of our code with the lab systems etc because we don't have them - that testing has to be done on site, once installed (this may be in a 'test' environment or 'live' environment).

 

[somerqc]

I think you can keep your exclusion. What you do need to show that is you have modified your testing methods if similar bugs keep being found.

Basically, you can test everything so long as you know to test it. Use "bugs" to determine where your testing protocol may be weak and fortify it. Now you show that your exemption still applies AND you can show continuous improvement!

John

 

[KateE]

Thanks for the responses.

As I mentioned in my reply, we sometimes have to install code onto site in an almost untested state because we do not have a copy of the lab system, for example, that we are interfacing communicating with, at our offices, so cannot test the interaction - do you get what I'm saying?

Its not a straight forward situation and drives me mad!!

 

[somerqc]

You can test it though! You are testing on-site before truly going "live" no?

Do you have UAT? (User Acceptance Testing) or some other version?

I am not in the field just married to it...(wife is the expert - being in quality we often combine brains on this type of stuff)

 

[bobdoering]

You have made some compelling arguments to support inclusion. If you did, what would you differently than you do now, or do you really meet it now, and just need to audit your process?

 

[Coury Ferguson]

KateE,

By your own definition of what the process is for your software, I would say that you can not exclude 7.5.2 of ISO9001:2000.

My opinion is based upon the following:

There is code that can't be validated until installed, and subsequent validation is performed by the Customer(s) which means lightly, there are deficiencies that are noted During and after the installation of the software. As 7.5.2 states (paraphrazed)"...deficiencies become apparent only after the product is in use or the service has been delivered." But, this is just my opinion.

 

[KateE]

Coury, I agree with you 100% and I have just spoken to an independant external third party auditor (who is also a trainer and took me for my lead auditor course) and he agress with you (and my thoughts) that we should not be excluding this clause.

I am going to raise this to the board's attention and then change the documents to include it.

I am not happy that our external auditors have not only allowed us to include this as an exclusion, but haven't questioned or queried it at each surveillance audit we have had.

We will be changing our external auditors.

Thanks for all the advice guys.