Table of Contents

Bug fix policy

DynamicWeb makes it a priority to ensure that customers can expect fast fixes of bugs found in the latest published version of DynamicWeb within 2-20 business days depending on severity of the bug.

For this policy, a bug is any proven defect that does not allow you to use an existing feature as described in the documentation or as designed and there is no suitable workaround.

For this policy, other scenarios exist that are not a bug, but a support case or investigation. This could be performance issues where it can be due to an unintended implementation, custom code using DynamicWeb APIs, a solution that crashes and other situations where the cause has not yet been identified. A support case can later result in a bug if a defect is discovered.

A reported bug should be reproducible in a standard DynamicWeb installation without customizations and the responsibility for describing the steps to reproduce belongs to the party that requests a bug fix.

Note

When you use a supported version, you can get technical support for the given version. If your version is no longer supported, we’re not able to provide support even if you have a valid license and we suggest that you upgrade to a supported version or, preferably, to the latest available version.

Bug fix Service Level Objectives (SLO)

DynamicWeb sets service level objectives for fixing bugs based on the severity level and expected number of affected solutions.

Resolution timeframes

These timeframes apply to all DynamicWeb supported products, and any other software or system that is managed by DynamicWeb or running on DynamicWeb infrastructure.

  • Critical severity bugs to be fixed in product within 2 business days, after being verified
  • High severity bugs to be fixed in product within 5 business days, after being verified
  • Medium severity bugs to be fixed in product within 20 business days, after being verified
  • Low severity bugs to be fixed in product within 20 business days, after being verified

Classification of bugs

The severity of a bug will define how fast it can be expected to be reproduced, fixed, tested and released.

Critical

A critical defect is a defect that leads to the complete failure of the software system. There are no workarounds. Critical bugs need to be addressed as quickly as possible, as without a fix end-users will not be able to use the application.

For example, the following bugs will be classified as critical:

  • Cannot login into your account
  • Cannot checkout
  • Product's price is not displayed

High

A major defect is a defect that leads to the failure of a crucial part of the application. Workarounds or alternatives may exist, but they are not ideal.

For example, the following bugs will be categorized as major:

  • Search results do not match the search query
  • Cannot use one of more payment methods during checkout. (But can use other payment methods)
  • Part of product information cannot be displayed

Medium

A minor defect is a defect that causes problems in some unimportant or niche functionality of the system

For example, the following bugs will be deemed minor:

  • Cannot search past orders that are more than a year old
  • Cannot compare more than three products at a time
  • Thumbnails of product photos uploaded by users are unclear

Low

These defects usually arise in the aesthetic part of the application like misaligned user elements, overlapping text, and links that do not work.

Submission process

Bug reports for our software should be submitted through our Partner Support

To help on a fast resolution time of the bug, add as many details as possible to help us reproduce and fix the issue fast and efficiently.

Information that will help us reproduce the bug and issue a bug number:

  • Problem description - describe the bug and how it affects the solution
  • Steps to reproduce the bug - provide a bullet list of the steps taken to reproduce the bug
  • Expected result Describe what was expected to happen
  • Actual result - describe what actually happened
  • Link to solution - a link to the page or backend where the problem is experienced
  • Visual information - one or more screenshots, a link to a video reproducing the issue
  • Version where issue is experienced – i.e. DynamicWeb 10.1.25 or Swift 1.35, must be a supported version
  • Environment - Hosting (DynamicWeb Cloud, Own servers, Azure), Device, and OS
  • Breaking bug - specify if this is something that has broken and worked correctly or differently in earlier versions
  • Severity - indication of the expected level of severity this bug should be classified as

Bug fixing process

Once a bug report is verified a bug number is issued referring to the bug work item in our development system (Azure DevOps). The case will reference the bug number and the reporter will get notified about the bug number.

The bug number and its status can be found on the open bugs list

The fixing of the bug will be included in the current sprint if the bug is high or critical, otherwise it will be planned to next sprint. A sprint is 14 days/10 business days and starts every other Wednesday.

Once the bug is released, care will report back on the case and the reporter will get notified.

To top