Reproduce the error on an internal system

When the problem is clear you have to reproduce the error on an internal system. This reproduction is necessary to find the error in your source but also to test the solution later in time. When the error is reproduced you start debugging to find the correct spot.

Make sure you check for sessions/programs with similar functionality. Make sure all places where the error occurs are taken into the solution you are going to provide.

Check if the solution is a result of a previous fix. Contact the relevant Maintenance Engineer. Discuss the solution made. When the fix is indeed a bad fix the Solution Store need to be updated with a reference to the solution you are going to provide.

Close the reported defect when it is not a bug or it is a duplicate

Close a reported defect when after deep analysis it has become clear that the problem mentioned in the reported defect relates to an enhancement request or a complex situation of the Support Engineer could not over see. When you close the request always explain with more then one sentence why it has been closed. See such a closure as a small Knowledge Transfer. Put in the effort that relates to such a Knowledge Transfer.

Duplicates need to be closed as soon as possible to have a clear view on what is on hand to solve. When you close a request provide the reported defect number to Support so they can follow up in the reported defect that goes thru the whole maintenance process.

Correct the error

Correct the error and describe what has been solved. This description should contain a defect description as well as a solution description. Make sure the code (with the solution) is marked in the software so it can easily be found.

When the defect has to be solved in several versions make sure the solution design fits within the version. Each version could contain (slightly) different functionality.

When an error requires a complex solution have the solution design checked by a colleague before you start programming. Two know more than one and it avoids rework when the solution design does not fit it's purpose.

Always test you own modifications! Make sure that what you make works! Compiling is not enough as well as only testing the problem of the reported defect. Make sure you do not introduce a bad fix.

Bad fix could be:

  • Incomplete solution
  • Original problem not solved
  • New problem introduced

Ask a colleague to check your solution

Ask a colleague to check your solution technically and functionally. Never deliver a solution without a check of a colleague. Bad fixes influences the satisfaction of your customer directly. The more bad fixes you deliver the lower the level of satisfaction will be. To help your colleague do a review describe clearly what you have changed and why. What you took in consideration and what you left out on purpose.

Make sure the solution text is written in a way customers can understand it. Always use the same format so customers can search more easily for information. To support solution text writing a template including a spelling checker is no superfluous luxury. The template should support the writing of:

  • Release, version, package, module, session
  • Problem Text
  • Solution Text
  • Installation instructions if required
  • Solution dump if available

Deliver the solution and close the reported defect

When the solution is ready deliver it in the agreed format and for all agreed upon versions. Close the request and make sure your Support Colleague is aware of the solution.