AIX > Tips & Techniques > Application Development

Are You Up to the Test?

Exploring best practices of testing

We all do testing. We write (or update) new programs and test for the errors we anticipate. Then we compile the program, put it into production, and lean back and wait for the harried helpdesk person to knock on our cube wall with a user with a problem. Perhaps there’s a better way.

Testing is a broad topic. Too often programmers (and systems people who write code, especially CL) have too narrow of a focus when it comes to testing. Now, a narrow focus when applied to attention to detail is a good thing, but we need to broaden our horizons with testing. We tend to focus on the code that we write, the errors that we anticipate and the exceptions that we plan to handle. And I believe we do a very good job with that technique.

By the way, I make a distinction between errors and exceptions. An exception is a change to the normal flow of a process, but it’s something that we expect. Reaching end of file when reading a file would be an example of an exception. An error is also a change to the flow of a process, but it’s a change that’s unexpected or abnormal, and can cause problems when it occurs. A decimal data error or dividing by zero would be examples.

However, those of us who’ve been around the block for a while realize it’s not the errors that we anticipate that will cause problems; it’s the errors that we don’t anticipate. Doesn’t that sound counterintuitive? How can we handle something that we don’t anticipate? Is that like proving a negative or something? Rest assured that the solution is simple…it’s called a testing procedure.

The Testing Procedure

The testing procedure consists of three major steps: setup, process and assessment. We’ll look at each step, but here’s an overview of the steps and their components:

1. Test Plan Setup

• Design test
  • Test script
• Validate test
  • Expected results

2. Testing Process

• Establish test data (ETL)
• Conduct test
  • Unit tests
  • System tests
  • Repeatability
• Regression testing

3. Assess results

• Compare actual to expected
• Feedback to development/testing
• Reset test data

Test Plan Setup

The first section, Test Plan Setup, is how we plan and design our testing. Rather than just concentrating on the errors and exceptions that we anticipate, we will create a test plan that will test the operation of our program (or application or system, depending on the scope of the testing). This will test the parts we expect to work as well as the parts where we expect a problem to happen.

The first step of the setup is to design the test. This is where we combine our knowledge of the program and our knowledge of the way it will be used. This enables us to create a listing of the step-by-step actions we need to take to fully test our program. The script would include instructions for the normal case (e.g., “Enter an order number,” “Press Enter to verify the order,” “Press F16 to submit the order for processing,” etc.). The script should also include instructions for error handling (e.g., “Press Enter with a blank order number,” “Attempt to submit an order with no vendor number,” etc.).

The second step of the test plan setup is to validate our test. Just as we create the actions to test our program, we also need to identify the expected results from those actions. For instance, if we process an order, we should expect that that order will appear in the list of open orders. If it doesn’t, we have a problem. We would need to provide feedback to the developer (or the lead tester) that a problem has been encountered.

Tweet