in reply to Re: Parallel maintenance on many projects, part II: The Testing
in thread Parallel maintenance on many projects, part II: The Testing

Checking only things that you think have changed is a heck of a lot of coding for significantly less benefit. That extra coding introduces even more bugs and more maintenance time, but doesn't add any benefit. Anything I can catch by testing only things that have changed I can catch by testing everything.

Never assume that the world is a perfect place. If I can test everything every day with as much effort (or even less effort) than trying to be clever about it, I'll check everything everyday. Computers are designed to do mindless tasks over and over again.

Unless you are looking to waste time, once you accomplish the task, move on to the next thing on your To Do list. :)

I like Joel Spolsky's take on this sort of thing: Fixing bugs is only important when the value of having the bug fixed exceeds the cost of the fixing it.

--
brian d foy <bdfoy@cpan.org>
  • Comment on Re^2: Parallel maintenance on many projects, part II: The Testing

Replies are listed 'Best First'.
Re^3: Parallel maintenance on many projects, part II: The Testing
by pg (Canon) on Sep 26, 2004 at 19:35 UTC

    I believe the approach you took is right in your case, and I really like the quote at the end of your post.

    However, in general, I think it depends on the size of the project, and the amount of effort required to test everything. There are projects that could not be possibly tested in one day, or one week, or even one month. A way to tailer test cases has to be there, in general. Don't misunderstand me, I am just trying to add some thoughts, not saying anything is wrong in your particular case.