"Building a Better Bug Trap"

[sheila miguez herndon]

Here's an interesting article in the Economist (though a little short on
details)

http://www.economist.com/science/displayStory.cfm?story_id=1841081

The article reviews a few methods of testing and talks about some recent
advances, one called "binary matching":

"So Mr Srivastava has devised a system called Scout, which compares the
old and new versions of the program using a technique known as “binary
matching”. This determines which bits have changed, and then works out
which test scripts need to be applied. ... Scout can be used in other
ways, too. The number of test-scripts needed gives an idea of how far-
reaching the modifications to a program were."

And it mentions a group doing automatic test generation:

"Agitar, a start-up based in Mountain View, California, believes it is
possible to go a step further. It has devised a testing system, called
Agitator, that examines a program and devises test-scripts
automatically."

Is anyone here involved in work like this who could provide some more
details? It's interesting stuff.

--
sheila

[Rudi]

> sheila miguez herndon wrote:
Here's an interesting article in the Economist (though a little short
on details) http://www.economist.com/science/displayStory.cfm?story_id=1841081 The article reviews a few methods of testing and talks about some
recent advances, one called "binary matching": "So Mr Srivastava has devised a system called Scout, which compares
the old and new versions of the program using a technique known as
“binary matching”. This determines which bits have changed, and then works
out which test scripts need to be applied.
That sounds like one of the approaches for "testing" Year2000
corrections, in other words, not new. The fun part of it is, that
although it is clever from an engineering point of view, it has
virtually no benefits for testing.

Although it sounds handy, having a tool for determining what part of a
program has changed, it has no value for testing, unless the impact
of the change can be determined. So to speak, determining what
"crossing" has changed doesn't give you a clue about the number of
roads that go over that crossing.

It could be beneficiary for the engineering or legal department
though.

Just my two (euro or dollar) cents worth,

Rudi


Posted from the Dutch software testing community at www.testforum.nl

[jcornado]

The Economist has been publishing over the last 2 years articles along
those lines. Also Business Week has just published another tech
section.

It is quite good. They point out the need to become more like GM, I
would say more like Toyota given the state of Detroit these days. Also
they point out the bad grades that enterprise software quality
receives.

A huge majority of tech companies are wasting companies' money in a
really stupid way: buyers know that new releases are extremely buggy
(some of them remain buggy even after several support packs) so they
wait for those support packs to really buy the product.

The question that arises is: why do the companies spend some much
marketing money in launching a new product? Buyers aren't buying new
releases. At best marketing campaigns are becoming longer and more
expensive because of below par products.

The marketing campaigns these days seem to be just a trap to lure
customers to try the products and find the bugs that should have not
been there.

The bottom line is that most software companies still have not figured
out how to create long-term value. The project-short-tem-itis is one
of the worst problems that the industry has.

sheila miguez herndon <sheila+news@feafaroth.org> wrote in message news:<Xns93A766A2DE809feafaroth@129.188.7.11>... Here's an interesting article in the Economist (though a little short on details) http://www.economist.com/science/displayStory.cfm?story_id=1841081 The article reviews a few methods of testing and talks about some recent advances, one called "binary matching": "So Mr Srivastava has devised a system called Scout, which compares the old and new versions of the program using a technique known as ?binary matching?. This determines which bits have changed, and then works out which test scripts need to be applied. ... Scout can be used in other ways, too. The number of test-scripts needed gives an idea of how far- reaching the modifications to a program were." And it mentions a group doing automatic test generation: "Agitar, a start-up based in Mountain View, California, believes it is possible to go a step further. It has devised a testing system, called Agitator, that examines a program and devises test-scripts automatically." Is anyone here involved in work like this who could provide some more details? It's interesting stuff.