Validating

When first looking at an issue there are a couple of steps that should be taken to validate that it is a real issue, and not a problem with the operation or state of the machine that the application was running on.

Is this the expected behavior?

The first step a developer should go through when faced with a new issue is to validate the issue. Put simply, this is deciding, if given what the user is trying to accomplish, is the software behaving in the way expected. It is typically at this stage that the developer will also do an “its different therefore it’s wrong” check. Given the long adoption cycle for Point Of Sale software, there are issues that will occasionally slip past the Product Management review process in which a user is effectively reporting that because a goal is achieved in a different means from a previous version, it is a bug.

If this is the expected behavior then the issue should be rejected and marked “works as designed”.

At this point the developer may also encounter an issue which works as designed, but the “bug” suggested in the issue is in fact a good idea for a feature that has not been implemented. At this point the developer should contact product management about the possibility of creating a new feature or a Change Request that incorporates the functionality indicated - and then make an entry in FogBugz to begin the change tracking process.

Pre – Testing

If it appears the software is behaving erratically it is important to try and recreate the fault. If the problem cannot be recreated or cannot be supported with logs by the developer or the business partners onsite it is most likely not an issue with the software, but an issue with the state of the platform the software was running on.

If the issue cannot be recreated and there are no logs to support it, the issue should be rejected and marked “can not reproduce”. The customer should be advised to enable auditing and logging for a time to see if the problem persists, and if additional data can be captured.