Cheatography
https://cheatography.com
A sheet describing how we use Rally to manage our development pipeline
Rally Schedule statesIdea | (I) Provisional User Story or Defect, requires design work | Defined | (D) User Story or Defect has either been designed or is a simple story | In Progress | (P) Once work has been started by a developer | Complete | (C) Work has been completed by a developer including code reviews and updated documentation | Accepted | (A) Work has been signed off by the testing team. |
How to Complete a User StoryReview User Story and Acceptance Criteria | Document design in the ADD document | Take the Task within Rally, and check that you agree with the time estimate | Write Unit & component tests to confirm the behaviour of the first part of the first task | Write code to pass the tests you have already written | Review tests and make sure they are correct | Update todo estimate if sensible | Iterate previous 3 steps till task is complete | Refactor code to ensure it high enough quality. | Update actual time spent on task | Iterate previous steps for tasks until User story is complete | Do a final refactor step to ensure code is well designed etc. | Review ADD & update if required | Review SMG & update if required - mark the checkbox stating that documentation is uptodate. | Ask someone to code review work. | Action all MoSCoW items as required and give back to reviewer to do the merge | Mark task as complete | Testing team will test and Review and reopen if required or mark as Accepted |
| | Checklist for a Code ReviewCheck code runs | Does design match documented design | Can you break by changing test values etc | High level review to ensure methods aren't too long | High level review to ensure classes are named properly | High level review to check its clear what the code does | Check test coverage | Check tests are in the correct area of code and seem sensible | Check naming of methods and variables | Check no libraries are in use unless agreed | Check abstraction is required | Check naming conventions |
The code should be branched and all comments committed in the relevant part of code, and then committed back to Github. Each change should be classified by:
(M) Must Change
(S) Should Change
(C) Could Change
(W) Won't address Raising a defectEnter a description of how to reproduce it | Enter the Git Commit Hash it was found in | Set the severity and priority (ask Marryat if unsure) | Check if it should be scheduled for this iteration. | Ideally link it to a Test Case | Ideally link it to a User Story |
Fixing a defectGit commit messages should include the DE### so it links in Rally | Enter the Git Hash that fixes the defect in the Fixed in Field | Enter any notes that are relevant | Set the Defect State to Fixed | Set the Scheduled State to Complete | Set the Resolution |
Verifying a DefectEnter the Git commit hash that you are verifying the fix in | Change the Defect Status to Closed | Change the Scheduled State to Accepted | Add in any notes that are relevant | Re-run the test case and record the result if present/relevant |
|
Created By
Metadata
Comments
No comments yet. Add yours below!
Add a Comment
Related Cheat Sheets
More Cheat Sheets by Marryat