|
Test Plan |
Fetter Software will incorporate unit testing, daily build smoke tests, system testing and validation/acceptance testing. Each type of testing serves a unique purpose in ensuring that high quality software is released to the customer during each staged delivery.
Unit testing will be conducted by each individual developer whenever there is a change to a module by that developer, no matter how small or insignificant the change might seem. Unit testing occurs once the developer has finished making changes to the source code and has successfully integrated the new code into his own private build with a successful compile.
Each developer is responsible for identifying the pre-conditions of the code that has been implemented. Once these have been identified, the developer is responsible for ensuring that the newly written code does not break on valid input. Sometimes this will involve writing a short driver to test the code and its output for valid input. Other times, when there are alot of interdependencies, the developer might be forced to unit test the new code by doing a quick system test of the new functionality that the code is intended to produce within the system. If the newly written code has other dependencies on other code that is yet to be written, the developer is simply responsible for testing that his new code does not break the private build before committing the new source code to change control.
When writing unit tests, the developer should exercise the new code with the appropraite boundary conditions. For example, if a method is being tested that has as a precondition that the input is a java prmitive such as a integer or a float, then the developer should test the method with the limits of the ranges of integers and float values according to the Java language specification. Test cases should involve some values approaching these boundaries, the boundaries themselves and just beyond. This is to ensure that the code not only behaves properly on valid input, but also handles any exceptions thrown on invalid input in a graceful manner without bringing down the rest of the system.
With every build a smoke test will be run by the system integrator after the build successfully compiles. The smoke test is designed to ensure that the newly developed code has not damaged the system and that the system, with the newly integrated code, is stable enough to be subjected to further system and validation testing.
A daily build smoke test report will need to be filled out and posted on the project team website for each build. The requirements for the daily smoke test might change throughout the course of the project with newly implemented features and requirements, but its main purpose is to test the user interface. Any defects or missing functionality which should be present with the current build, should be logged as a defect and the defect tracking number entered in the daily build smoke test report. After the smoke test is complete and the results posted on the web, the integration team should hand over the build to the test team for further testing.
The test team will begin system testing once the new build has passed the smoke test. System testing is testing the functionality of the system as a whole once all the newly developed code has been integrated. A primary area of system testing is regression testing. Every build must be regression tested to ensure that the requirements that were met with the previous build are still being met with the current build. A formal test suite guide will be written enumerating test cases used for system testing and will be a dynamic document with new test cases added when new functionality is added to the system. Each requirement must have at least one functional test case included in system testing at all times.
Validation testing is ensuring that the system responds and behaves in a reasonable manner when placed under normal or expected operating conditons such as those that would be used by an average user. Validation testing for our project will be in the form of an acceptance test implemented by the customer. The customer may formalize this testing on his own, or it may be nothing more than an informal smoke test in which he steps through what he feels is a normal use case. The customer will report on the results of his acceptance test with each release. The acceptance of our build by the customer in this manner is his stamp of approval that all contracted functionality for a specific release is present and behaving properly.