Here's the way I look at it: we could bust our buttons working extra special hard to get rid of lots of bugs, but there's a really good chance that our users would never even have found many of those bugs.  So I ask you: what's the point of fixing bugs that no one will ever encounter? That is one very painful waste of time.

So instead, I suggest that we should practice "just in time testing" or JITT. Let's non-shorten it to JITTerbug. I encourage everyone to do the JITTerbug when it comes to testing: write some really cool software and put it out there. Don't bother with testing. Give it to the users as soon as possible. They sure like new versions of software almost as much as we like the latest CPU from Intel.  Then as soon as a user finds a bug, we fix it. We fix it really fast. They will appreciate us more than ever before, and we will have more time to, um, write more buggy code. 

Silly, huh?
Ridiculous.

It is especially ridiculous, because everyone knows that programmers (sometimes gracing themselves with the title "software engineer" – which I will never do. I have too much respect for engineers) are absolutely addicted to testing. We can't wait to start testing our code. We look for every opportunity to test. We beg our managers: "Please don't ask me to start another program yet. I want to spend a few more days testing, just testing."

Wait a minute, wait a minute. I am in the wrong alternate universe. I am sure (though the memories are fleeting) that I come from a place where developers love testing. But here, here....here things seem to be different. Here, developers seem to hate to test their code. They just want to have all sorts of fun solving the logical puzzle in front of their faces (ie, the program they need to write). They don't care all that much about how well it works, that it really and thoroughly works.

Programmers just want to have fun.

And...and...now I feel the same way. Poof! The last memory of my home universe is gone. Here and now in this universe, I am no longer addicted to testing. Instead, I sneak around in the office to avoid my manager, who might ask that most challenging and troubling of questions: "Did you test your program?"

AAAARRRRGGGHHH!
**************************************
Ok, you've probably laughed all you are going to laugh at that silliness. Or maybe I offended you. If so, sorry 'bout that! I am sure there are many true software engineers out there. I just know that I am not one of them.

And more than that, I know that developers do want to write high quality code and we don't want to ship code that has bugs in it. But we face some rather severe challenges:

·          Complexity of code: software generally attempts to model or assist in some way real world processes that are very complex. The software thus also is very complex. Unless programmers are extremely disciplined about the way they design and write their code, the resulting programs are almost practically untestable.

·          Deadline pressures: programmers routinely complain that they are not given enough time to build high quality software, and that certainly includes time to test (assuming they know how to write and run the tests).

·          Large code volume for testing: it is generally understood that the volume of code required to test a program will be larger, perhaps an order of magnitude larger, than the program itself. That is a very intimidating prospect. Most developers don't have enough time to simply get the program written, much less write thousands of additional lines of testing code.

·          Unless the testing process is fully standardized and automated, testing takes a lot of time. If it is left up to each developer to decide how to write test code, to manually verify results, etc., then it will simply be an impractical task.

·          Test code maintenance: even if a programmer writes a comprehensive test today, she must also maintain that test code as the program itself evolves. This requires an enormous amount of discipline.

·          Testing is hard work. Let's face it. Writing programs is an awful lot of fun, but writing and running tests (just thinking about things going wrong) is hard work. It is like being paid to solve Soduku puzzles. We would all love to spend our time solving the puzzles, without having to verify that our solution is thoroughly and completely correct.

·          Developers can get away with not testing: as noted above, software lies at the heart of virtually every human-designed system in operation today. Without programmers working their supposed magic, much of what we take for granted would come to a screeching halt. To put it simply, humanity can't survive without us and they will, so far, accept whatever they are given and struggle through the bugs. As Gregory Tassey, senior economist at the National Institute of Standards and Technology stated: There are very few markets where "buyers are willing to accept products that they know are going to malfunction, but software is at the extreme end in terms of errors or bugs that are in the typical product when it is sold."

Beyond the general obstacles to testing, developers in the world of Oracle PL/SQL face some additional challenges. The logic inside a program can be very complex. That complexity is increased by an order of magnitude, however, when the program also interacts with an underlying database. Oracle PL/SQL is the quintessential database programming language.

Almost every PL/SQL program written reads from and/or writes to one or more database table. Every table I/O is, in formal programming-speak, a "side effect," a dependency or impact that is not evident through the parameter list of the program. Side effects generally increase testing difficulty. When those side effects involve tables, however, the situation gets even worse.

PL/SQL programmers must be able to configure a stable, predictable control set of tables for their tests (both as inputs and expected outcomes). These tables are often very large in volume, requiring substantial amounts of time and other resources to establish.

Testing the contents of these tables is also very difficult. The SQL language used to query a table's contents is relatively easy with which to work, but the data changed by a program can be hard to analyze.

The community of PL/SQL developers is also relatively small, certainly compared to that of Java and .Net. While many vendors, including most notably Quest Software and of course Oracle Corporation itself, provide very useful tools, there is quite simply less investment and activity in programmer tools development than with other languages.

To conclude, it's not hard at all to understand why we don't test enough. The obstacles are clear, yet the cost of not testing is also very clear. What can be done to help PL/SQL developers test their code much more thoroughly?

Right now, the best and by far the easiest thing you can do is to check out Quest Code Tester for Oracle, available through ToadWorld (www.ToadWorld.com).

Quest Code Tester is a revolutionary new tool in the Oracle space that automates the process of creating and running tests on PL/SQL program units. With Quest Code Tester, forget about writing test code. Instead you describe your test requirements through a UI and then the tool will:

·          Store this information in a repository, providing a rich reporting database.

·          Generate test code (a PL/SQL package).

·          Run your tests.

·          Automatically report the results.

You've got to see it, try it, to believe it. We just released Quest Code Tester at Oracle Open World as a special pre-commercial release. It is entirely free through the end of February 2007, at which time we will release a commercial version, along with trial and freeware versions. I believe that Quest Code Tester will solve most of the problems listed above. Let me know what you think.