After trying Rafal's suggestion of creating TEST tickets, I still think I'd like to add new JIRA workflow state.
What would people think of the following new state: Needs Verification and Documentation - with the following transitions: Rework Needed (Assign issue) -> In Progress Verify and Close (No screen) -> Closed Cancel Issue (Close issue with reason and fixVersion) -> Closed Then add a new transition to the Approved state: Request Verification (No screen) -> Needs Verification and Documentation And the same new transition to the Code Review (Post-Commit) Request Verification (No screen) -> Needs Verification and Documentation The man use case is that the ticket is in Committed Code state, and the code has been reviewed and approved, but the project administrator would like further verification and documentation. Therefore, instead of choosing "Approve & Close" the admin would choose "Request Verification". The admin would add a comment as to who is responsible for verification (instead of changing the assignee). Typical people asked to do verification would be: 1) a QA resource, 2) the reporter, 3) the assignee. Thoughts? Mark From: [email protected] [mailto:[email protected]] On Behalf Of Michael Seaton Sent: Friday, February 03, 2012 3:11 PM To: [email protected] Subject: Re: [OPENMRS-DEV] JIRA: Awaiting Testing Verification state? It's actually been my experience that our code review process is often so focused on the actual code, it doesn't always focus as much on whether the developed product (UI features, etc) works right or meets all of the initial specifications. Separating the process into code review (typically "the code looks good, the design is good, you have unit tests, you follow the right patterns", etc) and functional testing/approval might explicitly ensure that these steps are always being followed better. On 02/03/2012 02:51 PM, Darius Jazayeri wrote: Mark's point is that sometimes there's a separate QA/QC team (in the case of this sprint, it's an awesome PIH volunteer named Cordt). That's an extra, higher level of testing than what happens during our regular ticket workflow. And since we don't have a QA/QC team for OpenMRS generally, we obviously haven't modeled the "to-be-tested-by-QA-QC. Another option would be to approve the ticket and add a label for "needs-QA". Once that QA has happened, then remove the label and possibly reopen the ticket, or create a new ticket. -Darius On Fri, Feb 3, 2012 at 11:29 AM, Michael Downey <[email protected]<mailto:[email protected]>> wrote: Shouldn't a post-commit code review also be ensuring the code change actually fixed the problem? Michael _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [email protected]<mailto:[email protected]> with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:[email protected]<mailto:[email protected]>?body=SIGNOFF%20openmrs-devel-l] ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
