[Fedora QA] #263: Expand Xen test case set
by fedora-badges
#263: Expand Xen test case set
----------------------+-----------------------------------------------------
Reporter: adamwill | Owner:
Type: task | Status: new
Priority: major | Milestone: Fedora 17
Component: Wiki | Version:
Keywords: |
----------------------+-----------------------------------------------------
After checking with the Xen experts on list, it became clear that it would
be a good idea to somewhat improve and extend our set of Xen test cases:
https://lists.fedoraproject.org/pipermail/test/2011-November/104654.html
Konrad Wilk summarizes:
"It would be nice to expand the tests, and it kind of boils down to:
1) Does it boot
2) Does it work
The complexity is that there are three modes of this: HVM (so similar to
the KVM test-case), PV (we got that covered now), and the Dom0 (which is
mostly - does it boot and you kind of implicitly need to do this before
you can do the other two).
So I think it makes sense to add the HVM case in the test-matrix - it is
pretty simple and similar to the KVM one.
The dom0 is a bit more complex, but we already have it outlined in the
http://fedoraproject.org/wiki/Features/XenPvopsDom0 in the Documentation
part - so it should be fairly easy to lift it out of there. (adn the stuff
about the bridge is not needed anymore)."
If someone with knowledge of the area could take this ticket and draft up
the set of proposed test cases then mail them to the list for discussion,
that would be great. Thanks!
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/263>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
11 years, 10 months
[Fedora QA] #82: Update existing dual-boot tests and add to test plan
by fedora-badges
#82: Update existing dual-boot tests and add to test plan
---------------------------+------------------------------------------------
Reporter: jlaska | Owner:
Type: enhancement | Status: new
Priority: major | Milestone: Fedora 14
Component: Wiki | Version:
Keywords: retrospective |
---------------------------+------------------------------------------------
= problem =
See [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=590661
RHBZ#590661 - GRUB bootloader should have a few seconds delay on a multi-
boot setup]
= analysis =
Due to RHBZ #590661, the dual-boot experience was not well understood and
tested for the final release. It was discovered late and unclear whether
this behavior was critical to Fedora success.
= enhancement recommendation =
Recommend updating existing dual-boot test cases, and create new test as
needed, to reflect updated dual-boot release criteria. Also, add tests to
the install matrix (depends on ticket#80).
The current tests concern dual-booting windows and Mac. I believe Mac is
no longer a primary concern. However, we may wish to add a test for dual-
booting Ubuntu or even Fedora.
See existing dual-boot tests at
https://fedoraproject.org/wiki/Category:Installer_Dual_Boot_Test_Cases
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/82>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
11 years, 10 months
[Fedora QA] #259: Review Fedora 17 feature list and co-ordinate with owners of significant features to create test plans
by fedora-badges
#259: Review Fedora 17 feature list and co-ordinate with owners of significant
features to create test plans
----------------------+-----------------------------------------------------
Reporter: adamwill | Owner:
Type: task | Status: new
Priority: critical | Milestone: Fedora 17
Component: Wiki | Version:
Keywords: |
----------------------+-----------------------------------------------------
We should have someone responsible for reviewing the Fedora 17 feature
list and ensuring a good test plan is in place for any significant and
potentially disruptive feature. This ticket is for the general process of
reviewing the entire feature list; whoever does this may well choose to
create separate tickets for the test plans for specific features.
If you're interested in working on this, please feel free to assign the
ticket to yourself.
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/259>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
11 years, 10 months
[Fedora QA] #256: Add EFI data to installation / base results matrices
by fedora-badges
#256: Add EFI data to installation / base results matrices
-------------------------------+--------------------------------------------
Reporter: adamwill | Owner: adamwill
Type: enhancement | Status: new
Priority: critical | Milestone: Fedora 17
Component: Wiki | Version:
Keywords: efi retrospective |
-------------------------------+--------------------------------------------
It would be nice if we could explicitly include EFI install test results
in the installation matrix.
Right now we just have the efidisk.img test case, which is kind of
outdated: we don't just have a 'special' EFI boot disk any more, EFI
support is integrated into all images.
I'm not yet sure of the best way to lay this out, but I think we need to
capture:
* result of a straight-through DVD install booted via EFI
* result of a straight-through live CD install booted via EFI
* result of a straight-through live-image-written-to-USB-by-livecd-iso-to-
disk install booted via EFI
* result of a straight-through DVD-image-written-to-USB-by-l-i-t-d install
booted via EFI
* result of preupgrading an EFI install
* result of DVD upgrading an EFI install
I think other test cases don't necessarily need to be done both BIOS and
EFI, but we probably need at least the above results.
One way to do this would be to add an "EFI" column to the installation and
base results matrices, and only provide boxes in that column for the test
cases that cover the above features. But that's just one idea; there may
be a better way.
This should be completed in time for F17 Alpha, as EFI boot is considered
Alpha-critical for F17.
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/256>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
11 years, 10 months
[Fedora QA] #260: Cover USB-written images better in installation validation testing
by fedora-badges
#260: Cover USB-written images better in installation validation testing
----------------------+-----------------------------------------------------
Reporter: adamwill | Owner:
Type: task | Status: new
Priority: major | Milestone: Fedora 17
Component: Wiki | Version:
Keywords: |
----------------------+-----------------------------------------------------
It became clear in the Fedora 16 cycle that use of Fedora images (both
live and non-live) written to USB sticks is now extensive, and our current
installation validation tests don't really test this method very
comprehensively. We should extend the installation validation matrix to
cover at least boot and installation in the following situations:
* Live image written to USB stick using livecd-iso-to-disk
* Live image written to USB stick using liveusb-creator
* Live image written to USB stick using dd
* Non-live image written to USB stick using livecd-iso-to-disk
* Non-live image written to USB stick using dd
We may want to consider different l-i-t-d parameters also (especially the
use or non-use of --format could be significant). We could also cover use
of unetbootin as an _informational_ (non-blocking) test, but I'm not super
sure about that.
Part of this ticket is deciding on the best way to represent this -
whether it's by simply creating new test cases and adding them into the
matrix, or somehow re-rendering the matrix to cover these cases as
'variants' of existing test cases, or some other method.
The changes from this ticket and https://fedorahosted.org/fedora-
qa/ticket/256 should be co-ordinated (possibly handled by the same person
or group) as they both involve similar questions of how to revise the
matrix to cover more situations.
This should be completed by Fedora 17 Alpha TC1.
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/260>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
11 years, 10 months
Criterion proposal - keyboard layouts
by drago01
We currently don't have any explicit criterion that mandates that
keyboard layouts choose in the installer should work in the installed
system.
As a maintainer of one of the packages involved there
(system-setup-keyboard) I see such bugs in basically every release,
during the development cycle.
We should pay more attention to such issues as a system that uses a
different keyboard layout as the one physically present can not only
be very annoying (we shouldn't release in that state) but
can be useless when you have special characters in your password(s).
(Can't easily decrypt / login).
As seen in https://lists.fedoraproject.org/pipermail/test/2011-March/097859.html
we do currently have a paragraph that mentions this but is IMO way to
vague.
So I propose something like: "The keyboard layout selected in the
installer must be in use after rebooting the installer (plymouth and
X)".
11 years, 11 months
GNOME shell broken after suspend and resume for driver r300_dri
by Christoph Frieben
Can anybody report success for the suspend and resume cycle triggered
from within the GNOME shell when the graphics card is based on some
R300/R400 variant? In my case, the shell is still broken after resume.
The video device is some ATI Radeon X800 card which is using the R420
chip. Only a black desktop, a mouse pointer and the GNOME panel are
visible after resume. The desktop is not completely frozen since I am
still able to move the mouse pointer. It is also possible to switch to
a VT in order to reboot the system. Thanks, ~C
PS: The F15 development cycle is nearing completion, and in my
opinion, this is a major usability issue.
12 years
[Fedora QA] #270: Proposed Test Day - Sugar Desktop
by fedora-badges
#270: Proposed Test Day - Sugar Desktop
-----------------------+------------------------
Reporter: greenfeld | Owner:
Type: task | Status: new
Priority: major | Milestone: Fedora 17
Component: Test Day | Version:
Keywords: | Blocked By:
Blocking: |
-----------------------+------------------------
The Sugar (www.sugarlabs.org) desktop is being ported to GTK3. Early
versions of this code already are in Rawhide, and the final version is
expected to land in Fedora 17.
We therefore think it would be a good idea to schedule a test day for
Sugar and the SoaS Fedora Spin during the Fedora 17 time frame. March 22
is probably best, although other open test days in March will work as
well.
For reference, the schedule for Sugar 0.95/0.96 may be found at
http://wiki.sugarlabs.org/go/0.96/Roadmap
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/270>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
12 years, 1 month
