Difference between revisions of "Talk:Functional Testing"
Line 1: | Line 1: | ||
− | # '''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 | + | # '''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|Functional Test Master Table Template]]''': an online table 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; | ||
#* Tester Name: name of the tester; | #* Tester Name: name of the tester; | ||
− | #* Scope: the infrastructure scope where the Portlet has to be functionally tested; | + | #* 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; | #* 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; | #* Renders OK: indicates whether the Portlet displays correctly in the iMarine Gateway. The portal manager compiles this part; | ||
Line 12: | Line 12: | ||
#* Ticket: the [https://support.d4science.org/projects/gcube Redmine ticket] associated to the functional test ; | #* Ticket: the [https://support.d4science.org/projects/gcube Redmine ticket] associated to the functional test ; | ||
− | + | <strike>[[File:Functional tests.png|center|800px|Figure 1: functional test master table]]</strike> | |
− | [[File:Functional tests.png|center|800px|Figure 1: functional test master table]] | + | |
== Functional Test (FT) Procedure == | == Functional Test (FT) Procedure == | ||
Line 22: | 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). | + | 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 paste into the Release folders and completed by 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 gcube release containing the tests to be executed. | '''Releases''' will contain a folder for each gcube release containing the tests to be executed. | ||
<br> | <br> | ||
− | + | FT procedure's steps are describe below: | |
*The '''pre-production infrastructure''', [https://preprod.d4science.org hosted at CNR], will be used for the FT testing. | *The '''pre-production infrastructure''', [https://preprod.d4science.org 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 Release Manager will ask to '''every partners''' to suggest the persons that will form the testing team. | ||
Line 33: | 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 | + | #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]]). |
<br> | <br> | ||
− | + | ||
− | + | Every testers will fill the functional test master table including the functional tests results for the Portlets applications executed in the pre-production infrastructure: [[Functional Test Master Table Template|Functional Test Master Table Template]] . | |
− | Every | + |
Revision as of 11:06, 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 paste into the Release folders and completed by 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).
Every testers will fill the functional test master table including the functional tests results for the Portlets applications executed in the pre-production infrastructure: Functional Test Master Table Template .