Prasanna

« When you get stuck... | Main | Creativity and Techn... »
pageicon Wednesday May 30, 2007

The problem in Software testing

The easiest part is writing a piece of code, the toughest part as obvious is testing it. Code in a day and it takes the rest of life to test it. There are no limits in testing an enterprise software as it starts with sanity tests, followed by black box testing, white box testing, regression testing, load testing, performance testing, I don't want to write the rest, please visit here .

The question is will any software truly pass these tests as and when applicable or is there a proper process and procedure to carry out these tests. The obvious answer if NO. The reason why all these tests are never carried out is that it will so badly expose the serious flaws in the software and as we dig deep into testing, we can only get hands dirty similar to digging deep in a soil. And as a result no product can ever be released successfully in time (it's a fact).

But what can be done systematically to overcome these so called bugs? The easiest way is to make them as Known issues in case the bug is so complex, therefore fixing it may cause a break in functionality. The second simple way is called Hot fix, in which you simply comment that part of the code. But these things don't solve the issue in first place. They say prevention is better than cure. Therefore one needs to prevent bugs right from day one. With techniques like Test first development coming to the rescue of developers, the question is whether these techniques are followed during development in these days where a product has hard and fast deadline? Again the simple answer is it's often not possible.

Therefore the best solution as far as bugs are concerned is fix bugs for sometime and call it a day. Then take the bugs as and when it comes in the form of escalations and update the software with a clearly documented list of fixed bugs , because after a period of time, bugs has to come to us and it's nearly impossible for the us to go behind identifying it.

Posted at 08:22PM May 30, 2007 by prasanna in Tech  |  Comments[2]

Comments:

You could just start off with simply writing unit tests, as practised in Extreme Programming, while coding. Keep in mind though, that unit testing is not about finding/discovering bugs--although in practise it does tease them out--but of simply testing a unit of functionality for correctness. The unit tests also become artifacts in how a class/function is used and thus self documenting.

http://en.wikipedia.org/wiki/Unit_testing

You may want to give it a go, you may find that it will increase the rate at which you can generate functionally correct code.

From what little I know of TDD, I think it's similar to what Extreme Programming advocates, i.e., unit tests should be written while one is coding.

NB: if you don't write test even under a hard deadline, it'll just mean that the release will probably be further delayed because you'll be fixing more bugs but at very high level, i.e., digging through multiple layers of code to isolate a bug. The worse bit is that because you don't have any unit test, you'll never know at the code level whether your bug fix breaks something else. This is not to imply that unit tests are infallible but they do give you a way to modify (fixing bugs) code and to concretely determine correct behavior other than reading the code. Having this additional support is what unit testing is about. The other benefit is that aggressive refactoring becomes tenable. Without it you'll be a slave to old code.

Posted by Mike Lee on May 31, 2007 at 01:00 AM IST #

"if you don't write test even under a hard deadline, it'll just mean that the release will probably be further delayed because you'll be fixing more bugs but at very high level"

Absolutely right.

Posted by Prasanna Seshadri on May 31, 2007 at 06:42 PM IST #

Post a Comment:
  • HTML Syntax: NOT allowed