Customer-Reported Defect Resolution Policy

ccppmop1591
HID_release_info_resolution_policy
Broadcom’s defect resolution policy applies to all actively supported Clarity releases including on-premise or SaaS editions, and secondary applications such as CA Open Workbench and the CA Mobile 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, methods for delivering fixes, and service level objectives (SLOs).
2
Criteria Used to Assign Technical Severity to Defects
After Broadcom Support verifies an issue, it is referred to the Clarity software development team to determine if the behavior is a product defect. If the issue is determined to be a product defect, the issue is assigned a technical severity and reviewed to determine if and when a fix will be delivered. If a defect is to 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:
S1: Critical
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.
S2: High
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.
S3: Medium
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.
S4: Low
A severity 4 (S4) defect pertains to an issue that does not impact the application's day-to-day use, 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 the delivery of fixes for customer-reported defects. A 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, product enhancements are not delivered in patches but are instead reserved for releases and service packs.
Product Releases
Quality is important to us. Product releases are typically produced every twelve (12) 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 marquee features, enhancements, and fixes for customer-reported defects. By providing fixes along with 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-impact
S3 issues. A high-impact S3 defect impacts multiple customers or includes a workaround that might not be readily consumable. Broadcom will make a 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 Broadcom 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 online community website.
Service Packs
As part of our effort to continually improve customer experience, service packs will be released quarterly until the next major product release. Service packs typically include new features, enhancements to existing functionality, and fixes to customer-reported defects. Service packs follow the same methodology for including defects as product releases.
Patch Releases
Patches address a specific set of critical issues that impact our customers and cannot technically wait to be delivered in the next release.
Scope
If an issue is critical (S1 or High-Impact S2), the delivery of a fix for that issue may be considered for a patch.
Broadcom will only actively fix issues and deliver fixes via patches for GA and the latest service pack for GA-1 versions. For example, with the release of
15.9.1
, we will only patch 15.8.1, which is the latest Service Pack that represents GA-1. Similarly, with the future release of 16.0.0, we will only patch 15.9.3, which would constitute GA-1. This policy allows us to focus our efforts on producing the best quality patches to ensure that customer implementations are successful.
Fixes delivered in patches are automatically included in future Service Packs and/or major product releases.
Exclusions
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.
  • Defects that require a schema change
  • Updates to client applications such as OWB, MSP, or Clarity Mobile Application (CA PPM)
  • 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 this
    no patch
    category.
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.
SaaS
Customer reported defects would be delivered via upgrades to major product releases and service packs per the SaaS upgrade schedule published here.
Cadence
Broadcom determines patch release cadence.
Quality
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
Broadcom does not perform full regression and performance tests on each patch. Patches are cumulative, however, if there is enough content to warrant full regression and performance testing, or there is a specific defect that warrants special testing, we will conduct additional 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 that represents 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 the best effort goal to test monthly. Based on these tests' outcomes, we may or may not recommend a certain update level be applied for use with the application.
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 product. We will provide an updated list of supported MSP updates on the Broadcom Support website.
For Jaspersoft, patch dates are more prone to variance due to many factors; however, we generally plan for a quarterly patch cadence.
Service Level Objective for Delivery of Customer Reported Defects
Defects fixed as part of a patch will also be included in the next available upcoming release or service pack. Details will be published as part of the Release Notes for a given version, including the included patch-level fixes. 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