Test driven development?

"Mike Turco" schreef in bericht news:o4wVc.116279$sh.25205@fed1read06...

reasonable

back

than

So you dump it on the testers ;) Well, testing is boring, and it nice to have testers. And to make the testers' job a bit interesting, of course we will give them some bugs.

--
Thanks, Frank.
(remove 'x' and 'invalid' when replying by email)

"Frank Bemelman" wrote

We are honor bound to do so. After all, these folks have families to support.

Isn't this just an example of deficient requirements capturing. Basically it was a "typical" use case that your software wasn't designed for -- and I'm not really talking about an obscure use case. Having a good "tester" finding non-trivial validation flaws in the software like the one you described, would certainly shatter my confidence in whether the software is fit for use.

Also my observation is, writing better, tighter & less error prone code would not have significantly "fixed" the problem in this case (you were already doing most of this) as the fix to the problem would have required architectural changes to your software.

If better analysis had been performed on the use cases, these exceptional cases would have been revealled -- that's why experts are generally employed.

Ken.

+====================================+ I hate junk email. Please direct any genuine email to: kenlee at hotpop.com

"Ken Lee" wrote

Hi Ken,

I agree with what you're saying, but there's a dose of reality involved, too. I'm not a big company, I'm self employed. Many of my customers are small companies, too. The idea is to do the best you can with the money, time and resources that you have. Certainly, not taking on jobs you can't handle is a big part of that, and I think that's where a lot of consultants screw up.

When I was consulting -- which I still do occasionally -- I was usually hired because I brought something unique to the table in terms of skill and aptitude. "Requirements", to my customer, usually meant functional requirements. Product quality, in this case, means doing a good job. There is no way in hell for me to bring in a quality engineer or a statistician on-board for Joe Co's tape recorder on/off timer project.

Bottom line: business is business. We can talk all we want about creating an ideal situation, at every level, to complete a project. The fact is we have too little time, not enough money, hardly any memory space, funky compilers and way too much pressure. I think I've done a damn good job on all of the projects I've done over the years: my products keep on working and the customers are happy.

Mike

Hi Mike. I appreciate your comments and understand the constraints you work to. My previous comments were intended to expand on this discussion's thread, which included the unfavourable practice of "test dumping". The other abhor practice is using "test" personnel to uncover requirements.

Ken.

+====================================+ I hate junk email. Please direct any genuine email to: kenlee at hotpop.com