Right now we don't have a way of indicating if an issue has been tested or
not. As a workaround we accorded that every issue in the "resolved" status
is not tested yet, and those that are "closed" are. This is far from being
ideal. So I would like to ask you for your opinion and ideas on this topic.

One option that has been around for a long time is to introduce a new
status called "tested", between "resolved" and "closed". This has a
fundamental problem, though: why is the "tested" status after "resolved"
and not after? One would think that you cannot claim to fix an issue if
it's not tested. It might be a terminology difference only, but it says
a lot about us.

So the other option as a consequence of this is to have a new status
between "scheduled" and "resolved", called "Ready for testing".

But now we have the Continuous Integration factor as well. So need to
differentiate between "CI testing" and "Manual testing/verification/review".

So this is one possible workflow:

* New
* Feedback
* Acknowledged
* Scheduled
* Ready for testing
* Ready for review
* Resolved
* Closed

These are the actions that would trigger status changes:

* A Mercurial commit moves an issue from "Scheduled" to "Ready for testing".
* The CI moves an issue from "Ready for testing" to "Ready for review".
* The reviewers (right now QA) move the issues from "Ready for review" to
  "Resolved".
* And when a release is out we move the "Resolved" issues to "Closed".


Comments? Your ideas?

Juan Pablo


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Openbravo-development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openbravo-development

Reply via email to