The wiki is deprecated and due to be decommissioned by the end of September 2022.
The content is being migrated to other supports, new updates will be ignored and lost.
If needed you can get in touch with EGI SDIS team using operations @ egi.eu.
Difference between revisions of "EGI Quality Criteria Verification"
| Line 12: | Line 12: | ||
* Verification team checks that the pre-conditions of the verification phase are met: | * Verification team checks that the pre-conditions of the verification phase are met: | ||
* RT ticket is in state '''Open'''. | |||
Revision as of 03:40, 13 March 2011
Objective
The main objective of the TSA2.3 is to verify the quality of the software provided by the TP before entering the SR phase and going to production. By doing so we prevent that software that might work enters into the SR and even goes into production but that doesn´t follow the quality criteria defined in TSA2.2. Some of the reasons for doing the verification before the software enters the stage rollout are:
- Check that the bugs reported in the previous release of the software have been corrected (work in collaboration with DMSU) by the TP.
- Software can work well in the SR but might not have all the functionalities required
- Software might not be safe, well documented, or have the necessary installation rules or licenses
The verification process
When a new release is available, the TP has to follow the NSRW. Once the software is correctly uploaded to the repository, the release enters into the verification phase. The requirements are that the TP has to provide all the necessary information to the verifier (QCV) so that the QCV can assess that the TP has tested in advance the quality of the software. Depending on the type of release, different actions will be taken by the QCV, Verification process is as follows:
- Verification team checks that the pre-conditions of the verification phase are met:
* RT ticket is in state Open.