The quote only goes so far. Take an extreme example: you test every input possible and make sure it generates the proper output. Wouldn't that be bug free? In the real world, proper boundary value analysis (white box) does pretty much the same thing.
Ah, but we all know that it is next to impossible to test every possible input, even for relitevely simple applications. I think that the whole point of the quote is to make sure that people understand what testing is and what it is not.
I don't want to start the dispute here, but boudary value analysis (no matter how well done) is far from proving that the code is not buggy. The hardest part is to test the app when you have multi-threaded app, where things can really go out of hand. So, the quote, no matter how vague and obsolete, is sadly true.
You can make it hard or easy to test an app, it all depends on how you build it. You have to write code so that it is easy to (unit) test. If you have to do everything through the UI (manual), then YES, testing sw would be very hard. And I know, you can get things that push through the UI, but it's a lot slower usually, and not easy to get very granular.
I think that's a pretty pessimistic view of testing, and will only reinforce people's opinions that testing is more useless than it is, or not worth the time. That quote, taken literally, discounts the fact that one could test all of the inputs to a function quite explicitly. It's impractical but still possible. I think as engineers we should keep that in mind.
I think maybe where we are disagreeing is the perspective. Sure, application wise it may be more difficult to prove there are no bugs. But if you isolate a small portion of functionality it can be relatively painless.
The quote only goes so far. Take an extreme example: you test every input possible and make sure it generates the proper output. Wouldn't that be bug free?
ReplyDeleteIn the real world, proper boundary value analysis (white box) does pretty much the same thing.
Just to add to that point: if you think that testing an app well is hard, you are doomed to make buggy software.
ReplyDeleteAh, but we all know that it is next to impossible to test every possible input, even for relitevely simple applications.
ReplyDeleteI think that the whole point of the quote is to make sure that people understand what testing is and what it is not.
I don't want to start the dispute here, but boudary value analysis (no matter how well done) is far from proving that the code is not buggy.
ReplyDeleteThe hardest part is to test the app when you have multi-threaded app, where things can really go out of hand.
So, the quote, no matter how vague and obsolete, is sadly true.
You can make it hard or easy to test an app, it all depends on how you build it. You have to write code so that it is easy to (unit) test. If you have to do everything through the UI (manual), then YES, testing sw would be very hard. And I know, you can get things that push through the UI, but it's a lot slower usually, and not easy to get very granular.
ReplyDeleteI think that's a pretty pessimistic view of testing, and will only reinforce people's opinions that testing is more useless than it is, or not worth the time.
ReplyDeleteThat quote, taken literally, discounts the fact that one could test all of the inputs to a function quite explicitly. It's impractical but still possible. I think as engineers we should keep that in mind.
I think maybe where we are disagreeing is the perspective. Sure, application wise it may be more difficult to prove there are no bugs. But if you isolate a small portion of functionality it can be relatively painless.
ReplyDelete