Bug management

This section page describes how we track and manage the bugs reported by our Customerscustomers, the Konverso QA team, or any other party involved in the product, are tracked and managed.

The issues

Bug management

Tracking issues

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

• Customer Support: https://konverso.atlassian.net/servicedesk/customer/portal/1

• Kbot Security: https://konverso.atlassian.net/servicedesk/customer/portal/10

...

If a bug is reported to Konverso by Email, Phonean email, a phone call, or another non-formal way, then the Konverso Consultant or Support member will create consultant or the support engineer creates a ticket on the relevant portal, setting the reporting user informing about the given issue as the reporter on of the ticket.

If the bug has an Infrastructure cause, Konverso will create and link a dedicated DevOps ticket, assigned to a Consultant or Ops team member.

Suppose the bug has a kbot implementation root cause. In that case, Konverso will create and link a dedicated Kbot Developer ticket, assigned to a relevant engineer, and assigned to a particular sprint based on its criticality.

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 will validate team validates the change in a developer environment.

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

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

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

• Production environment after notification to notifying the customer.

• Pre-Production production environment, with a notification to the customer, with typically a . Usually we request for feedback / and confirmation of the resolution. Once approved, then 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 10mn 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, the this one should be done through a regular ticket on our support portal: 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 a clear definition 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 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.

...