This shows you the differences between two versions of the page.
releases:brahmaputra:release_plan:storperf_milestone_e_report [2015/12/17 18:35] Debra Scott created |
releases:brahmaputra:release_plan:storperf_milestone_e_report [2016/01/06 16:58] (current) Mark Beierl |
||
---|---|---|---|
Line 3: | Line 3: | ||
1. Has your test framework been executed against a deployed OPNFV platform? | 1. Has your test framework been executed against a deployed OPNFV platform? | ||
+ | |||
+ | N/A. StorPerf is a standalone, exhaustive disk subsystem test that is executed manually post deployment. As a note, StorPerf is being tested inside an EMC private lab against an OPNFV platform deployed using the OPNFV FUEL installer. | ||
2. Has your deploy tool been executed in more than one Pharos lab? | 2. Has your deploy tool been executed in more than one Pharos lab? | ||
+ | |||
+ | No. As StorPerf is not part of CI, we are not executed in Pharos at this time. | ||
3. Have your test framework and test cases been run against more than one deployment tool? | 3. Have your test framework and test cases been run against more than one deployment tool? | ||
+ | |||
+ | N/A. | ||
4. Do you have all target Brahmaputra test cases available in your test suites? | 4. Do you have all target Brahmaputra test cases available in your test suites? | ||
+ | |||
+ | N/A. | ||
5. Is your test framework able to be repeated on the same infrastructure at least 4 consecutive times without failures? Does it meet the agreed upon criteria of "stable"? | 5. Is your test framework able to be repeated on the same infrastructure at least 4 consecutive times without failures? Does it meet the agreed upon criteria of "stable"? | ||
+ | |||
+ | The test framework is a self-consistency and code coverage test. This is part of the Jenkins build process and can be viewed here: https://build.opnfv.org/ci/view/storperf/ | ||
6. Have all known test issues (Jira tickets against your project) been documented and that documentation either integrated into the release or made available on a public page and pointed to through documents that //are// integrated into the release? | 6. Have all known test issues (Jira tickets against your project) been documented and that documentation either integrated into the release or made available on a public page and pointed to through documents that //are// integrated into the release? | ||
+ | |||
+ | Yes. | ||
7. Are all known issues (Jira Tickets) prioritized by severity of impact (critical, high, medium, low) to users? | 7. Are all known issues (Jira Tickets) prioritized by severity of impact (critical, high, medium, low) to users? | ||
+ | |||
+ | Yes. | ||
8. Do all known critical Jira Tickets have a workaround in place? | 8. Do all known critical Jira Tickets have a workaround in place? | ||
+ | |||
+ | Yes. | ||
9. Do all non-critical Jira Tickets have a planned disposition in place (ie. deferred-fix in later release or closed- won't fix)? | 9. Do all non-critical Jira Tickets have a planned disposition in place (ie. deferred-fix in later release or closed- won't fix)? | ||
+ | |||
+ | Yes. | ||
10. Is your documentation complete and checked in? If not, how do you plan to deliver it independent of the release? | 10. Is your documentation complete and checked in? If not, how do you plan to deliver it independent of the release? | ||
+ | |||
+ | At this time, the documentation is in the Wiki. Plans are in place to move documentation to git. |