I thought I’d quickly write a little explanation of what happens when a customer (or we) find a bug in the website. Most of the time, the process goes through the following stages:
- Coding Fixes
Let’s discuss them in more detail:
Pretty self-explanatory, a customer or one of us comes across a bug. We get told about it.
Once a bug comes to our attention, we log the bug information (or what is mentioned to us as a bug). In some cases, the ‘bug’ is not a bug but a feature or a core funcitonality – e.g. we don’t store credit cards or allow customers to edit orders themselves once an order is placed.
Time to see if we can replicate the bug. A good 20 – 30% of all bugs reported to us are not replicable. Whether it’s due to different browsers or operating systems, specific extensions on browsers creating conflicts or even the server / network the customer is on; we are not able to replicate the exact environment that caused the bug.
If we are not able to replicate a bug, we can’t fix it. Thus the log – we keep a log on this issue, see if it (or something close to it) happens again. If enough people manage to replicate this, quite often we are able to acquire sufficient information from the various individuals to finally replicate the bug. Then it’s on to the next step…
How big an issue is this bug? Bugs are assessed on a variety of factors:
- number of individuals affected
- where in the checkout process this is happening (a checkout bug is much more important than one in the article pages)
- number of functions it affects
- other bugs that have not been fixed
- complexity of problem (if it’s something I could fix compared to a professional developer)
Once the assessment is done, we slot it into our ticketing system with our developers
Next up is the fixes and coding. Dependingo n the complexity of the problem, either I or our developers will work on the problem. If it’s an issue which our developers are able to solve, we normally have to wait due to their workload. This can often cause long delays. Unfortunately, finding competent developers whom we can trust is difficult.
Once a fix has been made, we have to test it. Obviously the developers have tested it, but to ensure the site does not break we generally do testing ourselves as well. This often can bring up new problems, so off we go back to coding fixes till the fix passes.
Finally, we deploy the fixes. At this point, we do one last test to make sure the bug is fixed and nothing else breaks. Once that happens, we are good to go. We keep an eye on the problem, just in case it crops up again, but generally it should be fixed and we’re good to go fix another bug.