Normally we have an orderly and well defined process for tracking software defects. If the customer detects the problem, they enter the problem in their proprietary bug tracking tool. Then the help desk team enters this information into ClearQuest for us. A team lead assigns the ClearQuest defect reports to developers. Developers fix the problems. ClearQuest gets updated. Testers and then the customer gets the fix. All during this process, the Help Desk monitors progress by checking ClearQuest.
Currently there is a lot of test activity going on. Our internal testers are trying to complete a smoke test of our application suite. At the same time, our customer is performing a functionality test. The new change is that the customer is not entering problems they find in their bug tracking tool. Our internal test team is supposed to determine when the customer finds a bug, enter the information in ClearQuest, and forward the information to the dev team. I guess our customer does not want to incur the overhead of their own tracking tool for their testing.
I do not know how the deviations in process started. But we seem to be getting a lot of bug lists from our internal test team via Excel spreadsheet. They also provide a summary of smoke and functional test results to a broad audience. The spreadsheet appears to be going to all developers. And it is causing a lot of confusion. For now I am ignoring these spreadsheets and email because I am working on another task for development. But the other developers are going bonkers. Excel by itself is not a bad product. But using it to manage bug lists can be tricky. The new process seems to be adding to the pandemonium.
Home grown bug tracking schemes can work. But a real bug tracking system is better. Yes there is some overhead involved. However you do not have to worry about what version of the spreadsheet you are looking at. You also can avoid getting a bunch of e-mails with Microsoft Excel spreadsheets.
Use the Requirements Already - I am working on a release at work. Initially we were supposed to replicate some bunch of database tables that the customer had in an old system. We did a ...