The Content for this Page is still in Progress. Expect to see more in the near future.
TBD
Release Testing Plans: 2 of 3 - Candidate Release
to migrate
Validating The Next Release
For Solutions which use a Candidate Release, the next level of testing continues at the Release-Level. Basically, the objective of these tests is to validate the addition of new Features 'Accepted' from a Build Release to the existing Solution. That is, to ensure the new Features operate together, that they do not cause problems with previously released functionality, and that they operate with other upstream or downstream Related Systems.
For Solutions which choose not to use a Candidate Release, they must find ways to incorporate Certification Tests into the Build Release. To emphasize, Certification Tests are required, whether a Solution uses a Candidate or not.
Building Confidence & Trust
TBD
TBD
Getting a Release to 'Done'
TBD
Tests to Plan
For Solutions which use it, the third level of testing is Candidate-Level. These tests occur after Build Release's Last Sprint concludes and 'Accepted' Features are added to the Candidate Release. The Change Sets accepted at the end of a Build cycle are combined and a new Candidate Release Branch is created. The Features (and Stories) on the Branch represent the next advancement of the Solution targeted for Production.
This newer, larger Solution must undergo additional testing that was not (and could not) be conducted within each Sprint. This Certification Testing seeks to ensure that all changes within the Solution work properly together, as well as with other, related Solutions if appropriate.  The following types of testing apply to the Certification Stage of each Candidate Release.
- Integration Testing (Release scope)
- System Testing
- Non-Functional Testing
- User Acceptance Testing (Release scope)
The diagram at right shows the rough alignment of test cycle and break/fix activities during each Candidate Release Certification cycle. 0% at the left represents work yet to begin; 100% at the right represents all work being completed over the span of Certification.
Candidate-Level Testing occurs in the following locations:
- Candidate Release testing begins in the TST2 environment. After the creation of each new Candidate Release, the prior TST2 environment is wiped clean and the new Candidate Release Branch is deployed. Upon successful completion of a Smoke Test, Integration Testing begins in TST2 and the same branch is deployed to DEV2 in case Bug fixes are required (which are likely).  Controlled Data is then loaded into each environment.
- Once Integration Testing provides sufficient validation to warrant subsequent types of testing, the Candidate Release Branch is deployed to the QA2 environment over a recent copy of Production. These actions simulate a Move to Production for the Candidate Release. The remaining Certification test cycles now get underway.
- System and NFR Testing occur in QA2 using Uncontrolled Data Sets. If thoughtfully designed, these test cycles can often occur in parallel.
- All Features within the Candidate Release are evaluated for inclusion in UAT. It is common for some Features to have failed earlier tests or for the Customer to otherwise feel they are not ready for Production. The results of these evaluations feed into Production-Level Testing.
Separate Test Plans should be prepared for each Certification cycle and for each Test Type within.
These Test Plans are produced and executed by a QA group. Delivery Teams cannot be expected to manage and execute these tests. While each Certification cycle is underway, the Team(s) are busy working on the next Build Release and managing Sprint-Level & Build-Level Testing.