On Tue, 2012-07-31 at 10:40 -0700, Adam Williamson wrote: Forgot to mention - please consider the Test Day SOP to be guidelines, not hard and fast rules - if you think of a way to adjust the process which you think would be beneficial for your Test Day, by all means go ahead and do it, no-one will be angry! So if you can think of any methods that you think might improve the ease of the feedback process, please do go ahead and try them for the f18 PM test day, and let us know how they go. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net

On Tue, 2012-07-31 at 14:14 -0500, Michael Cronenworth wrote: I didn't really cover the problem space very well, sorry for that. It's one of those things that gets bigger each time you look at it. In traditional 'big grown-up QA' terms, what we're doing is using the Wiki as a TCMS - test case management system. Real big grown-up QA tends to base a lot of work around these, which are pretty complex projects that aim to handle both the creation and management of test cases, and tracking test results. Test Days are really just one application, is the thing - at least looking at things from the traditional perspective, it wouldn't make a lot of sense to write a small, Test Day-specific client/server system, because really Test Days are just events where we get lots of people together to iterate intensively over a specific set of test cases. In theory the test cases aren't 'special' - they can be run in other contexts besides Test Days, which might want different things from the results. TCMSes tend to wind up as big sophisticated beasts which can track results in lots of different ways. TCMSes unfortunately tend to be built with an assumption that they'll be used by a small group of trusted and relatively savvy users: they'll be used by a dedicated QA team in a 'closed' environment, essentially. So they don't go out of their way to be easy to use and often aren't architected in a way which would make them particularly easy to deploy in an environment like Fedora, where we want to be open to engagement by very casual testers and people who aren't necessarily trusted and experienced QA members. There are several open source TCMSes and similar systems that we could, in theory, use for Fedora QA; we've evaluated several of them in the past. The 'obvious' candidate for Fedora is Nitrate, which is Red Hat's TCMS - https://fedoraproject.org/wiki/Nitrate . Red Hat QE, which is a much more grown-up and 'proper' effort than Fedora QA (but also basically a closed shop within RH), bases all its work around Nitrate. Even Nitrate, though, has quite a lot of disadvantages compared to the Wiki when it comes to the unique context of Fedora testing - https://fedoraproject.org/wiki/Tcms_Comparison is an evaluation of nitrate against the various features of 'wiki as a TCMS' which we've found useful or which have become integrated into the way in which we do testing for Fedora. Other open source TCMSes all have similar issues, or more, in the context of Fedora QA. None of them would be a straightforward drop-in replacement for the way we currently order things, with clear advantages and only a few drawbacks - they'd all represent a significant trade-off in capability and would take a lot of engineering work and re-design of our processes. This doesn't mean we shouldn't do it, of course, but it's not a straightforward call. There are, of course, always other ways of looking at things. You could take the point of view that a lot of successful open source code resulted from someone starting out by doing something small in a simplistic, unsophisticated way, and building from there. Perhaps the fact that we've never found a drop-in TCMS that entirely makes sense for Fedora is an indication that we really ought to grow our own, and making a simple limited system specifically for Test Days, or some other specific use Fedora makes of test cases, wouldn't be such a bad way to start out: I'm certainly sympathetic to the view that sometimes it works out better to do a good job on a small task in a relatively short time with concrete results than to look at everything Fedora QA would ultimately want from a TCMS and try to knock it all off on the first try. So that's a very longwinded way of saying - 'yes, with reservations' :). I could certainly see value in an effort to write a relatively simple system for handling test cases and results for Fedora test days, tailored to the somewhat unusual requirements of collaborative testing for an open project like Fedora. But I think if anyone's going to do it, they should do it with all of the above in mind - bear in mind that they're not exactly breaking new ground, but approaching a relatively mature field from a slightly unique angle. Be aware that, ultimately, what we really want is a more complex and flexible system around which we could base all of Fedora's QA efforts; something that can _only_ ever work for the Test Day format would be a bit of a dead end. Hope that made sense and made things a bit clearer :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net

On 07/31/2012 01:30 PM, Jaroslav Skarvada wrote: At the time we looked at various testing system but all of them fell short one way or another thus we decide to settle on something reporters where familiar with as an short stop until we found or came up with something better and we had couple of ideas how that should look like which well let's say was quite different from the traditional tcms. In any case this discussion and how it can be improved belongs on the -test list where the QA community resides... JBG

On Tue, 31 Jul 2012 15:35:35 -0500 Michael Cronenworth <mike(a)cchtml.com&gt; wrote: [ cc'ing test@ since this is relevant to QA ] I'm going to avoid Adam's discussion of TCMSs for the moment since any solution like that would be a large undertaking and a little different from the original issue raised with our current system(s). As a short term solution, I think that we write up a webapp that took in results and dumped to a wiki page either at regular intervals or at the end of the test day without too much effort. That way we could at least get around the problem of conflicting wiki writes without coming up with a completely new system. Assuming we did a decent job writing the app, it could also make result reporting less confusing to people who aren't familiar with the test day process. I'm still unsure of the immediate need for more than what we already have. I realize that the PM test day caused problems - this isn't the first time that the issues from that test day have come up. However, I'm not currently aware of any other test days that had similar issues of write conflicts and confusion. Have enough other test days hit similar problems to make it worth the effort to write, maintain, host and support anything beyond what we currently have? Has anyone else run into similar issues when running a test day? How much need is there for something more than what the wiki can currently provide? Tim