Difference between revisions of "Talk:Functional Testing"
Line 21: | Line 21: | ||
#the [https://goo.gl/kQGSf0 general XLS template] to be instantiated by each portlet developer for compiling the Testing Plan and | #the [https://goo.gl/kQGSf0 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 | #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 [https://goo.gl/kQGSf0 Portlet Testing Plan Template]; this file will | + | 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 [https://goo.gl/kQGSf0 Portlet Testing Plan Template]; this file will be pasted and completed into the Release folders by the testers. |
A Task ([https://support.d4science.org/projects/gcube Redmine Ticket]) will be assigned, by the '''Release Manager''', to each portlet developer. | A Task ([https://support.d4science.org/projects/gcube Redmine Ticket]) will be assigned, by the '''Release Manager''', to each portlet developer. | ||
<br> | <br> | ||
− | '''Releases''' will contain a folder for each | + | '''Releases''' will contain a folder for each gCube release containing the tests to be executed. |
<br> | <br> | ||
FT procedure's steps are describe below: | FT procedure's steps are describe below: | ||
Line 32: | Line 32: | ||
#The '''effort''' should be based not per application but per '''number of tests to be executed''' [https://support.d4science.org/issues/1413#change-6072]. | #The '''effort''' should be based not per application but per '''number of tests to be executed''' [https://support.d4science.org/issues/1413#change-6072]. | ||
#The tester should '''not''' be the '''same owner of the portlet'''[https://support.d4science.org/issues/1413#change-6072]. | #The tester should '''not''' be the '''same owner of the portlet'''[https://support.d4science.org/issues/1413#change-6072]. | ||
− | #For every release a wiki page will be created: '''$functional_test_master_table_Org_gCube_#Release'''(e.g. [[Functional Test Master Table Template gCube Release 3.10.0|Functional Test Master Table gCube Release 3.10.0]]). | + | #For every release a wiki page will be created: '''$functional_test_master_table_Org_gCube_#Release'''(e.g. [[Functional Test Master Table Template gCube Release 3.10.0|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 [https://preprod.d4science.org pre-production infrastructure] |
<br> | <br> | ||
− | + | = Roles = | |
+ | |||
+ | The functionality testing activity foresees the involvement of the following roles: | ||
+ | |||
+ | * [[Role Tester|Testers]]: | ||
+ | ** responsible for the execution of the functionality tests and to submit functionality test bugs | ||
+ | ** responsible to fill the dedicated [https://goo.gl/kQGSf0 Portlet Testing Plan Template] and the [[Functional Test Master Table Template|Functional Test Master Table Template]] as described in the [https://wiki.gcube-system.org/index.php?title=Functional_Testing&action=edit§ion=2 previous section]. | ||
+ | * [[Role Developer|Developers]]: | ||
+ | ** responsible for fixing functionality test bugs | ||
+ | ** carried out by JRA members | ||
+ | ** responsible to fill the dedicated [https://goo.gl/kQGSf0 Portlet Testing Plan Template] as described in the [https://wiki.gcube-system.org/index.php?title=Functional_Testing&action=edit§ion=2 previous section]. |
Revision as of 11:18, 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'. This functional test ticket contains also a link to the Functional Test Master Table Template: 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[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
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.