April 2014 - test - Fedora Mailing-Lists

[Fedora QA] #273: Improve browseability of validation matrix pages

by fedora-badges

#273: Improve browseability of validation matrix pages -----------------------------------------+------------------------ Reporter: adamwill | Owner: adamwill Type: enhancement | Status: new Priority: major | Milestone: Fedora 17 Component: Proventester Mentor Request | Version: Keywords: | Blocked By: Blocking: | -----------------------------------------+------------------------ = problem = cwickert and sandro have told us they have trouble finding the validation matrix pages when they need them. = analysis = we do have the pages logically named and categorized, but it's still not that easy to, for e.g., see all the desktop result pages for a given release at a glance. = enhancement recommendation = We could add more categories, for example "Fedora XX {{desktop,base,install}} validation results" categories, and any others that come to mind (suggestions please!) It would be nice to have 'next / previous' links that would let you browse from Final RC4 back to Final RC3 back to Final RC2 back to Final RC1 back to Final TC2 back to Final TC1 back to Beta RC4 and so on, but I'm not sure if that's plausible to implement automatically (it would be relatively easy to do manually when creating the pages, though). -- Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/273> Fedora QA <http://fedorahosted.org/fedora-qa> Fedora Quality Assurance

8 years, 7 months

1
5
0 / 0

[Fedora QA] #228: SOPs for Everything

by fedora-badges

#228: SOPs for Everything ----------------------+----------------------------------------------------- Reporter: adamwill | Owner: adamwill Type: task | Status: new Priority: major | Milestone: Fedora 17 Component: Wiki | Version: Keywords: | ----------------------+----------------------------------------------------- We should have...SOPs for Everything! This is a meta-ticket with the aim of identifying, well, everything QA does, and making sure they all have SOPs. For a start, I'm going to do a survey of the QA calendar for a release, and check whether we have an SOP for each task. -- Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/228> Fedora QA <http://fedorahosted.org/fedora-qa> Fedora Quality Assurance

8 years, 7 months

1
5
0 / 0

[Fedora QA] #441: Sysadmin permission to beaker for desktop qe

by fedora-badges

#441: Sysadmin permission to beaker for desktop qe -------------------------+------------------ Reporter: vrutkovs | Owner: Type: task | Status: new Priority: major | Milestone: Component: permissions | Version: Keywords: | Blocked By: Blocking: | -------------------------+------------------ Please add vrutkovs, vhumpa and vbenes to beaker's sysadmin group in order to work on desktop tests for Fedora. Approved by tflink -- Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/441> Fedora QA <http://fedorahosted.org/fedora-qa> Fedora Quality Assurance

8 years, 7 months

1
3
0 / 0

[Fedora QA] #429: temporary membership in sysadmin-qa for atodorov so that beaker trial can continue

by fedora-badges

#429: temporary membership in sysadmin-qa for atodorov so that beaker trial can continue -------------------------+------------------ Reporter: tflink | Owner: Type: task | Status: new Priority: minor | Milestone: Component: permissions | Version: Keywords: | Blocked By: Blocking: | -------------------------+------------------ = phenomenon = Long story short, atodorov is helping with the beaker trial we're doing and he needs shell access to the machine in order to complete his work. Assuming that this trial is successful, access to the beaker system(s) will be controlled with a separate FAS group but until that is set up, sysadmin-qa membership is the only way to get the required access. I don't expect the need for membership to last any more than a couple of weeks. -- Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/429> Fedora QA <http://fedorahosted.org/fedora-qa> Fedora Quality Assurance

8 years, 7 months

1
3
0 / 0

[Fedora QA] #404: Look through validation matrices and note which tests don't apply to ARM

by fedora-badges

#404: Look through validation matrices and note which tests don't apply to ARM ----------------------+------------------------ Reporter: adamwill | Owner: pwhalen Type: task | Status: new Priority: blocker | Milestone: Fedora 20 Component: Wiki | Version: Keywords: | Blocked By: Blocking: | ----------------------+------------------------ In the effort to revise the validation pages for ARM, it would help a lot to know which test cases in the existing set are not sensibly applicable to ARM validation. If an ARM folk could go through the pages and list which cases do not apply, that'd be great. Please refer to: * https://fedoraproject.org/wiki/QA:Fedora_20_Install_Results_Template * https://fedoraproject.org/wiki/QA:Base_validation_results_template * https://fedoraproject.org/wiki/QA:Desktop_validation_results_template Thanks! -- Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/404> Fedora QA <http://fedorahosted.org/fedora-qa> Fedora Quality Assurance

8 years, 7 months

1
5
0 / 0

[Fedora QA] #403: Modify initial-setup test case or create new one for ARM (vendor mode)

by fedora-badges

#403: Modify initial-setup test case or create new one for ARM (vendor mode) ------------------------+------------------------ Reporter: adamwill | Owner: pwhalen Type: task | Status: new Priority: blocker | Milestone: Fedora 20 Component: Test cases | Version: Keywords: arm | Blocked By: Blocking: | ------------------------+------------------------ The initial-setup test case - https://fedoraproject.org/wiki/QA:Testcase_base_initial_setup - doesn't really cover the case where initial-setup runs in 'vendor mode'. This mode is currently used only for ARM pre-built images, but since ARM is now primary arch, we need a test case for it. It should be basically a more extensive version of the test case that covers all the bits that would be release blocking for ARM (which I think is language, root password, user password, date/time - really all of it). If the existing test case can be 'conditionalized' elegantly enough, that'd be okay, otherwise just create a variant of it. -- Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/403> Fedora QA <http://fedorahosted.org/fedora-qa> Fedora Quality Assurance

8 years, 7 months

1
3
0 / 0

[Fedora QA] #397: Create test cases for release criteria that are currently missing them

by fedora-badges

8 years, 7 months

1
5
0 / 0

[Fedora QA] #400: Revise 'firstboot' test case

by fedora-badges

#400: Revise 'firstboot' test case ------------------------+------------------------ Reporter: adamwill | Owner: adamwill Type: defect | Status: new Priority: major | Milestone: Fedora 20 Component: Test cases | Version: Keywords: | Blocked By: Blocking: | ------------------------+------------------------ We've fixed up the release criteria for the F19 changes to replace firstboot with initial-setup and gnome-initial-setup and allow user creation in anaconda, but we still have the firstboot test case: https://fedoraproject.org/wiki/QA:Testcase_base_firstboot And the startup test case: https://fedoraproject.org/wiki/QA:Testcase_base_startup assumes the firstboot path too. We should revise those for the new era and the new criterion. -- Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/400> Fedora QA <http://fedorahosted.org/fedora-qa> Fedora Quality Assurance

8 years, 7 months

1
2
0 / 0

[Fedora QA] #396: Revise partitioning test cases to reflect newUI design and cover its intended use cases

by fedora-badges

#396: Revise partitioning test cases to reflect newUI design and cover its intended use cases ----------------------+------------------------ Reporter: adamwill | Owner: Type: task | Status: new Priority: major | Milestone: Fedora 20 Component: Wiki | Version: Keywords: | Blocked By: Blocking: | ----------------------+------------------------ Our current set of 'partitioning test cases' is: * https://fedoraproject.org/wiki/QA:Testcase_Anaconda_autopart_install * https://fedoraproject.org/wiki/QA:Testcase_Anaconda_autopart_(use_free_sp... * https://fedoraproject.org/wiki/QA:Testcase_Anaconda_autopart_(reclaim)_in... * https://fedoraproject.org/wiki/QA:Testcase_Anaconda_autopart_(encrypted)_... * https://fedoraproject.org/wiki/QA:Testcase_anaconda_ext4_rootfs_on_disk_p... * https://fedoraproject.org/wiki/QA:Testcase_Anaconda_custom_partitioning * https://fedoraproject.org/wiki/QA:Testcase_Partitioning_On_Software_RAID * https://fedoraproject.org/wiki/QA:Testcase_dualboot_with_windows * https://fedoraproject.org/wiki/QA:Testcase_anaconda_btrfs_rootfs_on_disk_... * https://fedoraproject.org/wiki/QA:Testcase_anaconda_ext3_rootfs_on_disk_p... * https://fedoraproject.org/wiki/QA:Testcase_anaconda_xfs_rootfs_on_disk_pa... * https://fedoraproject.org/wiki/QA:Testcase_Partitioning_No_Swap * https://fedoraproject.org/wiki/QA:Testcase_Anaconda_autopart_(shrink)_ins... This is kind of a mish-mash of functional and exploratory testing, covering some areas but leaving other large areas entirely uncovered. Several of the tests are also clearly based on the design of the *old* installer's partitioning workflow. At minimum we need to go through the existing cases and ensure the text is correct for the newUI partitioning design. Really, what we need to do is step back and take a wider look at the functionality that is most essential to the newUI design, with reference to the revised release criteria, and revise the entire set of partitioning test cases to cover the most important workflows, including ones we are missing like 're-use existing partitions', 'LVM-on-RAID', the intricacies of UEFI vs. BIOS and ms-dos vs. gpt partitioning, and probably some others I'm forgetting. This may need to be a 'master ticket' and have several smaller sub- tickets, depending on how much work we decide to do on it. -- Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/396> Fedora QA <http://fedorahosted.org/fedora-qa> Fedora Quality Assurance

8 years, 7 months

1
4
0 / 0

[Fedora QA] #394: Revise validation process / templates for ARM as primary arch

by fedora-badges

#394: Revise validation process / templates for ARM as primary arch ----------------------+------------------------ Reporter: adamwill | Owner: Type: task | Status: new Priority: major | Milestone: Fedora 20 Component: Wiki | Version: Keywords: | Blocked By: Blocking: | ----------------------+------------------------ ARM has been accepted as a primary arch at least for buildsystem purposes. The plan is to have 'primary' ARM deliverables as well if possible. This may require us to revise the validation process / template pages to incorporate ARM testing. It may be as 'simple' as throwing a couple of extra columns (for the two ARM variants) alongside x86_64, i686 and EFI in the templates, but we will have to take a look. -- Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/394> Fedora QA <http://fedorahosted.org/fedora-qa> Fedora Quality Assurance

8 years, 7 months

1
6
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

test April 2014