Defect handling

Updated by Leigh Hutchens

Defect handling is the process of identifying, tracking, and resolving defects or bugs in software. The goal of our defect handling process is to identify and eliminate any problems that can negatively impact the functionality or performance of Quinyx.

Defect severity refers to the degree of impact that a defect or a software bug has on a software system or end users. It's a measure of how serious a problem is and how much it affects the functioning of the software. The severity of a defect is generally classified into several levels, such as critical, major, minor, etc. When we are contacted about a defect, the Quinyx Support team applies defect severity guidelines.

Defect severity guidelines

Mean Time to Resolve (MTTR)/Service Level Agreement (SLA)

So what is MTTR? MTTR includes every step of the recovery process, from initial notice to root cause analysis to fix and deployment. It's a performance metric that measures the average time required to repair or resolve a defect.

Defect handling workflow

Effective defect handling is critical to the success of any product. Our defect handling process involves the following steps:

  1. Defect identification: The customer reports a bug to the Quinyx Support team.
  2. 1st line Support team verifies the bug: The 1st line Support team verifies the bug and logs it in our defect tracking system.
  3. 2nd line Support team verifies the bug: The 2nd line Support team verifies the issue.
  4. Quinyx R&D team verifies the bug: The Quinyx R&D team verifies the issue and assigns it to a team (this is when MTTR begins).
  5. Defect resolution: The team resolves the defect by identifying the root cause and implementing a fix. The fix is tested and verified to ensure that it resolves the issue.
We aim to have defects verified within 48 hours. Defect severities are defined as part of the contract with the customer. Please note that this is an internal Service Level Agreement (SLA) and the timeframe we strive to be within, but it’s not an official SLA. Defects are prioritized based on their impact on the product and the urgency of the issue. High-priority defects are typically addressed first.

Summary of defect severity levels

Defect severity levels are used to classify defects based on their impact on the product and the urgency of the issue. The severity level of a defect determines how quickly it needs to be resolved and how much attention it requires from the support and development teams.

Critical (Severity 1) 

Impact: The system is completely down, the confidentiality of privacy data is compromised, or usable payroll data cannot be extracted for any customer.

Criteria To be fulfilled (one/more)

  1. The issue is a complete show stopper (it makes Quinyx completely unusable for the majority of our customers); for instance, if Quinyx is down/offline.
  2. Confidentiality of privacy data is breached.
  3. The majority of customers are affected.
MTTR SLA:   Prioritized before all other things and goes directly to R&D for investigation and a fix.
Urgent (Severity 2) 

Impact: Payroll data or cost calculation or reports specific to payroll is incorrect for more than 100 employees for one customer.

Criteria to be fulfilled (one / more)

  1. It affects one or more customers' ability to generate usable payroll data or cost calculations for 100 or more users and does not have a workaround.
  2. The error causes the cost calculation to be completely wrong for 100 or more users.
  3. The problem affects the payroll for the customer and occurred directly as a result of the latest release.
  4. A core functionality is not working in the application.
Schedule is not a workaround for Base schedule.
MTTR SLA: 5 working days or before the next salary run.
High (Severity 3) 

Impact: Incorrect program output with no workaround.

Criteria to be fulfilled (one or more)

  1. The problem directly leads to incorrect program output, causing a lot of extra work for one or more customers, and has NO workaround.
  2. It is a cause for major irritation amongst at least 30% of our Quinyx users, which may indirectly compromise our current or future relations with any customer.
  3. If there is a feasible workaround for a Severity 3 bug, it automatically becomes Severity 4.
MTTR SLA: 4 weeks
Normal (Severity 4)

Impact: An important function is broken, but there is a workaround.

Criteria to be fulfilled (one/ more)

  1. The problem makes one of the program's secondary functions unusable for one or more customers, for instance, the vacation planner doesn't work as it should.
  2. It makes one or more of the program's primary or secondary functions usable with a workaround only.
  3. It may lead to incorrect program output.
  4. It is “cause for irritation” amongst at least 15% of our ACV/users, which may indirectly compromise our current or future relations with any customer.
  5. When registering a normal bug that doesn't have a major impact on daily work, Quinyx support will provide a workaround as a permanent solution. If you accept this workaround, we downgrade the priority to low. Quinyx Support checks the status of the bug after 4 weeks to see if there is still an issue. The team will make a decision as to whether it's necessary to inform the affected customers.
MTTR SLA: 12 weeks
Low (Severity 5)

Impact: A nice-to-have function is broken

Criteria to be fulfilled (one/ more)

  1. This by no means compromises the usability of the program, for example, if the forum tab has stopped working.
  2. It is a bug that is easily circumvented or even unnoticeable for the majority of users. A workaround that takes less than 2 hours a month fixes the problem.
  3. It is a requested bug that is only relevant for a single customer and also fulfills the criteria for severities 1 and 2.


How Did We Do?