1. Functional Test: When stage 1 and 2 and 3 are completed the functional test is assigned to the testing team which performs it by following the Software Testing Plan. An updating of the Functional test procedure is discussed to use the the Redmine tool to track the functional testing activities and dismiss the Functional Master Table. The new Software Test procedure is provided in the Functional Test (FT) Procedure section.

A new procedure is released using the Redmine tool to track the testing activities.

The fields (for every tickets) to fill are:

1. Project : gCube
2. Tracker : SW Test;
3. Subject : name of the portlets (plus version) to test or name of the Master Ticket.
   • org.gcube.subsystemName.componentName.version (SW Test) for the component test ticket. For example: org.gcube.application.aquamaps.aquamapsspeciesview.1-3-4 (SW Test).
   • gCube SW Test Release x.x.x for the Master ticket. For example gCube SW Test Release 4.3.0.
4. Priority : Normal;
5. Assignee: Tester, Developer, Infrastrucute or Portal Manager, Release. This assignment depend on the action to do (test, deploy, solve the issue and so on);
6. Category : name of the subsystem portlet (e.g. portlets-admin);
7. Sprint : Release x.x.x - FT Testing. For example: Release 4.3.0 - FT Testing;
8. Parent Task: Master SW Test Ticket (only for the software test components ticket). The parent task for the Master Ticket is the Project Task ticket;
9. Start Date: The date of the ticket creation;
10. End date: Date of the deadline ;
11. Progress: updated when the testing activities is in progress (included not only test but the solution of the issue). Only the first time the progress is 0.

Before to start with the functional test portlets some action were occured:

• The Release Manager asked to every partners to suggest the persons that forms the testing team. A table of the role and assignment is created: Role_Tester.
• Some recommendations were considered mandatory as:
  • The effort should be based not per application but per number of tests to be executed #14123.
  • The tester should not be the same owner of the portlet#1413.
• For every release a Software Test Tracker is created.

Software Test Tracker Procedure - NEW

The flow for the Software Test Tracker is:

New > Available (we verify that the back-end service is up&running, if so move to next status) > Under testing (The tester tests the app) > FT Issue (it goes back Available) OR Tested on preprod.

The flow is showed in the following figure:

• The Master Ticket is created by the Release or Portal Manager.

• The SW Test Portlet Tickets will be created copying the Master Ticket (it's considered the template of the SW Test Portlet). The Master Ticket and its sub-tickets can be used as template with Progress filed at "0" and Status field at "New" to create the other tickets.

For the testing of each release the Tester Manager copies from that template. In this way, only the sprint is changed (in one action thanks to the multi-selection).

• The SW Test Portlet are available after the services are deployed on pre-production and after the Deployer Manager following the procedure as reported in the (Releases Integration).

The Release Manager or the Portal Manager block the Tracker Releases and update the SW Test Tracker from Available to Under Testing.

• The Tester can start with the functional test when Deployer/Infrastructure Manager updates the CRT : {status: Under Integration -> Deployed on Preprod}. The following steps are executed:
• The Tester copies the TestPlan, with the results of the test, in the Releases directory.

For example: the tester tests the invites-friends.1-1-0 portlets. The Tester copies the TestPlan for this portlets into Releases/org.gcube.4.0.0/invites-friends.1-1-0.

• The Tester updated the TestPlan , provided in the Releases directory, with the results for the functional testing.

For example, in the case of the invites-friends, the Tester updates the TestPlan with the functional testing results for this component.

In case the functional testing failed , the Tester opens the issue in the following way:

1) The Tester updates the CRT:{status: Deployed on Preprod -> FT Issue, comment: <issue description>}. The comment should always include a link to a relevant log/report file. The Tester updates the TestPlan provided the number of the issue ticket too (field "Link to the Issue" ) and describing the test results (fied "Results"), too.

2) After the resolution of the issue, the developer updates the CRT:{status: FT Issue -> Under Itegration, comment: <issue description>}.Now. the Infrastructure Manager can be re-deployed the service and updates the CRT status : {status: Under Integration -> Deployed on Preprod, comment: <issue description>}. The tester knows that can repeat the testing and if the test passed, updates the CRT:{status: Deployed On Preprod -> Tested on Preprod, comment: <issue description>}. Otherwise he/she repeats the step 1) (the status return in FT Issue). The Test updates the TestPlan with the new test results (field "Results"), too.

NOTE:
 - Test issue  = The test is fails.
 - Tested on Preprod : indicated that the developer and/or the portal manager or the preprod infrastructure manager 
   are confident that the component behave as expected and can be released as is.

The pre-production infrastructure is provided for the functional testing hosted at CNR.

Roles

The functionality testing activity foresees the involvement of the following roles:

• Tester
• Developer

Tester - UPDATED

In the Software Test the principal role involved is the Tester Manager and the tester.

The Tester is responsible:

• for the execution of the functionality tests and to submit functionality test bugs
• to fill the dedicated Portlet Testing Plan Template and the creation of the SW Test ticket.
• to track the Test Issue through the use of the track system issue tool (ref. D4Science support).

The action for the TestManager are:

• to create the new Software Test Ticket (master ticket and its sub-tickets);

• to create the query;

• to clone the master ticket acting as template for the portlet testing.

The details about the assignment of the testers (for each partners) are hosted on the Role Assignment paragraph.
The tester starts with the functional test when Deployer/Infrastructure Manager updates the CRT status: {status: Under Integration -> Deployed on Preprod}. In case the functional testing fails , the Tester opens the issue updating the SW Test Tracker: {status: Under Testing -> Test Issue, comment: <issue description>}. The comment should always include a link to a relevant log/report file.
After the resolution of the issue, the developer updates the SW Test Tracker {status: Test Issue -> Under Testing, comment: <issue description>}. The Infrastructure Manager know that the portlets must be re-deployed (and after the deploy on Preprod the Tester can repeat the test).
The Tester repeats the testing and, if the test not fails, updates the SW Test Tracker: {status: Under Testing -> Tested on Preprod, comment: <issue description>}. Otherwise, a new issue is opened and the track status returns in Test Issue.

Developer - UPDATED

The details about the role of the developers are hosted on Developers wiki page. The developer is:

• responsible for fixing (functionality and no) test bugs
• carried out by JRA members
• responsible to fill the dedicated Portlet Testing Plan Template as described in the previous section.