On Thu, 2012-08-09 at 05:49 -0400, Kamil Paral wrote:
> > Hey, folks. So, as per https://fedorahosted.org/fedora-qa/ticket/307
> > , I
> > think we need to add a process for validating the multi-live and
> > multi-install images that we've been building for the last few
> > releases.
> 
> It is ironic that before F17 release I have talked about this to cwickert 
> (IIRC) and he assured me no QA help is needed and that nothing can go wrong. 
> When they build the image, they just ensure everything boots and that's it. 
> There's just a small syslinux glue, nothing else is changed. Well, it didn't 
> go according to the plan, apparently.
> 
> > I've put together a draft matrix template for this validation here:
> > 
> > https://fedoraproject.org/wiki/User:Adamwill/Draft_QA_Compendium_image_validation_results_template
> > 
> > It's similar to the other validation matrices, and the changes are
> > mostly obvious. The key bit is the layout of the matrix and the test
> > cases themselves. I haven't actually written any of the specific test
> > cases yet, but I tried to think of the best way to organize things.
> > We
> > obviously need to do the basic sanity tests on each image, then we
> > need
> > to test that each image boots and the menu that lets you select which
> > sub-image to boot works properly, and also that each sub-image boots
> > and
> > installs properly. I think that set of tests ought to pretty much
> > cover
> > the intended functionality of the compendium images. When actually
> > writing the test cases, we might be able to come up with ways to take
> > advantage of some of the existing install/base/desktop validation
> > test
> > cases, but I haven't quite thought that far ahead yet.
> > 
> > I tried to organize the planned test cases as efficiently as
> > possible;
> > this is the best layout I could come up with, but someone might be
> > able
> > to suggest improvements. In case it's not obvious, here's roughly
> > what
> > each test case does:
> > 
> > QA:Testcase Mediakit_ISO_Size and QA:Testcase_Mediakit_ISO_Checksums
> > -
> > these test cases already exist and can apply without modification to
> > the
> > compendium images, they simply check that they're within required
> > size
> > limits (dual-layer DVD size for these images) and the published
> > checksums match the images.
> > 
> > QA:Testcase_multilive_boot and QA:Testcase_multidvd_boot - these will
> > simply check that the compendium images themselves boot
> 
> I don't understand what this means.
> 
> To clarify, multidvd structure is this:
> -> default DVD boot (auto-selects architecture)
> -> select arch manually -> i386
>                         -> x86_64
> -> basic video -> both 2 options
> -> memory test
> -> local drive boot
> 
> So you probably mean the "default DVD boot" here, right? But which 
> architecture? The result might differ on i386 and on x86_64 machine.
> 
> But multilive structure is this:
> -> default Live GNOME (auto-selects architecture)
> -> default Live KDE (auto-selects architecture)
> -> default Live LXDE (auto-selects architecture)
> -> default Live SoaS (auto-selects architecture)
> -> default Live XFCE (auto-selects architecture)
> -> select arch manually -> i386 -> Live GNOME
>                                 -> Live KDE
>                                 -> Live LXDE
>                                 -> Live SoaS
>                                 -> Live XFCE
>                         -> x86_64 -> Live GNOME
>                                   -> Live KDE
>                                   -> Live LXDE
>                                   -> Live SoaS
>                                   -> Live XFCE
> -> basic video -> all 10 options here
> -> memory test
> -> local drive boot
> 
> What does the test refer to for multilive?

> I have to say I'm somewhat confused from the current matrices structure. But 
> maybe when the test cases are written it'll clearer.
> 
> My idea personally was:
> 
> MultiLive matrix                | GNOME | KDE | LXDE | SoaS | XFCE
> ------------------------------------------------------------------
> multilive_auto_boot (i386)      |
> multilive_auto_boot (x86_64)    |
> multilive_manual_boot (i386)    |
> multilive_manual_boot (x86_64)  |
> multilive_install (anyarch)     |
> 
> "auto_boot" is when you select the default option and correct architecture is 
> chosen for you. To test this properly, you need both i386 and x86_64 machines 
> (or VMs, if accepted).
> "manual_boot" is when you select the architecture manually from the submenu. 
> A single x86_64 machine is sufficient to check both cases.
> 
> MultiDVD matrix                | result
> ---------------------------------------
> multidvd_auto_boot (i386)      |
> multidvd_auto_boot (x86_64)    |
> multidvd_manual_boot (i386)    |
> multidvd_manual_boot (x86_64)  |
> multidvd_install (anyarch)     |
> 
> I am wondering whether we need installation tests at all. Theoretically the 
> ISOs are unchanged so there should be no difference at all. If they start to 
> boot, it should be fine. But according to Murphy's Law...

OK, I revised the middle table somewhat, I tried to figure it out myself
but it turns out fairly similar to yours:

https://fedoraproject.org/wiki/User:Adamwill/Draft_QA_Compendium_image_validation_results_template#Boot_and_sub-image_selection

so 'multi_auto' would just be 'leave it, and check it does the right
thing', 'multi_manual' would be a test case that's something like 'try
every entry besides basic video / memtest / local boot and make sure
they respond appropriately', and the other three are obvious - we
probably don't really need to do those three on both arches, we could
split out a small table for those, I guess.

The multi_sub_boot test now becomes redundant, and I suppose we could
move sub_install up into this new big table; we can probably get away
without testing install of every DE, since they all use anaconda. The
case I can see where install might break on the compendium images is the
case where anaconda, for whatever reason, examines the actual medium
it's booting from. It _does_ do this, in some cases - like it tries to
except the USB stick it's booting from (if it is) from the target device
list. (This test may well not work on the compendium images, actually).
I can possibly imagine a case where anaconda goes to look what image
it's booting from, and gets confused if it's the compendium disc. But
that shouldn't vary between desktops.

This is a pretty tricky problem space and I'm not at all confident I'm
wrapping my head around it perfectly, more comments and improvements of
course welcome =) Thanks!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Reply via email to