I also approve of this idea. It covers both the case where you have a dedicated tester, and the not-uncommon case where we ask the reporter to verify that things were fixed to satisfaction.
-Darius On Wed, Feb 8, 2012 at 10:51 AM, Dave Thomas <[email protected]> wrote: > +a million for > > Needs Verification and Documentation > > Having something built into the ticket workflows where developers have to > explicitly think to themselves 'I'm not going to document this', seems like > it might encourage better behaviour. > > (I'm as guilty as anyone) > > d > > > On Wed, Feb 8, 2012 at 8:33 AM, Mark Goodrich <[email protected]> wrote: > >> 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]> >> 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] with "SIGNOFF openmrs-devel-l" in the body >> (not the subject) of your e-mail. >> >> [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]**** >> >> ** ** >> ------------------------------ >> >> Click here to >> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >> OpenMRS Developers' mailing list >> **** >> ------------------------------ >> >> Click here to >> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >> OpenMRS Developers' mailing list >> **** >> ------------------------------ >> Click here to >> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >> OpenMRS Developers' mailing list > > > ------------------------------ > Click here to > unsubscribe<[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]
