We take great pride in producing software which contains very few bugs and program errors. We test thoroughly before software is released and concentrate a great deal of effort when writing code to ensure that it is solid and stable.

No software however is 100% bug free. When bugs are discovered, they are treated with extremely high priority, and every effort is made to find a solution, and produce program updates if necessary.

Bug fixes are the most expensive and disruptive tasks which we perform, because fixes require our most experienced and expensive developers, and if necessary they will work long hours late into the night to resolve bugs. Routine support on the other hand can usually be performed by those without the same level of expertise and cost. This is why we make such a careful effort to avoid bugs in the first place.

Unfortunately, more than 90% of "reported" bugs, are not bugs at all. Bugs are where programs do not perform as they were intended to perform. There are a number of things which can occur where the results you get are not what you want, but where the problem is not a bug. For example:-

• Data becomes corrupted by some means other than the software.
• hardware devices fail.
• device drivers are not installed correctly.
• operation instructions have not been followed.
• the software is not designed to implement the feature you want in the way you want it.

None of these examples constitutes a bug.

If you have difficulty in obtaining the results you want, look in the support forum for a solution or post a question. If you want additional features or different behavior in the software refer to the other sections of this site on how to get enhancements and additional features.

If you are really sure that you have identified a bug, then before making a bug report check each one of the following:-

1. verify that windows will perform a clean boot, without any warnings, errors or notifications.
2. verify that all devices are operating cleanly in device manager, with no warnings or errors.
3. check the event log in Event Viewer to ensure that nothing has occurred which might indicate a problem.
4. verify that printer test pages print cleanly for all installed windows printers.

Problems in any of these areas could and would be likely to cause the software to malfunction in a manner that was not the fault of the software. In the event where you file a bug report, and it is subsequently discovered that one of these problems with system configuration is the cause, then you should expect to be billed for the time taken to resolve these system errors. Fix such errors first, and it is likely that the problem will fix itself.

If filing a bug report, you need to describe what we can do to duplicate the problem, describing the result you actually get, and the result you expected to get. In order for us to identify faulty behavior by a program, we need to be able to duplicate the behavior you describe. The first step our engineers will take is to follow the steps you describe to see if the software behavior is what you describe. If so, and the behavior is incorrect, we will be able to identify why it is behaving incorrectly and what needs to be done to correct the problem.

Use common sense. Saying "X does not work" is the type question that would typically be asked of a first tier support provider, and this type question never reaches experienced staff that write and debug programs. If you direct such a question to second tier support organisations such as ourselves, you are likely to get billed for the time taken to respond.

On the other hand, sending three and a half MB of scanned images of receipts is equally ridiculous. We may well ask for copies of the Dr Watson.log file or the output of the event viewer, or data backups. But if we want this data, we will ask for it. Don't send it unsolicited.

Once again, use common sense. What we need is to be able to duplicate the problem. If you can do this using sample data files this is preferred since our engineers will not need to learn your configuration. Make your description as simple and uncomplicated as possible. Don't, for example, use an example with 5 items in a product sale if an example with one item on the sale will demonstrate the problem just as clearly.

Finally, we have never yet billed a client for time spent fixing a genuine bug. But if we put one of our most expensive developers to work tracking a "bug", and they spend 5 hours work only to discover that there isn't bug, and that the user has failed to follow documented procedures, then we are not very pleased.

In cases where you are unsure whether you have found a bug, it is best to search the forum and knowledge base to see if there is a solution to your problem that has already been uncovered, and make a posting to the forum detailing what happens if necessary.

In cases where you are fairly certain that you have identified a bug, we prefer for you to notify us by email to bugs@himatix.com rather than posting on the forum. This is because real bugs could open up security vulnerabilities for dishonest users, and in such cases we would prefer to fix the problem before it becomes too widely known.

Back to top