Let us start with unit testing. To unit-test a program, you: first create test cases. A test case is the description of a unique combination of inputs and data base states. The secret to good, efficient testing is to plan the test cases so that each is unique and together they are exhaustive. In practice, you develop unit test cases from the program specification to make sure that all the processing rules and conditions are reflected in at least one test case. You create a separate test case for each state of the data base that could have an impact on how the program works. Pay special attention to boundary conditions, those that are abnormal or at the edge of normality. For instance, when processing a multi-line order, pay special attention to the first and the last lines of the order. Include orders that have one line, or none at all, or a very large number. Consider also abnormal cases, such as that of trying to create an order for a customer who is not recorded on the data base. Create different orders for different types of customers. Consider what happens for the first order of the day, when the order file is empty, or after a heavy day, when the order file becomes very large. Create order lines with very small and very large amounts. Are negative amounts accepted? It is as important for a program to raise the proper exceptions for erroneous inputs as it is to check that valid data is processed correctly.
Once you believe the test cases are complete, cross-reference them against the program specification to ensure that each specification is addressed.
Once the test cases have been created, prepare the test scaffolding, the environment in which the test will be run. If the program is a user interface program, most of the test data needs to be laid out in a script for the user to follow. If not, input or transaction files must be loaded. This can be done with a test data load utility or it may require a specially written program. Next, the test data base (including web site content, if applicable) must be created. The best way to do this is to have the project team maintain a master database of shared test data from which each programmer can extract relevant tables, rows and files , modifying them where necessary for the purpose of the test. (You cannot use the database directly, since your program is likely to update it, thus creating unexpected conditions for everybody else.) If the project team doesn’t have a common test data base, create your own, as you did for input and transaction data.
Next, consider what stubs and drivers you need to test your program. In many cases, a program needs to communicate with other programs, some of which may not have been created yet. A stub is a small program that can be called by the program being tested and can simulate the services rendered by the called program. A driver works the other way around: if your program is designed to be called by a program that doesn’t exist yet, and you must write a simple program that activates yours.
Another useful tool is one that does screen capture. This tool records keystrokes and screen display changes; it enables you to repeat exactly the same test and to compare its output before and after you make modifications.
Before running the tests, you should prepare the expected results for each test case in each test cycle. Most developers do not do this. They believe that it is sufficient to run the test and review the output to see if it is correct. This is insufficient, for two reasons. First, people have a propensity to see positive results. Subconsciously, the brain will often rationalize an error and tend to think that the result is actually correct when it isn’t. Second, preparing expected results is an excellent way to review the completeness and relevance of the test data.
Ideally, you would load the expected results on to a file in the same format as that produced by the test. Then, the comparison between expected and actual results can be done electronically – a much more reliable approach than trusting human faculties. A keystroke/screen capture facility comes in handy here, especially for programs that are part of the user interface. But even if you don’t have such a tool, comparing a predetermined expected result against an actual one is a lot more reliable than just viewing the actual result to decide whether it is correct.
Preparing expected results is time-consuming and not much fun. Ultimately, however, by avoiding false positive results and by making it easier to repeat the same tests after correction, you save time and increase quality. However, since the cost is incurred earlier than the benefits materialize, project management has a tendency, when put under time pressure, to shortcut this indispensable investment.
- 1418 reads
