Bugs happen. How do we fix them?

When we handle bugs, they follow a certain flow. In this in-depth article we tell you every step in the process. From discovery, until notification of a fix.

Bugs happen. How do we fix them?
Written by Anna Implementation Consultant
Posted on
Reading time 8 minutes

You could assume that Grace Hopper, a computer scientist at Harvard University, was not having the best day on September 9, 1947. Her computer was repeatedly returning errors for no clear reason. When opening it up, Grace found an actual bug, a moth to be precise, that was interfering with its functioning. Thereby, she became the first person to report a computer bug.

In reality, software bugs are not actually caused by things like moths (although our developers wish all fixes could be so straightforward!). Rather, a software bug is an error in the system that causes it to produce incorrect results or behave unexpectedly. At Easy LMS, we aim to build a bug-free system for you! But, the fact of the matter is that a bug-free system is as rare as a unicorn. Easy LMS is built by humans, and subject to human error, which means that bugs slip through from time to time 😧.

Since we know how annoying it is when there are bugs, we have a process in place to get bugs fixed ASAP! Here is an inside look at how this process works, starting from a bug's discovery by you, to the final fix.

Phase 1

I think I found a bug. What should I do?

The first step in the process is where you, as a client, come into play. Let’s pretend that you’re creating a new Exam to test a new hire’s knowledge of security standards. To add some flair, you go to upload your company’s logo. Instead of successfully uploading the image, you watch the loading icon spin, and spin, and spin …

After trying it a few more times, you’re probably pretty frustrated. Easy LMS is clearly not working like it should! What should you do? Contact support immediately! Support will be your point of contact throughout the whole process.

We will gather as much information as possible about the bug.

Through the chat box, you will reach a member of the support team, which includes myself, Eléonore, Brian, Sharda, and Priscila. One of our biggest goals at this point will be to gather as much information as possible about the bug. You might feel like you’re playing Twenty Questions, but this step is critical so that development can troubleshoot later on. You’ll be asked these questions:

  • What is the menu path to reach the location where the issue is occurring?
  • What is the exact URL?
  • Which component is affected? Exams, Courses, etc.
  • What are the names of affected content and users?
  • What platform and device are you using?
  • What were you trying to do when you encountered the issue?
  • What exactly happens when this issue occurs?

Once you share this valuable information, your job is over. Now you can sit back, relax, and let Easy LMS take the reins!

Phase 2

Reproducing the bug

Your job might be done, but it isn’t over for the support member that you’ve been talking to. With your permission, he or she will log in to your account and try to reproduce the bug. Referring to our earlier example, a support member would typically go to the same Exam and try to upload a logo him or herself.

If support cannot reproduce the issue, the process will end here. In a certain sense it is a good thing that the bug cannot be reproduced, as everything should be working. Nevertheless, it doesn’t help us get to the bottom of what you experienced. In cases like these, we might have a few more questions and will ask you to let us know if it happens again. On the other hand, if we can reproduce the bug (yikes!), the process will continue.

Phase 3

Support records the bug

Now that we’ve been able to confirm that it is a bug, we will record, or what we say “log”, all of that information that you provided in a structured report. We log bugs in the Easy LMS service desk. This report helps others pinpoint the exact place and aspect that involves the bug down the line. The other benefit of logging bugs in one place, is that other team members can easily see if another client’s complaint falls under an existing bug.

Support will then tag your conversation with the bug ID number. That way, we can find your contact information to ask you for more information, or give you relevant updates.

Phase 4

Quality Assurance/Control reviews the request

Once we log a bug in the service desk, it will reach Caroline, who deals with Quality Assurance/Control. During this process, Caroline acts as a middleman between support and development. She will triple check that the issue is, in fact, a bug. This prevents us from wasting valuable development time. After she reviews the report, one of two things will happen.

Firstly, she could find that the issue is not actually a bug. Perhaps, what support thought was a bug was actually how it was supposed to function. At other times, she will find that it was related to a setting that we overlooked. When she finds this out, she will notify the support member who logged the bug and one of us will contact you.

Alternatively, she can confirm that the issue is a bug. When this happens, she will make sure that all of the information that the developers need is there. If anything is missing, she will reach out to support. Once this step is complete, she will mark the bug as “escalated” in the service desk, and prioritize the bug fix accordingly. Now the bug is out of support’s hands, and on its way to the developers.

Phase 5


Dev support is where the magic happens.

Developer support, a.k.a. dev support in the tech world, is always available. In fact, we always have one member of our development team devoted to addressing all highly technical issues that come through support. The person in this role changes each week. Dev support is where the magic happens. The developer will identify the underlying problem, and build a fix for it.

Phase 6

Quality Assurance/Control tests and applies the fix in the next release

You might be surprised to learn that not all fixes go live as soon as the developer is done! Instead, Caroline first tests that the fix works, and makes sure it doesn’t break anything else. Fixes are then launched in the next release, which means that they are released together with all new updates to the system. The version that gets released is preceded by a test version, that Caroline thoroughly checks for any errors. Even though bugs are typically applied in the next release, it doesn’t slow the process down as we have multiple releases per week!

How long does it take to fix a bug?

We would like it fixed immediately.

This is a difficult answer to give, as it varies with each bug. We can’t give you a strict deadline for when it will be fixed, but typically bugs are addressed, at the latest, within the month. The two main factors that determine the amount of time it takes to fix a bug is its impact, and how difficult it is to fix. For example, if no one could access Exams any longer, it would be a pretty big issue and take top priority. Clearly, we would like it fixed immediately. Nevertheless, we also have to factor in how difficult it is to fix. Even though it has a high impact (affects many accounts and is an important feature), it could take more time if it is a complex problem.

Will I be informed when a bug is fixed?

Woohoo! The bug is finally fixed! You will be notified by the support member that you have been in contact with as soon as it gets released.

At this point in time we will also thank you for your patience. Bugs are no fun for anyone! Not for you. Not for support. Not for development. So, your understanding and communication with us is always appreciated, and really helps make the process a bit easier on everyone involved.