Error, bug and its types in development and change request
You, as any company / customer, may have encountered an error during the development of your website or web application, at least while using it. It is very important to be able to distinguish between error and error and between error and CR (change request).
First of all, what is considering as error/bug during development, what error at all? Obviously, we can`t describe everything to the developer so that the page shouldn`t throw an error here, and the app shouldn`t return a blank white page there, but fortunately we don`t need to. These are clear expectations that every worthwhile developer. They do not attempt to raise a CR for each character to knock, as it is clear that normal user-supported operation is expected after and/or before a user interaction.
Essentially, any operation in the completed development, be it a website or an application, for which an expectation is defined in advance and does not meet it, is a bug. It is not necessary to be an actual error, it is enough to deviate from the previously agreed (! And written, accepted) expectations - however, any operation (reversing this line of reasoning) for which there is no defined, described operational expectation is not considered an error. For undefined operations, either an MVP of the operation needs to be clarified or completed before it can begin. .... We'll have another post about this soon.
Returning to the errors/bugs, we show you the most important error categories with a one- or two-sentence description, and hope it will help them to categorize and interpret errors and bugs in the near future.
- Critical:
- Critical errors can block / disable perform the function of at least a specific page or even the entire site or a business claim, thus somehow blocking the user from practicing the proper operation of the website as stated in the business claim. In these cases, there is no appellant, the developer (s), whether a company or an individual, should be contacted immediately and work should be started to fix the error immediately, as this could cause damage to the website owner, ranging from a few to several million forints.
- Important, but not critical:
- These are typically operational errors that do not or do not significantly (based on subjective judgment) / to a small extent affect business results. This can be practically anything that does not hinder or frighten the user. Although these errors are not SOS, it is also important to fix them as soon as possible, just because of the user experience (UX). Although the user may not be intimidated by a small thing in the short term, the constant inconvenience may prevent him / her from visiting / buying again on our website/web application in the long run.
- Slightly malfunctioning:
- While these errors are the least problematic, of course, correcting them in the shortest possible time is also positive. In the case of such errors, immediate intervention is not so important anymore, of course it is worth directing the operation to the right channel as soon as possible, as a good UX means a positive experience and perhaps returning users.
There are many ways to categorize errors, such as blocker, which often blocks the user in some process; and white page / blank page - that is a blank page appears on a website / web application, which also indicates the nature of the error.
Whatever way we categorize or just describe the bug, the most important thing is to be able to provide developers with the most accurate description possible to increase and help their work discover, identify the nature of the bug, and fix it ASAP.
Good luck in defining the bugs and malfunctions!
Author: Istvan Dombi
I work on IT development area since 2010, I had luck ever since to work on from simple corporate websites to e-commerce platforms and various API integrations (payment gateways and other third-party APIs) to complex international web applications. My main stack is backend development, within that PHP and GO languages.