Course Registration System
C2 Test Evaluation Summary
Version 1.0
Revision History
Date |
Version |
Description |
Author |
28/March/1999 |
1.0 |
Test Evaluation of R1.0 Release
(developed in the C2 Iteration - Initial Release. |
C. Smith |
|
|
|
|
|
|
|
|
Table of Contents
- Objectives
- Scope
- References
- Introduction
- Test Coverage
- Code Coverage
- Defect Analysis
- 7.1 Defect Density
- 7.2 Defect Trend
- 7.3 Defect Aging
- Suggested Actions
- Diagrams
C2 Test Evaluation Summary
1. Objectives
This Test Evaluation Report describes the results of the C-Registration
Release 1.0 system tests in terms of test coverage (both requirements-based
and code-based coverage) and defect analysis (i.e. defect density). These
tests were conducted during the C2 Iteration.
2. Scope
This Test Evaluation Report applies to the C-Registration R1.0 Release
implemented in the C2 Iteration. The tests conducted are described in the Test
Plan [5]. This Evaluation Report is to be used for the following:
- assess the acceptability and appropriateness of the performance
behavior(s) of the R1.0 system,
- assess the acceptability of the tests, and
- identify improvements to increase test coverage and / or test quality.
3. References
Applicable references are:
- Course Registration System Glossary, WyIT406, V2.0, 1999, Wylie College IT.
- Course Registration System Software Development Plan, WyIT418, V1.0, 1999, Wylie College IT.
- Course Registration System C2 Iteration Plan, WyIT500, V1.0, 1999, Wylie College IT.
- Course Registration System C2 Integration Build Plan, WyIT502, V1.0,
1999, Wylie College IT.
- Course Registration System Test Plan, WyIT501, V1.0, 1999, Wylie
College IT.
4. Introduction
The test cases defined in the Test Suite were executed following the test
strategy as defined in the Test Plan [5]. The test defects have been logged
and any medium, high, or critical priority defects are currently assigned to
the owner for fixing.
Test coverage (see Section 5.0 below) in terms of covering the use
cases and test requirements defined in the Test Plan [5] was 95% complete. 10
test cases involving operation of the system under a full load were not
completed due to bugs in the Load Simulator Software.
Code coverage was measured using Rational Visual PureCoverage and is
described in Section 6.0.
Analysis of the defects (as shown in Section 7.0 below) indicates that
the majority of found defects tend to be major problems classified as high or
critical in severity. The other significant finding was that software
components comprising the interface to the Course Catalog System contained a
significant number of defects.
5. Test Coverage
All test cases, as defined in the Test Suite, were attempted. 10 tests did
not complete due to software errors in the Load Simulator Software. Of the
tests cases executed, 15 tests failed.
The test coverage results are as follows:
Ratio Test Cases Performed = 110/120 = 92%
Ratio Test Cases Successful = 95/110 = 87%
The area of tests with the highest failure rate was:
- Performance tests involving access to the Course Catalog System
- Load tests involving access to the Course Catalog System.
- Installation of client software.
Further detail on test coverage is available using Rational RequisitePro
and the Test Case matrix.
6. Code Coverage
Visual PureCoverage was used to measure code coverage of the tests.
Ratio LOC executed = 94,399 / 102,000 = 93%
Approximately, 93% of the code was executed during the testing. This
coverage exceeded the target of 90%.
7. Defect Analysis
This section summarizes the results of defect analysis that was generated
using Rational ClearQuest. Section 8 recommends actions to address the
findings of the defect analysis.
7.1 Defect Density
Data on defect density has been generated using data extracted from
ClearQuest reports. Section 9 of this document includes charts that
illustrate:
- Defects by Severity Level (critical, high, medium, low)
- Defect Source (the component in which the problem or fault resides)
- Defect Status (logged, assigned, fixed, tested, closed).
The Defects by Severity Level Chart shows that 26 of the 36
logged defects are classified as high or critical in severity. This number
is considered very high and in addition all high and critical defects must
be closed in order for the Release to go out.
The Defect Source Chart shows an unusually high percentage of
defects are associated with the components (c-abx, c-xxx) which form the
interface to the Course Catalog System. In addition, many defects reside
within the software components that control installation of the client
software.
The Defect Status Chart shows that the defects are promptly
being assigned and worked on. Majority of defects have been verified and
closed.
In addition, analysis of the critical and high defects has shown that
many of these defects are due to poor response times in accessing the
Course Catalog System during conditions of heavy load. (Only 50% of the
Test Cases verifying performance requirements passed.)
7.2 Defect Trend
Defect trends (i.e. defect counts over time) is shown in the Diagram in
Section 9. This trend shows us that the occurrence of defects remains high.
If the trend continues, additional iterations may be necessary to find
remaining defects in the code.
7.3 Defect Aging
The Defect Aging Chart (see Section 9) illustrates that the time to close
some defects is more than 30 days.
8. Suggested Actions
The recommended actions are as follows:
- Continue to devote systems engineering resources to the response time
issue involving the Course Catalog System. This is a critical issue as the
R1.0 Release cannot be released without meeting the performance
requirements.
- Review the master schedule to see if a fourth iteration can be added to
the Construction Phase. The trend in defects over time indicates that many
defects remain in the code and an additional test cycle is recommended.
- Components with a high defect rate should be inspected prior to
resubmitting to a build. This includes c-abx and c-xxx.
- The high rate of Critical and High severity defects may indicate that
the design was incomplete and not properly reviewed. Plan additional
design reviews for the R2.0 Release.
- Fix the problems with the Load Simulator Software and re-run the
associated test cases.
- Investigate defect aging. Why are a number of defects taking more than
30 days to close?
9. Diagrams
|