Unfuddle usage guide 2
Download as PPTX, PDF0 likes315 views
The document provides a workflow for developers and QA to follow when working on tickets in Unfuddle. The workflow involves developers estimating tickets, updating statuses, writing tests and code, and resolving tickets once development is complete. QA then tests resolved tickets, failing them back to developers if issues are found or passing them to customers if testing is successful.
![• 5. Dev is recommended to write Nunit/Junit
scripts for the ticket
• 6. When checking in the code, please write
log message as this format: #[TicketNo]. This
will auto-associated with the specific ticket,
otherwise we need add “Associated
Changesets “manually.](https://image.slidesharecdn.com/unfuddleusageguide2-121114133912-phpapp01/85/Unfuddle-usage-guide-2-5-320.jpg)
![• 7. Once the ticket was completed and passed
developer’s own testing, please marked it as
Resolved and assigned to corresponding QA.
• 8. If the ticket is for bug fixing, developers
please write down the comments, including
“[What’s the problem]”, “[What is the root
cause]”, “[What is the solution]” and “[Any
related test points]”.](https://image.slidesharecdn.com/unfuddleusageguide2-121114133912-phpapp01/85/Unfuddle-usage-guide-2-6-320.jpg)
Unfuddle usage guide 2
- 2. When one ticket is assigned to you, please following this workflow: 1. Check if there is any requirement/ technical related question/concern there. if there is, please add comments and re-assign it to proper person ASAP.
- 3. 2. If there is no question, please give your estimation. (Dev/PL does this). Each ticket should be less than 24hours, otherwise please break it down to smaller tickets 3. When starting coding on this ticket, Dev please update status as “Accepted”. QA start creating test cases for new features.
- 4. • 4. Developers log time spending on the ticket under Time Tracking part by the end of each day
- 5. • 5. Dev is recommended to write Nunit/Junit scripts for the ticket • 6. When checking in the code, please write log message as this format: #[TicketNo]. This will auto-associated with the specific ticket, otherwise we need add “Associated Changesets “manually.
- 6. • 7. Once the ticket was completed and passed developer’s own testing, please marked it as Resolved and assigned to corresponding QA. • 8. If the ticket is for bug fixing, developers please write down the comments, including “[What’s the problem]”, “[What is the root cause]”, “[What is the solution]” and “[Any related test points]”.
- 7. • 9. If there is any database change, including schema or storage procedure update, Developers please write down any comment to record the name of PL sql and schema.
- 8. • 10. When QA testing, please add proper steps , actual result and with passed/failed comments. (Attaching snapshot if possible.) Please note the ticket is still in “Resolved” status but under QA’s name If the test steps are the same exact steps that are used elsewhere in the ticket just reference those steps. For example: Built to Beta. I used the test steps in the ticket description to test.
- 9. • 11a. When a ticket failed testing, please reassign back to developer with detailed steps how to reproduce it. • 11b. When a ticket passes QA’s testing, please reassign to customer properly