|
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
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
