Changes between Version 1 and Version 2 of TicketTestsLifeCycle

Timestamp:

Aug 18, 2011, 2:15:49 PM (13 years ago)

Author:

Anna Tomanek

Comment:

Proof-reading of the page

TicketTestsLifeCycle

@@ -1 +1 @@
 = Bug Ticket Handling Workflow and Tests =
 
-We use git to handle our tests repository. This gives use great flexibility when dealing with tests creation and quality assurance. This page exposes the way we work with it when dealing with our bug tickets.
+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. In the other hand, we have several ticket branches that FAIL because of the new unstable tests added to them. Checkout [wiki:CKEditor-Tests.git] for more information on how to work on our tests repository.
+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 [wiki:CKEditor-Tests.git] for more information on how to work with our tests repository.
 
-The following is a simplified description for our ticket handling workflow:
+The following is a simplified description of our ticket handling workflow:
 
- 1. A new bug ticket is created. (Status "new").
+ 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:
-  a. The issue can be reproduced. (Status "confirmed"). Go to step 4.
-  b. Other resolutions: "pending", "invalid", "duplicate", "wontfix" and "worksforme". Stop here. Feedback may be provided by the reporter later.
+  a. The issue can be reproduced. (Status {{{confirmed}}}). Proceed to step 4.
+  b. Other resolutions: {{{pending}}}, {{{invalid}}}, {{{duplicate}}}, {{{wontfix}}}, and {{{worksforme}}}. Stop here. Feedback may be provided by the reporter later.
  4. Ticket Tests created:
-  a. A dedicated test branch is created for the ticket. All added and changed tests will end-up on that branch. The branch name pattern is "t/<Ticket Number>".
+  a. 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>}}}.
   b. 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).
-  c. It may not be possible to create automated tests for this tickets. In that case, a manual test is required.
-  d. All test additions and changes must be documented with a ticket comment pointing to the hpp://ckeditor.t/ URL relative to the tests.
+  c. It may happen that it is not possible to create automated tests for some tickets. In that case a manual test is required.
+  d. All test additions and changes must be documented with a ticket comment pointing to the http://ckeditor.t/ URL relative to the tests.
   e. All new tests must FAIL at this stage.
- 5. Analysis phase. (Status "accepted")
-  a. New tests could come out on this phase, either ticket tests or design tests. All of them must end-up at the ticket test branch.
+ 5. Analysis phase. (Status {{{accepted}}})
+  a. 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:
   a. All new tests must PASS with it.
-  b. Status: "review".
+  b. Status: {{{review}}}.
  7. Review is performed. 
   a. After applying the patch:
@@ -28 +28 @@
    ii. Check whether new manual tests pass.
    iii. Check whether the new tests are correct for that ticket.
-   iv. Check the patch code, to accept the proposed changes, API changes/additions, coding style, performance impact, etc.
-  b. The reviewer is free to make changes to the proposed tests and add new tests as the result of the review, documenting it on comments. This helps also on justifying failed reviews.
+   iv. Check the patch code to accept the proposed changes, API changes/additions, coding style, performance impact, etc.
+  b. 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.
   c. Review PASSED. Go to step 8.
   d. Review FAILED. Back to step 4 or 5.