Difference between revisions of "Functional Testing"
From Gcube Wiki
(→Infrastructure) |
(→Description) |
||
| Line 1: | Line 1: | ||
| − | |||
The objective of the Functional Testing activity in gCube is to ensure that all the components: | The objective of the Functional Testing activity in gCube is to ensure that all the components: | ||
* gCube services and public interfaces, are conform to their specification | * gCube services and public interfaces, are conform to their specification | ||
| Line 8: | Line 7: | ||
The goal of functional testing is to assure the appropriate quality of the gCube software. Testing, in general, is not a procedure to find bugs, but to check that the software works in accordance with the specification, architectural and detailed design documents. In addition the testing activity has to ensure that the software is easy to use and gives appropriate response in the case of wrong usage or defects that cannot entirely be eliminated. Testing is planned according to these goals. | The goal of functional testing is to assure the appropriate quality of the gCube software. Testing, in general, is not a procedure to find bugs, but to check that the software works in accordance with the specification, architectural and detailed design documents. In addition the testing activity has to ensure that the software is easy to use and gives appropriate response in the case of wrong usage or defects that cannot entirely be eliminated. Testing is planned according to these goals. | ||
| − | + | The gCube software is composed by three types of components: services, libraries, and portlets. Functionality tests are executed against gCube services using different test tools (see [[Deployment Testing]]), while Validation tests are executed using the User Interface (portlets) of the software. | |
| − | + | ||
| − | The gCube software is composed by three types of components: services, libraries, and portlets. Functionality tests are executed against gCube services using different test tools, while Validation tests are executed using the User Interface (portlets) of the software. | + | |
* Services implement the gCube core functionalities and usually rely on other services and/or libraries at run-time. The testing of these services has to be performed by invoking their public interface methods similar to real production situations. In order to make testing more reliable and to ensure that a particular service is really stable, not only properly parametrized invocations have to be performed, but malformed or misused sequence of these service calls should also be performed. In many cases, the service interface execution requires input parameters taken from the output of another service. The functional testing activity therefore continuously requires modifications in the testing program code, and as such, it cannot be fully automated. Whenever a software is changed, the testing utility must be revised, and its configuration has to be renewed according the software changes. The functional testing activity is performed on all possible interfaces of all gCube services, both using (and modifying) the provided testing utility in each service, and by developing additional testing utilities within the corresponding test case executor if needed. | * Services implement the gCube core functionalities and usually rely on other services and/or libraries at run-time. The testing of these services has to be performed by invoking their public interface methods similar to real production situations. In order to make testing more reliable and to ensure that a particular service is really stable, not only properly parametrized invocations have to be performed, but malformed or misused sequence of these service calls should also be performed. In many cases, the service interface execution requires input parameters taken from the output of another service. The functional testing activity therefore continuously requires modifications in the testing program code, and as such, it cannot be fully automated. Whenever a software is changed, the testing utility must be revised, and its configuration has to be renewed according the software changes. The functional testing activity is performed on all possible interfaces of all gCube services, both using (and modifying) the provided testing utility in each service, and by developing additional testing utilities within the corresponding test case executor if needed. | ||
Revision as of 16:57, 13 October 2015
The objective of the Functional Testing activity in gCube is to ensure that all the components:
- gCube services and public interfaces, are conform to their specification
- are free from erroneous or malfunction
- can be run in the defined system requirement
- are free from code anomalies and coding errors
The goal of functional testing is to assure the appropriate quality of the gCube software. Testing, in general, is not a procedure to find bugs, but to check that the software works in accordance with the specification, architectural and detailed design documents. In addition the testing activity has to ensure that the software is easy to use and gives appropriate response in the case of wrong usage or defects that cannot entirely be eliminated. Testing is planned according to these goals.
The gCube software is composed by three types of components: services, libraries, and portlets. Functionality tests are executed against gCube services using different test tools (see Deployment Testing), while Validation tests are executed using the User Interface (portlets) of the software.
- Services implement the gCube core functionalities and usually rely on other services and/or libraries at run-time. The testing of these services has to be performed by invoking their public interface methods similar to real production situations. In order to make testing more reliable and to ensure that a particular service is really stable, not only properly parametrized invocations have to be performed, but malformed or misused sequence of these service calls should also be performed. In many cases, the service interface execution requires input parameters taken from the output of another service. The functional testing activity therefore continuously requires modifications in the testing program code, and as such, it cannot be fully automated. Whenever a software is changed, the testing utility must be revised, and its configuration has to be renewed according the software changes. The functional testing activity is performed on all possible interfaces of all gCube services, both using (and modifying) the provided testing utility in each service, and by developing additional testing utilities within the corresponding test case executor if needed.
- Functionality test is based upon executing Test Suites. Test Suites have to be provided by developers of service and they consists of a collections of basic functionality tests for the corresponding services. In order to examine if a particular Test Suite works properly, it has to be first executed by developers before the service contribution is accepted.
- Functionality test executions require a specific, and configurable Test Suite executor.
Roles
The functionality testing activity foresees the involvement of the following roles:
- Testers:
- responsible for the execution of the functionality tests and to submit functionality test bugs
- developers:
- responsible for fixing functionality test bugs
- carried out by JRA members
Infrastructure
The execution of functionality tests requires a gCube testing infrastructure fully functional. A detailed description of the testing infrastructure can be found Testing Infrastructure
