Alert.png 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 Control"

From EGIWiki
Jump to navigation Jump to search
imported>Krakow
 
(No difference)

Latest revision as of 16:45, 29 November 2012

Technology Software Component Delivery Software Provisioning UMD Middleware Cloud Middleware Distribution Containers Distribution Technology Glossary



Where Quality Assurance aims to capture and describe the quality that any software delivered to EGI must meet, Quality Control ensures that the software will meet the quality described earlier.

Hence, Quality Control in EGI is involved in two phases of Quality Control in the relationships between EGI and its Technology Providers:

  • Proactive collaboration with Technology Providers relating to Test Plan execution and results.
  • Independent control of software quality covering key aspects of delivered software.

Controlling software quality is conducted in a two-step process. Both steps complement each other in the aspects of quality they control. Each step is described in greater detail below.

Contact

The contact person for Quality Assurance is Carlos Fernandez Sanchez, carlosf@cesgaSPAMMENOT.es

Quality Criteria Verification

This first step of active Quality Control within EGI uses an independent reference testbed deployed at IBERGRID premises. Each Product delivered to EGI for quality control will be assessed based on the amount of changes, i.e.e bugs and/or security holes that have been fixed in the update, and the type and amount of new features, if any.

Quality Criteria Verification will focus on functional tests around the areas of change of the Product under verification.

For each Product that is tested in this step:

  • Each Verification officer records a detailed report of what has been verified, and the outcome of it.
  • An executive report summarises the verification efforts and the outcome (i.e. whether accepted or rejected). Guidance is given
    • to StageRollout which aspects of the Product to re-test or pay special attention to,
    • to DMSU for newly discovered, not fixed, or non-critical bugs with workarounds available, for future guidance and support to resource sites and users,
    • to Quality Assurance for reassessment of existing Quality Criteria, or to develop new Quality Criteria, if applicable.
    • to Technology Providers describing in which circumstances which component of the Product has developed the erroneous behaviour.

Each set of verification reports is permanently stored in EGI's document database and made publicly available for review.

Staged-Rollout

Stage-Rollout complements the Quality Criteria Verification step in exposing the Product to real production conditions. Early Adopter sites that are interested in a timely rollout of the Product update take a part of their production infrastructure into a special "sandbox mode" where the Product update is installed under close scrutiny and exposed to a live environment and user requests.

The exact design and process of Staged-Rollout is described in the Operations context since Staged-Rollout needs close collaboration and planning within the Operations community.

Similar to Quality Criteria Verification, all Staged-Rollout activity is permanently stored in written reports per Product and will be publicly available for review and reference.