Ticket_procedure - hpgDesigns/hpgdesigns-dev.io GitHub Wiki

A formal procedure for the life of a bug ticket is as follows:

• Reporting phase
  1. A concerned person ("reporter") discovers a bug.
  2. Reporter attempts to reproduce the bug. In the case of Errors, if it doesn't reproduce, continue anyways.
  3. Reporter files a ticket with as much information as possible. An outline of reporting tickets is documented at Bug reporting.
• Tech phase
  1. A tech lead receives the ticket.
  2. Tech lead attempts to reproduce the bug and fills out the ticket with any additional information and tags as appropriate. Note that at this point, there may be insufficient information, at which point the tech lead will attempt to collect more information from the reporter. Tickets like this should to be tagged as "Needs Information" or "Needs Feedback". If the tech lead is familiar with the problem/solution, he may give a rough outline of what work needs done.
  3. Generally the tech lead should also include a test case for QA. Usually this is just the steps to reproduce.
  4. Ticket is assigned a priority, which may fast-track it into development or may put it into the backlog, at which point it can be pulled into development whenever a new dev phase starts (in Agile, this is at the beginning of a "sprint", which is usually 2 weeks).
• Sprint phase
  1. Team lead reviews the ticket with the devs, gives an estimate, assigns the ticket, and effectively pulls it into the sprint (meaning it will be worked on this sprint).
  2. At this time, the ticket may be cleaned up a little to more accurately reflect the issue.
  3. Developer documents work and issues until the problem is fixed.
  4. Developer refactors code so that it's clean and in line with the philosophy of the product.
  5. Developer attempts to confirm that the issue is fixed. Updates the test case as necessary (including any exclusions for things that QA should not fail the ticket for - usually due to it being addressed in a separate ticket). Pushes code into review (this effectively closes the ticket as In Review and pushes the code into a team repository).
• QA phase
  1. Team lead and/or tech lead reviews the fix. Pushes the code into the global repository. Pushes it into QA (this effectively re-opens the ticket as Begin QA).
  2. QA tests the parts of the product relating to the ticket on their own, clean environment. This is outlined in the test case. Ultimately, the test case needs to pass for the ticket to pass. If the test case fails, the fix fails. If the test case passes, QA should also do a basic regression test, or a more thorough regression test for fixes that affect many aspects of the product - for fixes that it is unclear what they affect, it would generally warrant a Full regression test. If anything seems wonky, especially if any of the steps leading up to the test case cannot be followed, QA will fail the ticket. Failed tickets go back to dev (who may decide to exclude the reason of failure and/or clarify the test case, and push it back into QA. Alternatively, they may fix the regression and push it back into review).
  3. QA phase 2 repeats the QA process in a production environment. This step may be skipped if a "production environment" is the same as a development environment.
  4. QA passes the fix, formally closes the ticket as resolved.

Note that, as a small team, we do not have the resources to follow this formal procedure. We do not have nearly enough people to fill all the roles, and even if we did, the people we have are all volunteers, meaning they are under no obligation to fulfill their role, let alone to fulfill it in a reasonable time frame. Because of this, much of this process is expidited as much as possible, compressing several steps, and creating informal processes for these. Whatever the case, this formal procedure forms a guideline in what the procedure for a ticket *should* be, so that our informal processes may reflect this as best is possible with the resources we have.

Do realize that tickets and bugs do still fall through the cracks. To best expedite a ticket, we ask that reporters stick around and check up on the ticket throughout the life of the ticket, helping in whatever way they can. The reporter is also capable of closing their own tickets, should they feel they are invalid or resolved before the usual ticket process completes - that's perfectly fine. However, you are not required to close your tickets - they will follow their usual lifecycle and get closed off eventually anyways (hopefully by QA).