1. Describe fully the required functionality of the program.
Don’t start coding until you are sure you understand what is needed. We developers like to jump right in and start coding, but that can be a very bad idea. Remember: you are not just a cog in the big wheel of business. You are a critical player in the deployment of applications; it can't happen without you. So please be ready to engage with your user on all levels (technical, business, ethical, etc.) to ensure that you know what is needed, and you are comfortable with what you will be building.
The fundamental point here: think first about the interface, not the implementation. What are really good names? What the inputs and outputs? Once you have come up with a good name for your program and clarified all the arguments you need, you can use Toad to create and compile a “stub” of that program. This is useful because you have now verified that the syntax is correct. Plus, you will be able in step 4 to compile your test code against this stub.
Think about what it will take to prove your program works. Don't worry about getting to 100% coverage, at least in the first pass. Instead, try to come up with a representative sampling of inputs to the program and expected results. You could put these test cases in a spreadsheet or document, but that is dangerously far from the source code. Instead, you are much better off using Quest Code Tester to place your test case definitions in a test repository that is linked directly to the code itself.
4. Build test code that implements all test cases.
Ah...the truly challenging step. Write the test code. It can be hard enough to figure out how to write your application code, but at least you generally know how to write such programs. Test code? Hmmm. How do you test programs that modify programs? How do you test programs that return cursor variables? Where do you put the results, how do you even semi-automatically verify results?
In years past, I would have told you: use utPLSQL, an open source testing framework, that will give you a formalized process for building test code. But you will still write a ton of code. Who has time for that?
Fortunately, I have a much better option to offer to you: when it's time to define your tests and write your test code, use Quest Code Tester for Oracle. This new tool, released first at Oracle Open World in October 2006, allows you to define your tests through a graphical interface. And then Quest Code Tester will generate all the test code for you!
You can get your hands on Quest Code Tester through www.ToadWorld.com; just click on the Downloads link.
5. Write the program unit.
Back to your comfort zone ("I know how to write programs!"), but now you are building against a test plan. Use Toad to build a first iteration of your program. Don't, however, try to implement everything at once. You will end up with too many bugs, making it hard to test and fix your code. Write a little bit of the program, get it compile, run it through the test cycle....
6. Test, debug, fix, test, debug, fix, test, debug....
We never get it right the first time. Writing software is almost always an iterative process. Again, build incrementally, dealing only a limited amount of complexity at a time. Write a little bit, get it to compile, then run your tests. The failed test cases will point out bugs. Use your integrated source code debugger and trace features to find the lines of code that cause the problem. Change the code to fix the bu. Then run your tests again to confirm that you've dealt decisively with the bug (and not introduced any others). Then move on to the next level of complexity or feature that you want to implement, following the same cycle.
Then...repeat steps 3-6 for each enhancement and bug report.
Every bug report highlights two bugs: one in your code and another in your test case. So whenever you encounter a bug (or your users report one), first go back to your test definition and related test code, and make sure you can reproduce the bug there (by adding at least one new test case). Then enter the code-test-debug cycle to fix the bug.
For each enhancement request, follow the same procedure: update your test definition and related test code to capture the new requirements. Your test should then fail since you have not yet implemented the functionality. Then enter the