Revision as of 17:47, 14 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

The Portlets composing gCube have been required to pass a functional testing procedure in order to be made available for end users. The actors involved in the procedure are: the portal manager, the infrastructure manager, and the portlet application domain experts. Portlet application domain experts are expert users of a specific application. The domain expert knows very well all the possible interactions between the end user and the user interface. In some specific cases, they could be application developers or application owners.

The procedure starts by analysing the software artefacts included in the release along with their software dependencies. This task is carried out manually by the portal manager. Each portlet artefact which is released must be part of the functional testing procedure. Also, if anything in the dependency chain of a Portlet X is released, than X has to be functionally tested too.

The Portlets Functional Testing procedure consists of 4 stages:

1. Web Archive check: every Portlet web archive released is verified to contain all the necessary files needed for its correct deployment. If the check is not passed the Portlet developer is notified through a new ticket of type integration issue;
2. Back-end Service check: The portal manage and the infrastructure manager make sure that the back-end services of the Portlet application are ready and fully functional in the testing / pre-production infrastructure.
3. Rendering check: every Portlet web archive passing stage no. 1 is then actually deployed into the pre-production portal to check if it renders correctly. In this stage there are few things that could make the Portlet not render correctly. For instance, the GWT compilation could fail during Web Archive creation, or the developer could have used some CSS classes that clash with those of the iMarine Gateway. If the check is not passed the Portlet developer is notified through a new ticket of type integration issue;
4. Functional Test: when stage 1 and 2 are completed the related Portlet application domain expert is assigned to the functional test by opening a new ticket of type ‘functional test’; This functional test ticket contains also a link to the functional test master table: an online table created by the portal manager (see Figure 1 for column names) and shared with each actor involved in the functional testing procedure. Each row contains a Portlet artefact having to pass the functional testing procedure. With respect to the table header reported in the figure below. The columns indicate the following:
   • Component Name: Portlet unique identifier;
   • Owner: generally the developer of the Portlet or the responsible of the application;
   • Domain Expert: an expert user of the application;
   • Scope: the infrastructure scope where the Portlet has to be functionally tested;
   • Web Archive validity: indicates if the software package produced by the build system can be correctly deployed in the iMarine Gateway. The portal manager compiles this part;
   • Renders OK: indicates whether the Portlet displays correctly in the iMarine Gateway. The portal manager compiles this part;
   • Service Deployed: indicates whether the infrastructure services composing the back-end of the Portlet application are ready and fully functional. The infrastructure manager compiles this part;
   • Functional Test: compiled by the Application Domain Expert user, indicates if the functional test was performed;
   • Notes: if the functional test cannot be performed the Application Domain Expert can explain the reasons in the notes;
   • Ticket: the Redmine ticket associated to the functional test;

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