This page describes how we track and manage the bugs reported by our customers, QA team, or any other party involved in the product.

Bug management

Tracking issues

If an issue is reported by customers or linked directly to a particular customer project, it is tracked in a dedicated ticket, in one of the following portals:

• Customer Support

• Kbot Security

If a bug is reported by an email, a phone call, or another non-formal way, the Konverso consultant or the support engineer creates a ticket on the relevant portal, setting the user informing about the given issue as the reporter of the ticket.

If a bug is caused by our infrastructure settings, we create a DevOps ticket and assign it to either a consultant, or a DevOps team member.

If a bug is caused by the Kbot implementation, we create a development ticket for one of our engineers and add it to a sprint according to its priority.

Finalizing solutions

Once the solution is identified and implemented:

• If a code change is involved, a dedicated pull request is created to obtain code reviews approvals.

• A QA team validates the change in a developer environment.

• A consultant validates the change in a customer pre-prod or dev environment.

Once the changes are approved by the consultant, the customer ticket is updated with a comment explaining the correction, and the customer receives a notification.

After notifying the customer, we deploy the change. Depending on its criticality, urgency, and impact, the change may be done on:

• Production environment after notifying the customer.

• Pre-production environment, with a notification to the customer. Usually we request for feedback and confirmation of the resolution. Once approved, the change is deployed to the production host on a schedule agreed upon with the customer.

Note that there is no rule on the deployment timeline. This may vary from as low as 10 minutes to several months, depending on the severity, impact, and complexity of the bug.

Infrastructure changes

Infrastructure changes are usually internal and not requested by customers. If a customer wants to raise a request or incident related to an infrastructure topic, this one should be done through a regular ticket on our Customer Support portal.

All infrastructure changes, typically on our Azure IAAS environment, are done through a change request in the form of a ticket in our dedicated Jira project (DO). The tickets in this project have clear definitions of the target Azure resources, a list of reviewers and approvers, and some target delivery dates. The changes made to the infrastructure are documented on the related ticket.

As a set of examples, the scope of Infrastructure changes includes:

• Network and an associated firewall;

• VM resources and associated specifications (size);

• Service objects such as Microsoft Bot Service, OAuth2 endpoints as Applications, etc.;

• IAM (permission) changes.