Highlight a phrase and click this icon to search it on Swyx-Forum    Highlight a phrase and click this icon to search it within the Swyx Knowledgebase    Highlight a phrase and click this icon to search it using Goolge    Highlight a phrase and click this icon to search it using Wikipedia

Highlight a phrase and click this icon to search it on Swyx-Forum    Highlight a phrase and click this icon to search it within the Swyx Knowledgebase    Highlight a phrase and click this icon to search it using Goolge    Highlight a phrase and click this icon to search it using Wikipedia

List of Blogs
Search Blogs

Blog Archive

Most recent blog entries

 

Most recent blog entries

 

Jan21

Written by:Martin
21.01.2008 21:04 

All software has bugs. SwyxWare is no exception. To make sure that you not miss something severe before releasing a version you have to test consistently and you have to keep track of all bugs you find. We're using a database to store and track bugs. The vast majority of them are found and fixed internally during development and test, but some of them are reported by customers after the software has been released and will often be fixed in a maintenance pack, bugfix release or a future major version.

For each bug we have to decide how important it is, if and when to fix it. To do that, each entry in the database gets a severity level and a priority. The severity defines the impact this bug has on customers using SwyxWare, the priority is used for sorting them. Higher priority bugs will be fixed before lower ones. We always have to makes compromises, of course, because there is no time to fix all of them. We have to pick the important ones and do the minor ones later. 

Severity and priority are related, i.e. for each severity level we've defined default priority. But that relation is not fixed. Some examples: A minor severity bug like a spelling mistake in a configuration dialog might get a high priority because the fix is easy with very small effort. If fixing a high severity bug has a big risk of negative side effects and if it's in a rarely used feature it might get a lower priority and might be fixed in the next version instead of an upcoming maintenance pack. If there's a workaround the priority is typically less than default, too. But diverging from the severity-driven priority is the exception, not the rule.

There's another important field in our bug tracking database which allows linking the record to the Swyx support database. It means that the issue had been reported by a customer. If more than one customer reports the same problem, we can see that too. Bugs of the same severity which have a non-empty ticket ID are always more important than bugs without one. Or in other words: If no customer reported it and there are no other indications that it affects customers, it's not important enough for a quick fix, maybe even not important enough to be included in a maintenance pack or bug fix release.

This mechanism is the reason why it's important to contact us when you have a problem with SwyxWare. If it's a bug, your report influences the priority for fixing it. But even if it turns out to be a configuration mistake instead of a bug, if we can see that a lot of customers make the same mistake, we can address that in a future version by changing the software or more immediately by writing a knowledge base article you can read on our web site.

 

 

Tags:

 

1 comment(s) so far...

Re: To fix or not to fix

Very good! Thanks for this detailed description.

By tom.wellige on  22.01.2008 10:10

Your name:
Your email:
(Optional) Email used only to show Gravatar.
Title:
Comment:
Security Code
Enter the code shown above in the box below
Add Comment  Cancel 
Blog Help
Sponsors