Proposals/bug reporting

From Riley Consulting Wiki
Jump to: navigation, search

Proposal to change the Bug-Reporting Process for RedX products

    The process under review is the process by which bugs which are found by current customers using the any RedX service are reported to the appropriate development team.

Current Process:
    The current process by which customer bugs are reported to the development team in informal in inefficient. The customer contacts a service representative with a complaint. That representative walks the customer through some unspecified series of steps to try and resolve the problem. An email is then send to Branden Cecala or Daren Stroud with the customer complaint. Sometimes logs and a stack trace are included. Other times there is little more information than 'Storm started freezing'.
The Problem:
    This process forces the developer to waste valuable time hunting down the information needed to recreate the bug. Long email chains between developers, customers and service representatives are not uncommon. Often the developer has to spend time telling the support person to do some rote things to either fix or diagnose the problem. This pulls the developer out of what he was working on, forcing him to go through a difficult context switch. It also wastes the support personnel's time as they have to go back and forth between the developer and the customer trying different things before the bug is officially passed to development.
Proposed Process:
    Each project/product manager is to give customer support a detailed checklist with two kinds of items on it. The first is a series of simple things the support person can do with the customer to try and clear up the problem. Things like resetting the cache, or rebuilding the database or re-importing the leads into Rolodex. This list will of course vary from product to product and is determined by the team who built the product. The second type of item on the checklist is a required data field. This can be things like the customer's operating system or web-browser, the app logs or any other data that can be gathered by the support representative that will aide in the diagnosing and fixing of the bug. Once the checklist has been completed, it is submitted to the testing department before it is given to the developers. The tester's job is to recreate the bug. If they can do so, then the bug is to be sent, with the checklist and the method to recreate it, to the appropriate project/product manager. In the event that the fixing of the bug brings to light a new process the support team can take a customer through to fix their problems, it is the responsibility of the project/product manager to update the support checklist for that product with that new procedure.
Outcomes:
    This process can help the entire chain of people involved in dealing with customer bugs to be more efficient. The support person has a reference document that they can go through while the customer is on the line to either fix the problem or gather the information necessary to do so. The testing department is actually used, which is a step up from the current process. Finally, the developers are not interrupted until the bug has been absolutely confirmed and recreated, resulting not only in fewer context switches for the developers, but also in quicker bug fixes.