 |
 |
 |
 |
440.0 TEST PHASE
Most full-time software developers like nothing better than sitting down and writing code. Many can sit down early in the morning and write code for hours at a time. Of course, along with the coding comes the testing, which many developers don't enjoy as much. But it is during the testing process that you really find out what kind of programmer you are. Were the hundreds, or thousands, of lines of code just so much garbage, or did the testing prove the beauty and logical strength of your code? In fact, the software testing process shows much more than what a good programmer you are. It also shows how well you captured your business requirements and how well you designed your application.
It is worth stating the obvious about the reason we perform testing at all. First, we want to ensure that the solution meets the business requirements. For instance, if a specific business transaction follows a logical path from A -> B -> C -> D, we want our testing to prove that this, in fact, happens. Second, we test to catch errors and defects. These may be programming errors or errors that were introduced earlier in the development lifecycle. In other words, we need to prove that our solution is correct, while at the same time proving that there are no errors or defects. You may not catch many errors, but you still need to prove that the solution meets the business requirements.
The essence of testing is to:
-
Catch as many errors as possible
-
Correct the errors
-
Track the errors to understand their causes and any patterns that may exist
-
Revalidate the stability of the solution, including ensuring that the correction of one error does not lead to the introduction of another error somewhere else
In some organizations the testing process is handled by a separate team of testing specialists. This test team is usually very disciplined in their testing approach, and they are able to thoroughly test because they do not have any preconceived notions of how things "should" work. They only know how the solution "does" work. The construct team passes their programs and test data to the test team for testing and validation. The test team performs the actual testing and provides feedback to the construct team on the success and errors encountered.
However, it is more typical for the Test Phase to be completed by the same group of people who worked on the Construct. This has some benefits in terms of their familiarity with how the solution is supposed to work. They also have the advantage of being able to quickly go from testing error to code correction and then back to testing again.
Both organizational models are valid and are used successfully in many companies.
Some Basic Tenets of Testing
Regardless of the type of project you are on, you want to catch as many errors as early in the lifecycle as possible. There are projects that purposely blast through the Analysis, Design and Coding Phases with a philosophy that they will fix all the problems in testing. This is usually disastrous. It’s not so bad to correct programming errors that you discover in your testing. It is much more difficult when you realize that a design error resulted in information missing from your database. It is even harder if you discover that your analysis missed an entire business process.
At the same time, you cannot ensure that your software is perfect. Even with the best tools, it is impossible to test every logic path of every program. Therefore, you cannot ever be sure that your code is bug-free. There are times when software that has been stable for ten years suddenly breaks through an unlikely combination of circumstances that never occurred before. (These are “subtle” bugs.)
Since you cannot build the perfect, bug-free system, the project team needs to understand the cost of testing and when the cost exceeds the benefit. You can get into a lot of trouble if your testing is not rigorous enough. However, testing too much can be a waste of precious resources as well. You can’t deliver a perfect system, but you can determine how much testing makes sense given the characteristics of your project. Building an internal application to track client complaints does not need the testing rigor that was required for the Apollo moon mission.
The Testing Process
The Test Phase is toward the end of the traditional waterfall development process. However, hopefully this is not the first time you have thought about testing. Depending on the characteristics of your project, you may already have created an initial Testing Strategy in the Analysis Phase and a Testing Plan in the Design Phase. You would have already performed initial unit testing in the Construct Phase. Now, you are ready for the standalone testing process that belongs in the Test Phase.
Note again that some methodologies combine the testing process into the Construct Phase. LifecycleStep breaks out the formal testing process into its own phase to provide emphasis on the focused testing that takes place at this time. If the testing process uncovers error and bugs, the team will need to correct them, which will mean briefly going back to the construct and unit test process. However, some errors may also require you to backtrack further and make design changes. In fact, you may encounter major errors that could impact your requirements. This could be caused by determining that certain requirements were missed or that certain stated requirements need to be modified to accommodate problems that were uncovered in the testing process.
There are a number of specific tests that can be part of the testing process. The specific ones your solution needs will be defined in your testing strategy and plan.
448.0 Re-plan for the Remainder of the Project
449.0 Obtain Approval to Proceed
-
Test Cases
-
Test Script
-
Test Case Validation Log
-
Test Error Report
-
Test Error Log
[Previous -
439.0 Obtain Approval to Proceed]
[Next -
440.1
Resolving Bugs
]
