Difference between revisions of "Functional Testing"

From Gcube Wiki
Jump to: navigation, search
(Description)
Line 7: 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. While deployment of services and libraries are tested with the [[Deployment Testing|Deployment tests]], the functionality of portlets is tested through a specific procedure. Since portlets rely on services and libraries to perform their functions, testing the portlets functionalities implicitly tests also the functionalities of services and libraries.
  
* 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.
+
= Portlet Functioanl Testing =
* Functionality test is based upon executing '''Test Suites'''. Test Suites have to be provided by [[Role Developer|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 [[Role Developer|developers]] before the service contribution is accepted.
+
* Functionality test executions require a specific, and configurable Test Suite executor.
+
  
== Roles ==
+
 
 +
= Roles =
  
 
The functionality testing activity foresees the involvement of the following roles:
 
The functionality testing activity foresees the involvement of the following roles:
Line 23: Line 22:
 
** carried out by JRA members
 
** carried out by JRA members
  
== Infrastructure ==
+
= Infrastructure =
  
 
The execution of functionality tests requires a gCube testing infrastructure fully functional.  
 
The execution of functionality tests requires a gCube testing infrastructure fully functional.  
 
A detailed description of the testing infrastructure can be found [[Testing Infrastructure|Testing Infrastructure]]
 
A detailed description of the testing infrastructure can be found [[Testing Infrastructure|Testing Infrastructure]]

Revision as of 17:06, 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. While deployment of services and libraries are tested with the Deployment tests, the functionality of portlets is tested through a specific procedure. Since portlets rely on services and libraries to perform their functions, testing the portlets functionalities implicitly tests also the functionalities of services and libraries.

Portlet Functioanl Testing

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