Difference between revisions of "Talk:Functional Testing"
(→Functional Test (FT) Procedure) |
|||
Line 1: | Line 1: | ||
− | # '''Functional Test''': when stage 1 and 2 are completed the related Portlet application domain expert | + | # '''Functional Test''':<strike> 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'</strike> 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. |
+ | <br> | ||
+ | <strike>This functional test ticket contains also a link to the</strike> An online table | ||
+ | '''[[Functional Test Master Table Template|Functional Test Master Table Template]]''' is created by the portal manager : <strike>(see Figure 1 for column names) </strike> and shared with each actor involved in the functional testing procedure. Each row contains a Portlet artefact having to pass the functional testing procedure[[https://wiki.gcube-system.org/index.php?title=Functional_Testing&action=edit§ion=1 Functional Test (FT) Procedure]]. <strike>With respect to the table header reported in the figure below.</strike> <strike>The columns indicate the following:</strike>. Below the description of the table's fields: | ||
#* Component Name: Portlet unique identifier; | #* Component Name: Portlet unique identifier; | ||
#* Owner: generally the developer of the Portlet or the responsible of the application; | #* Owner: generally the developer of the Portlet or the responsible of the application; |
Revision as of 12:29, 24 November 2015
- 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'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.
This functional test ticket contains also a link to the An online table
Functional Test Master Table Template is 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[Functional Test (FT) Procedure]. With respect to the table header reported in the figure below. The columns indicate the following:. Below the description of the table's fields:
- Component Name: Portlet unique identifier;
- Owner: generally the developer of the Portlet or the responsible of the application;
- Tester Name: name of the tester;
- Scope: the infrastructure scope where the Portlet has to be functionally tested;F
- 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;
- Link Test Plan: the general XLS portlet test plan link
- Ticket: the Redmine ticket associated to the functional test ;
Functional Test (FT) Procedure
The Software Testing Plan #1413 is created in the BlueCommons VRE Folder containing two folders: Material and Releases.
Material will contain:
- the general XLS template to be instantiated by each portlet developer for compiling the Testing Plan and
- the portlet folder (created by Portal Manager) for each portlet to be functionality tested. The syntax used to create the portlet folder
will be: $portlet_name_folder. Every developer will create the actual testing plan into Material/$portlet_name_folder including by adding additional files required for the test (e.g. cvs_files). To describe the functional tests, the developer will use the Portlet Testing Plan Template; this file will be pasted and completed into the Release folders by the testers.
A Task (Redmine Ticket) will be assigned, by the Release Manager, to each portlet developer.
Releases will contain a folder for each gCube release containing the tests to be executed.
FT procedure's steps are describe below:
- The pre-production infrastructure, hosted at CNR, will be used for the FT testing.
- The Release Manager will ask to every partners to suggest the persons that will form the testing team.
- The following recommendations should be mandatory:
- The effort should be based not per application but per number of tests to be executed [1].
- The tester should not be the same owner of the portlet[2].
- For every release a wiki page will be created: $functional_test_master_table_Org_gCube_#Release(e.g. Functional Test Master Table gCube Release 3.10.0). The [Functional Test Master Table Template|Functional Test Master Table Template]] will be fill by the testers with the FT results for the portlets applications in the pre-production infrastructure [3]
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
- responsible to fill the dedicated Portlet Testing Plan Template and the Functional Test Master Table Template as described in the previous section.
- Developers:
- responsible for fixing functionality test bugs
- carried out by JRA members
- responsible to fill the dedicated Portlet Testing Plan Template as described in the previous section.