Changes between Initial Version and Version 1 of TicketTestsLifeCycle


Ignore:
Timestamp:
Aug 18, 2011, 1:27:57 PM (8 years ago)
Author:
Frederico Caldeira Knabben
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • TicketTestsLifeCycle

    v1 v1  
     1= Bug Ticket Handling Workflow and Tests =
     2
     3We 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.
     4
     5The 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.
     6
     7The following is a simplified description for our ticket handling workflow:
     8
     9 1. A new bug ticket is created. (Status "new").
     10 2. Ticket cleanup is performed (title, description, fields, etc.). This may happen together with step 3.
     11 3. Ticket confirmation:
     12  a. The issue can be reproduced. (Status "confirmed"). Go to step 4.
     13  b. Other resolutions: "pending", "invalid", "duplicate", "wontfix" and "worksforme". Stop here. Feedback may be provided by the reporter later.
     14 4. Ticket Tests created:
     15  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>".
     16  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).
     17  c. It may not be possible to create automated tests for this tickets. In that case, a manual test is required.
     18  d. All test additions and changes must be documented with a ticket comment pointing to the hpp://ckeditor.t/ URL relative to the tests.
     19  e. All new tests must FAIL at this stage.
     20 5. Analysis phase. (Status "accepted")
     21  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.
     22 6. A patch is provided:
     23  a. All new tests must PASS with it.
     24  b. Status: "review".
     25 7. Review is performed.
     26  a. After applying the patch:
     27   i. Check whether all automated tests pass (including new ones). This is run on the ticket test branch.
     28   ii. Check whether new manual tests pass.
     29   iii. Check whether the new tests are correct for that ticket.
     30   iv. Check the patch code, to accept the proposed changes, API changes/additions, coding style, performance impact, etc.
     31  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.
     32  c. Review PASSED. Go to step 8.
     33  d. Review FAILED. Back to step 4 or 5.
     34 8. Commit:
     35  a. Commit the patch into the SVN.
     36  b. Merge the ticket test branch on master.
     37  c. Delete the ticket test branch.
     38 9. Close the ticket.
     39 
© 2003 – 2019 CKSource – Frederico Knabben. All rights reserved. | Terms of use | Privacy policy