On Tue, 2014-11-25 at 06:46 -0500, Kamil Paral wrote: > > Eh, it's OK, just seems slightly inconsistent to be specifying > > environment 'horizontally' for some tests and 'vertically' for others. > > Why not just another table with the two tests that use the GUI/text > > distinction and those as the columns? > > Hmm, I guess there were two reasons: > 1. I didn't actually consider text vs gui to be environments, it > seemed similar to me as with Testcase_install_repository_NFS_graphical > and Testcase_install_repository_NFS_variation. The difference was that > I didn't want to create two separate test cases when the steps are > almost exactly the same, so I tweaked the description slightly to > accommodate for both approaches and then differentiated it just in the > test case title in the table. You can also see this approach in the > Desktop matrix with the Testcase_desktop_updates (installation) and > Testcase_desktop_updates (notification) test cases. So for me any time the test case is the same, any different 'configuration' in which you run it is an environment. As you say the difference with the install_repository tests is that the actual test steps are different in that case, it really is a different test case. OK, it's slightly slippery as we're also in control of how we express the test cases, but hey. It's no big deal, really. In the Desktop matrix we're effectively using the 'two-dimensional' hack (that was in fact where I got the idea for the 'two-dimensional' tables) - we need results for all combinations of two sets of environments (desktop environment is one 'environment', installation vs. notification is the other). We can't express it all in the table columns without having twice as many columns, which is just ugly. But we don't have that issue in the bit we're discussing here, as it has no column 'environments'. > 2. When I did the above, I probably still had some architectures as > environments. So I needed to do it like this, otherwise I would have a > table with three dimensions, which is a bit hard to create :) Aha, right. > So now, yeah, we can definitely move gui and text to be columns, as > environment. But we will need to create yet another table (just for > those two test cases), which I wanted to avoid (multiple rows are > probably a bit easier to read when in the source view than multiple > tables and/or columns). But either way is fine with me. Like I said I don't really care about it thaat strongly either. Maybe just leave it for now and it's something we can fiddle next time we want to feel like we're doing something useful! > We can also consider to remove those "text" test cases, because I have > in fact added them myself, without any discussion, it just seemed > right to me. Before my change, we tested it on x86 and ARM, which kind > of implied gui and text, but not necessarily. It seemed logical to > remove those architectures and replace it with their real difference, > which is gui and text. But maybe people might not see their importance > high enough to justify this separation. No, I think it makes sense. If anything we should be testing text install *more*, but it's just one more multiplying factor in the test set :/ > > > > With a very neat-freak hat on, I'd probably have put the table with just > > one column either at the top or bottom, not in the middle - just flows a > > bit odd visually for me. But that's very small beans. > > I tried to sort that according to milestone priority, so that tables > containing Alpha test cases are above tables containing Beta+ test > cases. No objections to change it. Oh, I see. That makes sense, sure. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
