begin quoting Bob La Quey as of Fri, Oct 31, 2008 at 01:19:47PM -0800: [snip] > > I suggest then that the core problem becomes, "How does one make test > and bug fixes fun?" > > It is not obvious to me that they cannot be fun.
There are some people who take great joy in writing/running tests. If that's what they primarily do, they're often looked down upon by the "non-test" folks. Testing isn't always seen as having value, so those engaged in it are engaged in less-valuable activities, and treated as such. Management sometimes looks at testers as if they're an expense -- almost like they think the testers are introducing bugs rather than discovering bugs. They *say* they want testing, but the act otherwise. Fixing bugs is more fun once there's a framework of tests in place, and adding tests to a well-tested product (especially when there's a bug) is a lot nicer than trying to set up a test when there's no suite of tests in place. Some open-source projects welcome bug reports from users, and a report of "it doesn't work with error message $X" gets a prompt reply and some questions from a developer. Those projects are *fun* for end-users to report bugs for, as it lets them contribute. Other projects make it difficult to provide bug reports, and when a user finally figures out how, the bug is often closed immediately with "can't reproduce" or "duplicate of bug $Y", or worse, it languishes, un-commented on, for a long time. That's not so fun. > Alternatively is there some automagical (i.e. a program runs) to find > and test edge cases? Someone still has to write down the rules in a way the program can understand. I recently had a bug where a bad or missing configuration value resulted in a default value being used. That's what default values are for, right? But in this case, it gave undesired behavior. The fix replaced two lines of code with twelve, and broke the system's philosophy of "be forgiving of the contents of the configuration file". I don't think that could have been caught with anything automated, given that it was an (unconsidered) special case. The test, however, was pretty simple, so /that/ bug won't show up again. -- Reward testers. Stewart Stremler -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
