The problem & defect lifecycle

We’re constantly developing our products, adding new features and improvments. We work hard to develop and test the products we deliver to ensure it works as intended, but from time to time defects are introduced, these are logged as Problems.

What is a Problem?

We create problem records when we have reports from customers of things not working correctly – we can then link all the seperate reports to the same problem. This means that when our development teams investigate the issue, they can see all the information everyone has provided.

The defect process

When a problem is raised to us that requires a software change and is considered a defect it is assessed using the following defect process.

Potential defect identified

The first stage in the defect lifecycle is identification. We tend to become aware of a defect when you call us about a problem, but we also have alerting to let us know about performance issues or error messages that may be occurring. Our Service Desk teams will investigate; It may be something we’ve seen before and can fix quickly or provide a workaround – if they can’t fix the problem, they will escalate to our developers.

When an issue is escalated to Development, it’s assigned a defect reference which we use to track the defect. Your Incident remains active and is linked to the Problem (which is in turn linked to the defect).  We monitor how many customers are affected by a defect by how many Incidents are linked to the Problem number.

Defect prioritisation

To prioritise a defect we assess the following:

  • Impact on the customer – is the problem stopping you from doing your job?
  • Frequency of issue occurring – is it rare that the issue crops up, or does it happen regularly?
  • Clinical or safety risk – does the problem pose any risk to patient care or information governance?
  • Number of customers impacted – is this a rare issue, or is it widespread?
  • Workaround quality – can you work around the issue, and if so how easily?

Based on this criteria, we’ll prioritise the defect. We work on fixing defects in order, based on the priority they’ve been assigned and how long ago they were first identified.

Development testing and in-house testing

Before a software change is released it has to go through a testing process.

Firstly our Development department test the defect with the following steps:

  • Recreate the defect on an in-house test system.
  • Implement and test a solution to the defect
  • Review the changed code for any software changes that may affect other modules in the system.
  • Pass the solution back to the Service Desk.

Our Service Desk then test the system using the below steps to ensure the change works correctly:

  • Recreate the defect on a standalone test system.
  • Test the solution, implemented by our developers, to ensure the defect has been fixed has been successful
  • Perform a test schedule to ensure all other functionality in the module is unchanged. This may take several days to complete.


Once the defect has been through both our testing phases and is confirmed as fixed, we can incorporate it into a future release of our software.

Fix released

If the defect is identified as a major issue (a security issue for example), it could warrant its own emergency release. If it’s a lesser issue (such as a problem that occurs infrequently or has an acceptable workaround), the fix will be incorporated in a scheduled release.

Related Articles