A test plan is a set of strategies and resources to carry out a systematic, planned testing methodology.
Using this methodology seeks to validate the behavior of the application, or part of it. To validate the application behavior, the person running the test plan will provide input data and observe both the behavior of gvSIG and the output data. Comparing the expected result with the results obtained we validate the application functionalities.
The test cases will be identified in terms of user requirements, frequency of use, the associated risk and specifications of the application. Priorities on the functionalities to test of each subsystem will have to be set, because it is impossible to try everything.
Test plan structure
Each test plan will have a hierarchical structure. It will try to cover as much as possible the functionalities present in the system to be tested. This hierarchical structure consists of several levels. Each level relationship with the next level is 1 -> n. The test plan is made up of these levels:
- System
The system is the application itself. The tests defined on the plan will be passed on it.
- Subsystem
The subsystem associates related functional groups, it should operate as independently as possible to the rest of the system.
- Module
Each module comprises specific functions. These specific functions, integrated with other modules, implement the logic of the subsystem.
- Use cases
Use cases describe a system use and how it interacts with the user. Use cases must answer the question “what does each module from the user point of view?”.
- Test cases
Test cases show the steps the user has to follow when using a specific use case feature. These steps must be clearly defined. Test cases will be defined for generic sets of input-output data (not particularized in data types, formats, file size, etc).
- Scenarios
Each test case can be tested with several sets of input-output data, each data set defining a test case is called scenario. Inputs for a scenario will be the necesary data to run the corresponding test case and the output data will be the expected results of that test case.
Hierarchy schema
Notice that not all cases must be present at all levels, it depends on the complexity of the set of features you want to try and the test plan to design.
Advantages of testing based on test plans
- Tests are formally defined
Having the tests on paper makes them repeatable by any user or tester, because anyone needing to run the tests will just have to follow the steps listed in each test.
- Application areas already tested are easily identified
The hierarchical structure of each set of tests helps identifying the features that have already been tested. This is also helpful to quickly find out which features are most likely to contain mistakes or misbehavior.
- Monitoring the status of the application
The results of the tests are saved along with the test plan. Analyzing the content of these results we'll be able to estimate the stability of the whole application, and what are their weakness and risk.
- Errors due to correction of other errors are identified
Once a bug in the code is fixed, this may harm another part of the application. Passing the same tests build after build, it is more likely to find such errors.
