intertwingly

Heh. That's funny.

Oh, wait. It wasn't said in jest.

Testing does not make the software better; instead, it just discovers that the software is lousy. Or not, as the case may be.

People make software, so there are as many reasons lousy software is made as there are people making lousy software.

It's the lazy programmers that test their software better - we don't want to get bogged down in QA, so a bit of time building a habit of test classes and the like gets us out drinking while the other poor sots are responding to bug reports :-)

Let's get my domain name spelled right :-(

I was taught that "one can't test in quality". Since then, I have seen my share of overdesigned products that don't meet customer's needs.

XP is a set of best practices. My favorite is Code the Unit Test First.

The linked article goes against conventional software engineering wisdom and my own experiences.

Claiming that testing is the final arbiter of the quality of software and not the software development process (I guess the Capability Maturity Model is crap then) is like claiming that the top speed of your car is more dependent on how good a driver you are than the engine in the car.

Nice sentiment, too bad it doesn't jibe with software engineering research and industry experience.

>> Testing does not make the software better; instead, it just discovers that the software is lousy. Or not, as the case may be. <<

As a consumer, I don't care how much lousy code a software company turns out as long as it doesn't reach me. From that standpoint the statement that inadequate testing is the reason for lousy software stands.

>> XP is a set of best practices. My favorite is Code the Unit Test First. <<

As a software producer this is what is going to allow my company to get to the good code to release so much sooner and at a lower cost. The statement still stands.

>As a consumer, I don't care how much lousy code a software company turns out as long as it doesn't reach me.

How does testing prevent lousy code from reaching you? I'd assume the only way to prevent lousy code from reaching you would be for the company to write good code. Most entities that write good code have a combination of good people and good processes.

Dare - I'm quite a bit surprised by your reaction. Who said that the SEI's CMM is crap?

Perhaps the real problem is that in many places, testing is "bolted on the side" of the development process, and the result is something that both software engineering research and industry experience has shown to be underwhelming.

Your mention of "good people" is reminiscent of the description some give to CMM's level 1: "worship the hero".

It is my belief that to attain a higher maturity level, testing must be an integral part of the process.

The original quote from Cedric is

"No. The reason for lousy software lies in two simple words.

Inadequate testing.

It has nothing to do with the process that was used to develop the said software. Open Source, closed Source, XP, object-oriented, C++, UML, etc..."

I am not saying testing is unimportant, definitely not. However it is not the primary arbiter of quality in the software development process. I'd rather use software that went through code audits, design reviews, and was formally specced out than one where the code was hacked out and quality was "tested in".

I am not saying testing is unimportant, definitely not. However it is not the primary arbiter of quality in the software development process. I'd rather use software that went through code audits, design reviews, and was formally specced out than one where the code was hacked out and quality was "tested in".

If you write the test first...then you think through and write your best understanding of the requirements into the test. So the code must do what the test specifies. Making the test (which specifies input and verifies output) correct is a very small subset of the effort required to guess the code correct.

The linked article goes against conventional software engineering wisdom.

Challenge: Name 5 extremely successful software product/project that resulted from "conventional software engineering wisdom."

Now name 10 that didn't.

Which took longer?

Dare, regardless of what practices a company uses, unless there is a test then you don't know whether the software is good or bad. Testing is the final arbiter on whether the software is good or bad.

Now if the company goes ahead and releases software that doesn't pass quality assurance tests then you are absolutely correct, testing will not prevent the software from reaching me.

Justin,
You are confusing testing being an indicator of the quality of software (conventional software engineering wisdom) with testing being the primary influence on software quality (the original statement which I am disagreeing with).