Vincent Massol wrote: > On Dec 6, 2007, at 5:22 PM, Ludovic Dubost wrote: > >> I'm for a +1 on this one . This would allow to introduce testers in >> our >> process. >> I understand this is difficult for the platform but this would be >> easier >> for the products. > > 2 points: > > 1) I'd prefer a new state rather than Resolved. Something like > "Tested" or "Externally Tested" or "Verified by Tester" or whatever
Even better. I agree with you that forcing each issue to be tested is not a good idea (it would be in an ideal world), so the best we can do is have an optional state or a boolean property of an issue which signals the fact that there are tests written for that feature. Anyway, I still think that we should have something for this, as I don't like having documentation issues like XWIKI-1867. We could have filters for "My undocumented closed tasks", "Undocumented tasks for the current release", "Undocumented closed tasks". > 2) We'll need to write issues from a user point of view (which I've > always wanted) and not from an internal point of view. This means that > for each issue fixed technically we need to find a user use case that > was failing because of it and use that as the description rather than > a technical description. Otherwise an external tester won't be able to > test it. > > anyway let's wait for a tester to come on board first... > > -Vincent > >> Maybe we can leave the decision on the project head for each of our >> projects. >> >> Ludovic >> >> Vincent Massol wrote: >>> On Dec 5, 2007, at 3:13 PM, Vincent Massol wrote: >>> >>> >>>> I don't like it. >>>> >>>> The developer is reponsible for testing what he commits. Period. >>>> Anything that implies otherwise should be banned IMO. >>>> >>> Just to qualify my answer a bit ;) >>> >>> It can work but only when there's a very rigid process with one >>> person >>> working full time to manage it. Unfortunately we don't have that >>> person yet. Maybe in the future we'll be able to get someone to do >>> functional tests for us. When this happens we could possibly add a >>> new >>> state for whether the issue has been validated by an external tester >>> or not. But even when that happens every developer still needs to >>> ensure that: >>> 1) he's fully tested it (with automated tests as much as possible) >>> 2) written documentation for it >>> >>> -Vincent >>> >>> >>>> On Dec 5, 2007, at 2:54 PM, Sergiu Dumitriu wrote: >>>> >>>> >>>>> No replies yet... >>>>> >>>>> On Oct 11, 2007 5:33 PM, Sergiu Dumitriu >>>>> <[EMAIL PROTECTED]> >>>>> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> We should reintroduce the Resolved state in the issue workflow, >>>>>> and >>>>>> it >>>>>> should work like this: >>>>>> >>>>>> - When closing an issue, it will go in the Resolved state, which >>>>>> means >>>>>> that somebody provided a fix and it is committed in the >>>>>> repository. >>>>>> - Somebody else can test (manually) that the issue is indeed >>>>>> fixed/implemented, and it works as expected. If no, then it goes >>>>>> back >>>>>> to Open, otherwise it goes to Verified. >>>>>> - When all the needed tests and documentation are written, the >>>>>> issue >>>>>> can be closed completely, entering the Closed state. >>>>>> >>>>>> This should improve the way we write code, meaning that we don't >>>>>> just >>>>>> commit some quick fix code which nobody sees, and claim that the >>>>>> issue >>>>>> is fixed. Right now we're trying to do peer reviewing either by >>>>>> first >>>>>> attaching patches to the issue and have somebody review it, or by >>>>>> hoping that someone is reading the commit mails and notices if >>>>>> something is wrong. We should never make a release that has issues >>>>>> in >>>>>> the Resolved state, as it has unverified code, probably with >>>>>> missing >>>>>> documentation and proper tests. We should reserve a few days >>>>>> before >>>>>> each release for moving any Resolved issue to the Closed state, by >>>>>> verifying, testing and documenting it. >>>>>> >>>>>> Verifying issues can be done by outsiders, too, so we could >>>>>> involve >>>>>> the community more. Perhaps it would be a good idea to require two >>>>>> verifiers before moving the issue to verified, as testing on >>>>>> different >>>>>> systems can spot some bugs, like the full screen editor not >>>>>> working >>>>>> in >>>>>> Safari issue. _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
