|
AFAIK You cant sell ISO products created by non-iso co-producers.
I agree that ISO is not bad, ..is good I would say.
And the paper work it creates is just a matter of good management (computers can be very helpfull here ). Bad manager will always have problems, even without paper work.
BTW I am working in the company with ISO 9001. I cannot imagine working without ISO. I was working earlier in one, which had no ISO - and this was like: I never knew what to do, who is who, where to search, what I can, etc.
Have a nice day!
|
|
|
|
|
It sounds like your company has figured out how to use ISO productively, so it's an asset to your operations, not a hinderance. Cool!
Marc
|
|
|
|
|
The great thing with ISO is that you can (within a range) adapt it to your special process. But then you are forced to stick to it.
So, it really pays to have a good, smooth working development process. You even are encouraged to do process improvement, but you HAVE TO do that according to a clear plan with measurable goals and changing states of the project and so on.
I know this, because we had the testers in our group just 2 month ago.
Their saying was :"Do what you want but have a plan for what you are doing and stick to it."
|
|
|
|
|
Marc Clifton wrote:
and I loved the concept of ISO 9000. Everyone else hated it.
Same here, concept wise I like the idea. But I hate paperwork.
Regardz
Colin J Davies
Sonork ID 100.9197:Colin
You are the intrepid one, always willing to leap into the fray! A serious character flaw, I might add, but entertaining.
Said by Roger Wright about me.
|
|
|
|
|
I believe that if your programmers work closely with the testers, and participate in the testing process, that complicated standardized testing paradigms such as ISO9XXX can be avoided. However, I have to admit, I've never led or worked on a humungous projects.
Paul Oss
|
|
|
|
|
Small sample so far, but still - I hope not too many other companies do not have a testing department. The testers can be a pain sometimes, and it's a thankless job, but I have no doubt our products are better for it.
Christian
Hey, at least Logo had, at it's inception, a mechanical turtle. VB has always lacked even that... - Shog9 04-09-2002
During last 10 years, with invention of VB and similar programming environments, every ill-educated moron became able to develop software. - Alex E. - 12-Sept-2002
|
|
|
|
|
I don't think enough punch is given to QA in most places, or TQM or whatever, It seems like a lot of QA depts are staffed by wanabe coders who never made it.
If QA paid more things would be better.
Regardz
Colin J Davies
Sonork ID 100.9197:Colin
You are the intrepid one, always willing to leap into the fray! A serious character flaw, I might add, but entertaining.
Said by Roger Wright about me.
|
|
|
|
|
Back when my company had a QA department, they had one position that was specified for a software engineer. Naturally, he was the guy who tested all of the software (we're a hardware company).
Unfortunately, they could never keep the position filled for more than 12-18 months at a time. Anybody good enough to do the QA job, was good enough to be writing the code he was testing.
Which would you rather do?
Gary R. Wheeler
|
|
|
|
|
We don't have the resources for a formal QA department. However, we have hardware devoted to testing and software to automate much of the process.
Tim Smith
"Programmers are always surrounded by complexity; we can not avoid it... If our basic tool, the language in which we design and code our programs, is also complicated, the language itself becomes part of the problem rather that part of the solution."
Hoare - 1980 ACM Turing Award Lecture
|
|
|
|
|
I'm not impressed with the fact that a company has a testing department. You can have all the testing departments in the world, but if the communication between development and testing isn't there, a testing department can actually hurt the process. I've certainly seen the results of this after we got 'corporatized'.
Paul Oss
|
|
|
|
|
Having testers guarentees nothing, not having them guarentees less. Of course it's important to communicate with the testers and have a system in place so that everything works as it should. Having no testers will NEVER make a product better than having them though. At the end of the day, the product is what the programmers write, the testers have an opportunity to provide feedback and information, it's up to the programmers to do something about it, and up to management to provide systems where information flows freely.
Christian
Hey, at least Logo had, at it's inception, a mechanical turtle. VB has always lacked even that... - Shog9 04-09-2002
During last 10 years, with invention of VB and similar programming environments, every ill-educated moron became able to develop software. - Alex E. - 12-Sept-2002
|
|
|
|
|
Christian Graus wrote:
Having testers guarentees nothing, not having them guarentees less. Of course it's important to communicate with the testers and have a system in place so that everything works as it should. Having no testers will NEVER make a product better than having them though.
I agree. I didn't mean to make it sound like I was against testing. I'm not. I just don't think that having a QA department with people having 'QA' in their job title fixes anything by itself. If the organization isn't there, you might as well have the 'receptionist test it in her spare time'.
You have to have a good communication conduit between your testers and your developers/coders. If you don't, the results can hurt real bad.
Paul Oss
|
|
|
|
|
In our company, the programs test it, and then it is sent to the QA for their final approval. The QA is staffed with trained people,and the product is not delivered unless QA approves it.
|
|
|
|
|
Nandita wrote:
In our company, the programs test it, and then it is sent to the QA for their final approval.
I think that falls into first option: "QA department staffed by trained testing professionals."
I C++, therefore I am...
|
|
|
|
|
Two or three options really apply in our case.
1. We write it and test it.
2. We give it to the in-house development chemists who chuck 1000's runs at it (QA)
3. We have novice in-house users who also test it (a la receptionist)
Testing, a very important part of any product. Preferably, the programmer catches most of the problems before they ever get out to be tested by anyone else, this spares
Roger Allen
Sonork 100.10016
I think I need a new quote, I am on the prowl, so look out for a soft cute furry looking animal, which is really a Hippo in disguise. Its probably me.
|
|
|
|
|
We test it, the receptionist tests it, the client services director throws junk data at it (not purposefully, he's just that way inclined - and it helps us!), and that way we muddle through...
The following statement about your geekness is true. The previous statement about your geekness is not true.
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/IT/P d- s: a- C++++$ UL+>++++ P+ L++$ E- W+++$ N !o K+ w++$ O---- M--
PS- PE Y+ PGP--- t !5 X- tv b+++ DI++ D+ G++ e++>e+++ h--- r+++
------END GEEK CODE BLOCK------
|
|
|
|
|
This is a good process. We set up that process here in the shop I work on (well, we used to have it... long story). The programmers were, in effect, responsible for alpha testing all the software. I wanted it this way because as far as I was concerned, the alpha testing phase was too close to the design and coding process. Then, when the programmer felt comfortable that all the obvious flaws were gone, it went into a kind of pre-beta with our 'testers'. Then once they couldn't find anything, it went into beta on several hand picked clients. Once we were satisfied there, we expanded the beta on another block of clients. Once all those clients were no longer reporting anything, we went to release. This whole process was admittedly informal, but it was incredibly effective for a company which had very limited resources.
It's not a process which would fit all environments. Ie, you don't want your software systems controlling the fly-by-wire system on a 767 to follow this process. But for business apps, it worked great.
Paul Oss
|
|
|
|
|