Difference between revisions of "PROC05 Software deliverable testing"
Line 55: | Line 55: | ||
== Manual Test == | == Manual Test == | ||
<br> | <br> | ||
{| class="wikitable" | {| class="wikitable" | ||
Line 63: | Line 63: | ||
! Responsible | ! Responsible | ||
! Action | ! Action | ||
|- valign="top" | |- valign="top" | ||
| 1<br> | |||
| <br> | | <br> | ||
| <br> | | WP manager | ||
| <br> | | | ||
| <br> | As for the classical deliverables (the documents), 3 reviewers (1 moderator + 2 reviewers) will be assigned to each software deliverable. The WP manager has the responsibility to identify the reviewers. | ||
In the case of deliverables containing more than 1 software releases, there will be 3 reviewers for deliverable plus supporting testers | |||
|- valign="top" | |||
| 2<br> | |||
| <br> | |||
| Developers<br> | |||
| The candidate release should be installed on the testing/devel instance <br> | |||
|- valign="top" | |||
| 3<br> | |||
| <br> | | <br> | ||
| | | Reviewers | ||
| | |||
The reviewers will perform the validation tests on the candidate release. | |||
Tests will be executed within a week. During this period, the testing/devel instance should not be updated. Reviewers and developers should agree on the week to perform the tests. | |||
|- valign="top" | |||
| 4<br> | |||
| <br> | |||
| WP manager<br> | |||
| | |||
Ensure that outcomes of the testing process are part of the short document describing the software release. | |||
|} | |||
== (Semi-)Automatic Internal Testing procedure<br> == | == (Semi-)Automatic Internal Testing procedure<br> == |
Revision as of 15:45, 31 May 2016
Title | Software deliverable testing |
Link | https://wiki.egi.eu/wiki/PROC05_Software_deliverable_testing |
Owner |
Quality Manager |
Status | Approved |
Approval date | |
Related document |
Overview
This procedure is part of Review procedure for deliverables and milestones. It describes how quality check is done for SW deliverables.
Definitions
Please refer to the EGI Glossary for the definitions of the terms used in this procedure.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", “MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
Entities involved in the procedure
- XX: person who...
- XXX:
Requirements
Production tools, which are part of EGI Catalogue, should have a production and a testing/devel instance (at least 2 instances in total)
Steps
Each product team should choose between two possible ways to verify the quality of its release:
1. Manual test
2. (Semi-)Automatic internal procedure to test the release In both cases, tests and short document must be finished by the deliverable deadline in the DoA.
Manual Test
Step# | Responsible | Action | |
---|---|---|---|
1 |
WP manager |
As for the classical deliverables (the documents), 3 reviewers (1 moderator + 2 reviewers) will be assigned to each software deliverable. The WP manager has the responsibility to identify the reviewers. In the case of deliverables containing more than 1 software releases, there will be 3 reviewers for deliverable plus supporting testers | |
2 |
Developers |
The candidate release should be installed on the testing/devel instance | |
3 |
Reviewers |
The reviewers will perform the validation tests on the candidate release. Tests will be executed within a week. During this period, the testing/devel instance should not be updated. Reviewers and developers should agree on the week to perform the tests. | |
4 |
WP manager |
Ensure that outcomes of the testing process are part of the short document describing the software release. |
(Semi-)Automatic Internal Testing procedure
Step# | Responsible | Action | Prerequisites, if any | |
---|---|---|---|---|
Revision History
Version | Authors | Date | Comments |
---|---|---|---|