Difference between revisions of "EGI Quality Criteria Verification"
Line 39: | Line 39: | ||
== Reference Documents == | == Reference Documents == | ||
{| cellspacing="0" cellpadding="3" border="1 | {| cellspacing="0" cellpadding="3" border="1" style="border: 1px solid black;" class="wikitable sortable" | ||
|- align="left" style="background: none repeat scroll 0% 0% Lightgray;" | |- align="left" style="background: none repeat scroll 0% 0% Lightgray;" | ||
! DocDB link | ! DocDB link | ||
Line 60: | Line 60: | ||
== Metrics == | == Metrics == | ||
{| cellspacing="0" cellpadding="3" border="1 | {| cellspacing="0" cellpadding="3" border="1" style="border: 1px solid black;" class="wikitable sortable" | ||
|- align="left" style="background: none repeat scroll 0% 0% Lightgray;" | |- align="left" style="background: none repeat scroll 0% 0% Lightgray;" | ||
! Metric | ! Metric | ||
Line 83: | Line 83: | ||
== Verification engineer skill matrix == | == Verification engineer skill matrix == | ||
{| border="1" style="text-align: center; | {| border="1" class="wikitable" style="text-align: center;" | ||
|+ Verification Cheat Sheet | |+ Verification Cheat Sheet | ||
|- | |- | ||
Line 90: | Line 90: | ||
! width="75" | IFCA | ! width="75" | IFCA | ||
! width="75" | IFIC | ! width="75" | IFIC | ||
! width="75" | INFN | ! width="75" | INFN | ||
! width="75" | IN2P3 | ! width="75" | IN2P3 | ||
! width="75" | JÜLICH | ! width="75" | JÜLICH | ||
Line 102: | Line 102: | ||
| | | | ||
| | | | ||
| | | | ||
| * | | * | ||
| | | | ||
Line 111: | Line 111: | ||
| | | | ||
| | | | ||
| | | | ||
| | | | ||
| * | | * | ||
Line 121: | Line 121: | ||
| | | | ||
| | | | ||
| | | | ||
| | | | ||
| * | | * | ||
Line 132: | Line 132: | ||
| | | | ||
| | | | ||
| | | | ||
| | | | ||
| | | | ||
Line 142: | Line 142: | ||
| | | | ||
| | | | ||
| | | | ||
| | | | ||
| | | | ||
Line 152: | Line 152: | ||
| | | | ||
| | | | ||
| | | | ||
| | | | ||
| | | | ||
Line 160: | Line 160: | ||
| | | | ||
| | | | ||
| * | | * | ||
| | | | ||
| | | | ||
Line 172: | Line 172: | ||
| | | | ||
| | | | ||
| | | | ||
| | | | ||
| | | | ||
Line 182: | Line 182: | ||
| | | | ||
| | | | ||
| | | | ||
| | | | ||
| | | | ||
Line 191: | Line 191: | ||
| | | | ||
| | | | ||
| | | | ||
| | | | ||
| | | | ||
Line 202: | Line 202: | ||
| | | | ||
| | | | ||
| | | | ||
| | | | ||
| | | | ||
Line 213: | Line 213: | ||
| | | | ||
| | | | ||
| | | | ||
| | | | ||
|- | |- | ||
Line 220: | Line 220: | ||
| | | | ||
| | | | ||
| | | | ||
| * | | * | ||
| | | | ||
| | | | ||
| | | | ||
|- | |- | ||
! align="left" | StoRM | ! align="left" | StoRM | ||
Line 232: | Line 232: | ||
| | | | ||
| | | | ||
| | | | ||
| * | | * | ||
| | | | ||
Line 243: | Line 243: | ||
| | | | ||
| | | | ||
| | | | ||
| | | | ||
|- | |- | ||
Line 253: | Line 253: | ||
| | | | ||
| | | | ||
| | | | ||
| | | | ||
|- | |- | ||
Line 260: | Line 260: | ||
| | | | ||
| | | | ||
| | | | ||
| | | | ||
| | | | ||
Line 273: | Line 273: | ||
| | | | ||
| | | | ||
| | | | ||
| | | | ||
|- | |- | ||
Line 281: | Line 281: | ||
| | | | ||
| | | | ||
| | | | ||
| | | | ||
| * | | * | ||
Line 291: | Line 291: | ||
| | | | ||
| | | | ||
| | | | ||
| | | | ||
| * | | * | ||
Line 301: | Line 301: | ||
| | | | ||
| | | | ||
| | | | ||
| | | | ||
| | | | ||
Line 313: | Line 313: | ||
| | | | ||
| | | | ||
| | |||
| No verifiers available yet. | | No verifiers available yet. | ||
|- | |- | ||
Line 321: | Line 322: | ||
| | | | ||
| | | | ||
| | | | ||
| | | | ||
| | | | ||
Line 329: | Line 330: | ||
| | | | ||
| | | | ||
| | | | ||
| | | | ||
| * | | * | ||
Line 339: | Line 340: | ||
| | | | ||
| | | | ||
| | | | ||
| | | | ||
| * | | * | ||
Line 349: | Line 350: | ||
| | | | ||
| | | | ||
| | | | ||
| | | | ||
| * | | * | ||
Line 359: | Line 360: | ||
| | | | ||
| | | | ||
| | | | ||
| | | | ||
| * | | * | ||
Line 369: | Line 370: | ||
| | | | ||
| | | | ||
| | | | ||
| | | | ||
| * | | * | ||
Line 379: | Line 380: | ||
| | | | ||
| | | | ||
| | | | ||
| | | | ||
| * | | * | ||
Line 389: | Line 390: | ||
| | | | ||
| | | | ||
| | | | ||
| | | | ||
| * | | * | ||
Line 399: | Line 400: | ||
| | | | ||
| | | | ||
| | | | ||
| | | | ||
| * | | * | ||
Line 409: | Line 410: | ||
| | | | ||
| | | | ||
| | | | ||
| | | | ||
| | | | ||
Line 420: | Line 421: | ||
| | | | ||
| | | | ||
| | | | ||
| | | | ||
| | | | ||
Line 431: | Line 432: | ||
| | | | ||
| | | | ||
| | | | ||
| | | | ||
| | | | ||
Line 442: | Line 443: | ||
| | | | ||
| | | | ||
| | | | ||
| | | | ||
|- | |- | ||
Line 452: | Line 453: | ||
| | | | ||
| | | | ||
| | | | ||
| | | | ||
|- | |- | ||
Line 462: | Line 463: | ||
| | | | ||
| | | | ||
| | | | ||
| | | | ||
|- | |- | ||
Line 472: | Line 473: | ||
| | | | ||
| | | | ||
| | | | ||
| | | | ||
|- | |- | ||
Line 483: | Line 484: | ||
| | | | ||
| | | | ||
| | | | ||
|} | |} | ||
Revision as of 10:30, 17 April 2012
Technology | Software Component Delivery | Software Provisioning | UMD Middleware | Cloud Middleware Distribution | Containers Distribution | Technology Glossary |
Quality Assurance | | Quality Criteria Definition | | Quality Criteria Dissemination | | Quality Criteria Verification | | Verifier Guideline | | Verification Testbed | | Glossary |
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 product 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 described in detail in the EGI Verifier Guideline.
QC Verification Reports
RT workflow and Verification Templates links are available in this page. First of all verifiers must check QC service mapping to know which test must be verified for each product. This service mapping is available here QC Verification service mapping and Verification/Executive Summary templates are available here: QC Verification Templates.
Verifiers must fill all required fields for each product and write a Verification process summary into Executive Summary, this summary should include:
- A short summary of the installation and configuration process: Installation and configuration were successful?, If not explain any issue or bug found. If the product was rejected explain why.
- If its necessary Verifiers should include a comment for StageRollout: Configuration changes or minor issues found verifying the product.
- If a new QC is necessary and is not included, Verifiers must write a comment to SA2.2 to change current QC.
Verification Work Effort Metrics
Each verification process and change is registered by EGI RT. A complete report is generated on a daily basis each midnight. The XLS file can be downloaded from here SA2 Verification Metrics
Verification Team
Verifiers team is updated for each UMD release and it is available here: SA2.3 Verifiers List. All verifiers are included in the SSO sw-rel-qc group that includes a mailing list and permissions to modify RT tickets related with the verification process.
Reference Documents
DocDB link | Release Date | Document |
---|---|---|
364 | 11. 08. 2011 | UMD Quality Criteria |
418 | 11. 08. 2011 | UMD Products service mapping |
417 | 11. 08. 2011 | QC Verification Templates |
Metrics
Metric | Description |
---|---|
M.SA2.4 | Number of new releases validated against defined criteria: Measures the workload on the validation team. |
M.SA2.5 | Mean time taken to validate a releas: Indicates how responsive the team is to validating releases. |
M.SA2.6 | Number of releases failing validation: Indicates the quality assurance process of the software providers. |
SLAs
EGI SLAs negotiated with the TPs
Verification engineer skill matrix
Product\Institute | CESGA | IFCA | IFIC | INFN | IN2P3 | JÜLICH | LIP | COMMENTS |
---|---|---|---|---|---|---|---|---|
ARC CE | * | * | ||||||
ARC compute cli | * | * | ||||||
ARC Infosys | * | * | ||||||
dCache | * | |||||||
gLite MPI | * | * | ||||||
CREAM_torque | * | * | ||||||
CREAM_lsf | * | |||||||
WMS | * | * | ||||||
LB | * | * | ||||||
FTS | No verifiers available yet. | |||||||
DPM | * | |||||||
LFC_mySQL | * | |||||||
LFC_Oracle | * | |||||||
StoRM | * | * | ||||||
APEL | * | |||||||
DGAS | * | |||||||
BDII | * | |||||||
UI | * | |||||||
PX | * | |||||||
VOMS_mySQL | * | |||||||
VOMS_Oracle | No verifiers available yet. Oracle training required. | |||||||
HYDRA | No verifiers available yet. | |||||||
ARGUS | * | |||||||
UNICORE TSI | * | |||||||
UNICORE WS | * | |||||||
UNICORE Client | * | |||||||
UNICORE Registry | * | |||||||
UNICORE Gateway | * | |||||||
UNICORE Hila | * | |||||||
UNICORE xuudb | * | |||||||
UNICORE Uvos | * | |||||||
AMGA | * | |||||||
SAGA-SD | No verifiers available yet. | |||||||
GRAM5 | * | |||||||
GridFTP | * | |||||||
myProxy | * | |||||||
RLS | * | |||||||
GridWay | * | |||||||
SAM | * |