Review in The Hindu Business Line
COMPUTER books tend to be fat and daunting, especially if they're about software. Therefore, it comes as a welcome change to see Rajnikant Puranik's illustrated guide to software testing, titled The Art of Creative Destruction, from Shroff Publishers & Distributors (www.shroffpublishers.com) .
In the foreword, one is struck by the frankness of L.N. Rajaram, director of Advanced Information Services and The Watts Humphrey Software Quality Institute, who writes: "Every other industry would consider it an extremely unethical practice to pass on to the customer products of the levels of quality found in software products."
For the Indian software industry to leapfrog into top slot as software producer, the driver has to be software quality, emphasises Rajaram, making the book eminently relevant for the purpose.
Puranik's work should be useful to bankers because of the many examples he cites in the book, based on his experience in heading the development of core banking and treasury products.
"Testing is an area not just for testers," writes the author, inviting you, as a user, to taste the wisdom in the pages, beginning with a Russian proverb: "Trust. But, verify." What seems simple may actually be quite complex, reminds Puranik.
The book presents information in bullet points and flowcharts, tables and diagrams, so it should be easy to grab the inputs on the go.
For instance, the chapter on automated functional testing has graphic depictions of broad automation components, domain testware, test data, test automation `artifacts', test repository, regression testing, and so on.
Puranik presents `a few guidelines for selecting test-data for a banking application.' These include suggestions on using EP (equivalence partitioning), and BVA (boundary value analysis), plus advice not to ignore illegal values and extreme ones. Don't forget the maxim: "There is 99.9999 per cent chance that what is not tested would also not work."
Effective testers have seven habits, lists the book. These include: "They uncover error in the code, not in the person. They know that part testing is no testing. They test with both valid and invalid inputs. They check if the system is doing what it should, and also if it is doing what it should not. They automate as much as possible, as early as possible."
However, what's common is to find ineffective responses from developers when you report bugs.
They may say, "I had fixed that! Somebody must have changed something in that."
Or, one or more of the following: "Must be a hardware problem. That's a feature. You logged in as what? It is as per the specifications. That's what I was told it should do. That's strange. I think your PC is infected. It worked yesterday. That's not possible. There's something illegal in your data. You must be using the wrong version. That's some weird coincidence. I can't test everything! It's working fine, only it's yet to be tested. Why do you want to do it that way?"
A book not to be missed!