Bug Ticket Handling Workflow and Tests

We use Git to handle our tests repository. This gives use great flexibility when dealing with test creation and quality assurance. This page describes the way we work with Git when dealing with our bug tickets.

The basic idea is that our "master" branch must remain stable, with all tests PASSing. On the other hand we have several ticket branches that FAIL because of the new unstable tests added to them. See CKEditor-Tests.git? for more information on how to work with our tests repository.

The following is a simplified description of our ticket handling workflow:

1. A new bug ticket is created. (Status new).
2. Ticket cleanup is performed (title, description, fields, etc.). This may happen together with step 3.
3. Ticket confirmation:
   1. The issue can be reproduced. (Status confirmed). Proceed to step 4.
   2. Other resolutions: pending, invalid, duplicate, wontfix, and worksforme. Stop here. Feedback may be provided by the reporter later.
4. Ticket Tests created:
   1. A dedicated test branch is created for the ticket. All added and changed tests will end up in that branch. The branch name pattern is t/<Ticket Number>.
   2. Ticket tests must reflect the exact steps to reproduce the ticket issue, not tests for the root of the problem. Design tests may be created on very rare cases (usually when reporting API issues).
   3. It may happen that it is not possible to create automated tests for some tickets. In that case a manual test is required.
   4. All test additions and changes must be documented with a ticket comment pointing to the ​http://ckeditor.t/ URL relative to the tests.
   5. All new tests must FAIL at this stage.
5. Analysis phase. (Status accepted)
   1. New tests could appear in this phase -- either ticket tests or design tests. All of them must end up in the ticket test branch.
6. A patch is provided:
   1. All new tests must PASS with it.
   2. Status: review.
7. Review is performed.
   1. After applying the patch:
      1. Check whether all automated tests pass (including new ones). This is run on the ticket test branch.
      2. Check whether new manual tests pass.
      3. Check whether the new tests are correct for that ticket.
      4. Check the patch code to accept the proposed changes, API changes/additions, coding style, performance impact, etc.
   2. The reviewer is free to make changes to the proposed tests and add new tests as the result of the review, documenting it in the comments. This helps also in justifying failed reviews.
   3. Review PASSED. Go to step 8.
   4. Review FAILED. Back to step 4 or 5.
8. Merge:
   1. Merge the test and patch branches to master or major branches of their respective repositories.
   2. Delete the test and patch branches.
9. Close the ticket.