Ticket_procedure modified by Hugh Greene

Hugh Greene — Fri, 20 Jan 2023 12:23:58 -0000

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).

Recent changes to Ticket_procedure

Ticket_procedure modified by Hugh Greene