|
|
| (4 intermediate revisions by the same user not shown) |
| Line 1: |
Line 1: |
| − | == Functional Test (FT) Procedure ==
| + | |
| − | <br>
| + | |
| − | The Software Testing Plan [https://support.d4science.org/issues/1413#change-6072 #1413] is created in the [https://i-marine.d4science.org/group/data-e-infrastructure-gateway/workspace BlueCommons VRE Folder] containing two folders: '''Material''' and '''Releases'''.
| + | |
| − | <br>
| + | |
| − | '''Material''' will contain:
| + | |
| − | #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
| + | |
| − | 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.
| + | |
| − | <br>
| + | |
| − | '''Releases''' will contain a folder for each gCube release containing the tests to be executed.
| + | |
| − | <br>
| + | |
| − | FT procedure's steps are describe below:
| + | |
| − | *The '''pre-production infrastructure''', [https://pre.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 following '''recommendations''' should be '''mandatory''':
| + | |
| − | #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].
| + | |
| − | #For every release a wiki page will be created: '''$functional_test_master_table_Org_gCube_#Release'''(e.g. [https://wiki.gcube-system.org/gcube/FunctionalTestMasterTablegCube3.10.0 Functional Test Master Table gCube Release 3.10.0] or [https://wiki.gcube-system.org/gcube/FTMasterTablegCube4.0.0 Functional Test Master Table gCube Release 4.0.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|infrastructure]].
| + | |
| − | <br>
| + | |
| − | [[span style="color:red;"]]Scritta di prova.[[/span]]
| + | |
| − | <pre style="color: red">NEW
| + | |
| − | In case of FT issues:
| + | |
| − | # the Tester Manager updates the CRT: <code>{status: Deployed on Preprod -> FT Issue, comment: <issue description>}</code>. The comment should always include a link to a relevant log/report file.
| + | |
| − | #After the resolution of the issue, the developer updates the CRT: <code>{status: FT Issue -> Under Itegration, comment: <issue description>}</code>. The comment should always include a link to a relevant log/report file.
| + | |
| − | #The tester canrepeat the FT testing and if the test passed, updates the CRT: <code>{status: FT Issue -> Tested on preprod, comment: <issue description>} otherwise the first step is repeated (the status return in FT Issue).
| + | |
| − | </pre>
| + | |
