Customer-Reported Defect Resolution Policy
This standard defect resolution policy applies to all active supported releases of
Clarityincluding on-premise or SaaS editions, and secondary applications such as CA Open Workbench and the CA Mobile Time Manager app.
This document provides a standard resolution policy for customer-reported defects. Resolutions are made in order by assigning a relative severity and priority for each defect. This document describes the criteria for assigning severity, the methods for delivering fixes, and the service level objectives (SLOs).
Criteria Used to Assign Technical Severity to Defects
After CA Support verifies an issue, it is referred to the
ClaritySoftware Development team to determine if the behavior is a product defect. If the issue is determined to be a defect in the product, it is assigned a technical severity and reviewed to determine if and when a fix will be delivered. If a defect will be resolved, the fix is delivered in a defined package according to its technical severity level and complexity. The technical severity levels are defined as follows:
A severity 1 (S1) defect pertains to a system crash, major memory leak, unrecoverable data corruption or loss, major functional deficiency without a workaround, failure of application installation or upgrade, prevention of further feature testing within the same area or items considered offensive in the software, UI, or documentation.
A severity 2 (S2) defect pertains to a major functional deficiency, recoverable data corruption or loss, documentation or error messages that could cause users to take incorrect actions, significant performance degradation, localization or globalization issue that makes features unusable by non-English speakers, and web application security vulnerabilities through which hackers can exploit application data. Severity 2 issues may or may not have a workaround.
A severity 3 (S3) defect pertains to feature deficiency with a reasonable workaround, minor documentation errors, usability or accessibility issue causing minor inconvenience, non-significant performance degradation, incomplete/incorrect un-installation of the application, or incorrect error messages.
A severity 4 (S4) defect pertains to an issue that does not impact day-to-day use of the application such as minor low visibility cosmetic errors or inconsistencies.
Standard Delivery Methods for Defect Resolution
The delivery method for a resolved defect depends on its technical severity and the feasibility of a fix. Determination is made based on complexity, risk, and technical severity. Three methods are available for delivery of fixes for customer-reported defects. The fix for a resolved defect is delivered in the next:
- release; or
- service pack; or
- maintenance patch (for critical issues).
In some cases, a defect cannot be addressed outside of a release.
Typically, enhancements to the product are not delivered in patches and are instead reserved for releases and service packs.
Quality is important to us. Product releases are typically produced every six (6) months and an emphasis is made on resolving customer-reported defects as part of those releases. Our main delivery mechanism for customer-reported defects is through our product release cycle.
Product releases include enhancements and marquee features in addition to customer-reported defects. By providing fixes along with those enhancements, we ensure that we deliver a high quality, well-tested product for our customers.
During a product release cycle, particular focus is given to S2 and
high-impactS3 issues. A high-impact S3 defect impacts multiple customers or includes a workaround that might not be readily consumable. CA will make reasonable effort to address low impact S3 defects even if a workaround is available. In some cases, based upon a review of the defect and the customers impacted, a determination may be made not to fix the defect.
Low severity (S4) product defects will be considered for resolution on a case-by-case basis once the issue has been confirmed as a defect. Any cases that are linked to S4 defects will be closed once the issue has been confirmed. S4 defects will be reviewed for releases only and CA will make reasonable commercial efforts to incorporate them into a given product release. Based on customer reports, area of functionality, and other considerations, we might decide that a defect will not be fixed. In this case, the customer will be notified through our standard Support process or the
Classic PPMonline community website.
As part of our effort to continually improve
Classic PPM, service packs will be released approximately three months after a major product release. Service packs typically include enhancements to existing functionality and fixes to reported defects. Services packs follow the same methodology for including defects as product releases.
Patches address a specific set of critical issues that impact our customers and cannot technically wait to be fixed in the next release.
If an issue is critical (S1 or High-Impact S2), the delivery of a fix for that issue may be considered for a patch.
We will only actively fix issues and deliver them via patches for GA (
15.8.1) and GA-1 versions approximately every other month (for example, GA in January, GA-1 in February, GA in March, and so on). This policy allows us to focus our efforts on producing the best quality patches to help ensure customer implementations are successful.
Fixes delivered in patches will be included in the product release that is currently under development (non-GA/next X.X.0 release or X.X.1 service pack). Non-GA releases have, as part of the lifecycle, a code freeze date. Should a patch be released after the code freeze date for the version currently under development, those fixes will be included in the first patch scheduled immediately after the new version is GA. For example, a 22.214.171.124 patch would include the defect resolutions delivered after the code freeze date for a 15.8.1 product release.
In alignment with our End-of-Service (EOS) and End-of-Life (EOL) policies, fixes will not be generated after the EOL status for a specific product version is announced.
Some fixes that otherwise meet the criteria for resolution in a patch may not be feasible to deliver in this way due to complexity, risk, and impact on other customers. In addition, defects in the following areas are not candidates for a patch and are reserved for releases or service packs only:
- Defects that require a schema change
- Updates to client applications such as OWB, MSP, or Mobile Time Manager
- Defects that would require a major user interface change
- Defects for integrations such as Rally (formerly known as CA Agile Central) and connectors such as Microsoft Project
- Product Architecture Stack (Compatibilities) and localization changes
- Custom applications built using our REST APIs
- Defects for beta functionality (beta functionality is not supported in production environments)Other areas may also fall into thisno patchcategory.
For the GA and GA-1 releases, we will evaluate which client-side fixes are included in patches once per quarter. The standard fix criteria for risk and complexity are applied.
When the SaaS Team applies a patch to any instance within SaaS, the latest patch level for that release will be applied.
Patches are released in a short time frame with more limited testing than the testing done for a release. Patches produced for the GA and GA-1 versions are released approximately every other month (for example, GA in January, GA-1 in February, GA in March, and so on) to provide a quick resolution to critical issues.
Patches are intended to resolve a specific issue or issues and will include fixes rolled up from previous patches (patches are cumulative). All patches go through QA testing, but the scope of testing is limited only to:
- Verification of the specific fix resolved in the patch
- Regression and integration test coverage limited only to the impacted product areas
We do not run full regression and performance tests on each patch. Because the patches are cumulative, when there is enough content to warrant full regression and performance testing, or there is a specific defect that warrants special testing, we will conduct that testing as appropriate. Extended QA validation includes regression testing, performance testing, and selective PAS testing as needed. Any patch that has been performance and regression tested will be noted in the patch README.
Customers should be aware that a software patch could potentially have unintended adverse consequences with respect to the performance or functionality of the software in the customer environment.
Customers should not apply software patches directly to production systems without first verifying them in a test environment which is representative of their production system in terms of configuration and data volumes.
Third-Party Product Defects
For products like Microsoft Project (MSP), we perform high-level tests on newly released updates once every two months with a best effort goal to test monthly. Based on the outcome of these tests, we may or may not recommend a certain update level be applied for use with
If we encounter a defect in the MSP update which impacts our integration and does not deliver a quality experience for our customers, we will neither recommend nor support that update level for use with the released
Clarityproduct. We will provide an updated list of supported MSP updates on the CA Support website.
For Jaspersoft, patch dates are more prone to variance due to many factors, however, we generally plan for a quarterly patch cadence.
Other CA Applications
Other CA applications that work with
Classic PPM, such as Mobile Time Manager, first released with
Classic PPMMobile 3.0, first released with
Classic PPM15.5, follow the same scope and priority procedures as outlined above. Fixes for these products may take place on the server-side or on the CA application client-side of the functionality.
- If an issue impacts only server-side functionality, any given fix would be delivered in either the main release under development or aClassic PPMGA or GA-1 patch. It may also be decided that the issue will not be fixed.
- If an issue impacts only application-side functionality, the fix may be included in the main application release under development at that time. It may also be decided that the issue will not be fixed.
- If an issue impacts both the server and the application, any given fix would be delivered only in the main release. It may also be decided that the issue will not be fixed.
Service Level Objective for Delivery of Customer Reported Defects
Defects that are fixed as part of a patch will also be included in the next available upcoming release. Details will be published as part of the Release Notes for a given version including the patch-level fixes that are included. The delivery method varies by severity:
- S1: patch
- S2: patch or product release
- S3: future product release or closed
- S4: possible future product release or closed