“Why is MY bug not fixed yet?” A simple question with a not so simple answer that we would like to try and explain.
Any update for Informant is of the best quality that we can release at that time. The Informant application IS tested both internally and by our beta team but with a flexible and powerful application such as Informant its not possible to test every usage case or settings combination and because of this a bug may get out into production and into your Informant. We take ALL bug reports seriously. Often, something that is reported as a bug is acutally the applications normal behavior but that behavior may not be what the user is expecting. That is where our team starts when a support case comes in reporting a bug.
Informant product updates fix the bugs that we have found or that have been reported to us. At the same time with each update some customers tell us, “the update is nice but it doesn’t fix MY bug, why?” We want to explain the difference when it comes to bugs between “weight” and “wait” to try and address this common thought or question from our customers. Handling bugs is a team effort between ourselves and our customers, often for the simple reason because you can see the issue on your device and you have to be “our” eyes on it so to speak.
“Ok but what can I do to help?”
Often our support team will ask for more information or for what we call “STR” (Steps To Reproduce) The STR are one of the most helpful things that a customer can provide to expedite the bug confirmation and start the process to correct it.
“What should I include in my STR?”
The most effective STR are the most detailed. We often ask users to provide the steps from the time they pick up their device until the bug occurs, almost as if you were talking to your doctor or mechanic about a concern. While we don’t need pages and paragraphs of description more detail is always better.
Screenshots are also very helpful to illustrate an issue or to show the progression of the concern. If you are not opening your support case from inside of the application other useful items that you can include are the version of the app that you are using, the version of the OS, and what device you are using.
STR is the most important element of any bug or malfunction report and helps us in all ways to help you more quickly.
“Any other things that I can do to help?”
Sometimes we may provide a procedure for you to try to either correct the issue or provide further information to us. Please follow the steps and let us know your results.
In rare cases if a bug cannot be reproduced in our lab then it is recorded and we have to hold it waiting to see if another user reports the same or similar issue. These second or third reports often yield a clue or something that helps us to identify the issue and move it to the next level and onto correction.
The system and how it works-
Once the proven bug is logged to engineering our product manager reviews it and the item is given a score or “weight” if you will. We ask if the bug is impairing the use of the core application features, then we look at the usage case and estimate how many customers are affected in their normal usage of the application. Our engineering team then reviews the issue and gives it a value on how long it will take to engineer a fix and how involved the fix will be to implement. We then review the engineering schedule and if a new bug has a higher weight than what is in progress and fits with the engineering availability it will be given a higher priority than another bug. Software development is fluid by nature and changes on the fly to the development roadmap are not uncommon. This is why we don’t ever promise a specific date when a bug will be fixed. Unless the item to be fixed is in beta and almost to production we won’t tell you to look for the fix in an upcoming specific release. No one likes to hear “wait” but sometimes its the best answer we have to offer.
In the end-
We know that the most important bug is the bug you are seeing but we, having to look at the whole picture regarding the application, have a different perspective and have to act accordingly. No bug is forgotten and even though some may not be able to be addressed as quickly as others that doesn’t mean we are ignoring them. Some bugs are fixed as side effects of other fixes and overall application improvements. In the end we work to address all of the confirmed bugs as well as continually improve the applications we offer.