Let's suppose that the customer has opened a trouble ticket on a problem in our software. To start with, our Help Desk team enters the information in our bug tracking tool. Then the Help Desk assigns the ticket to the team lead of one of our teams. The team lead often does a little analysis on the problem. Then the ticket is assigned to a developer on their team. These days I fill the team lead role for the application developers. But I am also a developer myself (sometimes I assign problems to myself).
While you are working on a trouble ticket, you are to enter your progress in our bug tracking tool. This allows the Help Desk to provide status to our customers. Let us suppose that I get lucky enough to figure out the problem and determine the code changes needed to correct it. Here are the steps I would take to get the software fix to our users:
- Document all code changes in a Microsoft Word document
- Generate a unit test plan to verify the fix
- Obtain a peer review of the code changes and unit tests
- Check the code changes into source code control
- Request a release number from the configuration management team
- Check the release number information into source control config files
- Label all files that are to be included in the release
- Generate the documentation that accompanies the release
- Submit a request ticket to the configuration management team to build the software
- Review the configuration management team work for technical problems
- Forward the software release to the internal test team
This is the list of steps that are taken for every single software change that corrects a bug in our system. Things get more complicated when there are more than one defect corrected in any given release. Other complications include the fact that some of our code is in a C++ client application, while some other code is in database stored procedures. The above list does not take into account all the additional steps that occur after the application development team is done their part in the release.
