EGI Quality Criteria Verification

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.
  • The RolloutProgress is set to Unverified.
  • CommunicationStatus is OK.
  • Owner is set to nobody.

• If these conditions are reached then Verification process could be started.
• Verification team changes RolloutProgress to In Verification to start to work.
• First of all verifier must use an specific template for each product (see 417).
• Template fields are filled for each test by the verification team:
  • Accepted: Yes, No or does not apply.
  • Tested: By TP or VLD (Validation Team).

• QC Tests are:
  • Mandatory: The release is rejected if fails one or more of these tests.
  • Optional: These tests are not critical and the release could be verified even if it's failing.

• When the report is finished a new Executive Summary is created:
  • Includes a summary of tests failed and passed (Critical and non critical).
  • A list of comments for SR team.

• A new space into documentDB is created to store:
  • Release Verification Report.
  • Release Executive Summary.

• The documentDB link is used to set QualityCriteriaVerificationReport for each ticket.
  • DocumentDB space status must be set to FINAL.
  • DocumentDB space view must be set to public.

• If these conditions are reached then Verification Process is done!.
• And the Verification Team changes RolloutProgress to “StageRollout”.

(!) Verification Templates are updated if a new UMD Quality Criteria is released.

Documents

DocDB link	Expected Release Date	Expected Verification Date	More information
240	10. 02. 2011	10. 02. 2011	UMD Quality Criteria
418	10. 03. 2011	10. 03. 2011	EMI service mapping
417	10. 03. 2011	10. 03. 2011	QC Verification Templates

Verified Products

DocDB link	Verification Date	More information
460	-	CA update, version 1.37-1
1125	-	CA update, version 1.38-1
490	-	SAM Update-6
626	10. 03. 2011	SAM Update-7
1281	-	SAM Update-9