From Fedora Project Wiki

< FWN‎ | Beats

(create fwn 250 qa beat)
(create fwn 252 qa beat)
Line 8: Line 8:
<references/>
<references/>


=== Test Days ===
=== Call for Anaconda test cases ===


The Fedora 14 Test Day cycle has concluded. If you would like to propose a main track Test Day for the Fedora 15 cycle, please contact the QA team via email or IRC, or file a ticket in QA Trac<ref>http://fedorahosted.org/fedora-qa/</ref>.
[[User:Clumens|Chris Lumens]] posted a call for test cases<ref>http://lists.fedoraproject.org/pipermail/test/2010-December/095816.html</ref> for automated storage testing in Anaconda, the Fedora system installer. Several people followed up with suggestions for tests.


<references/>
<references/>


=== Installing Rawhide ===
=== Blocker bug tracking process improvements ===


Qiang Li asked what was now the recommended method of installing Rawhide<ref>http://lists.fedoraproject.org/pipermail/test/2010-October/094970.html</ref>, given that a Rawhide installer build is now not always available. [[User:Adamwill|Adam Williamson]] recommended updating from the latest pre-release using yum<ref>http://lists.fedoraproject.org/pipermail/test/2010-October/094971.html</ref>, to which Qiang replied that he does not like doing this due to the time and bandwidth involved<ref>http://lists.fedoraproject.org/pipermail/test/2010-October/094973.html</ref>. Later in the discussion, Christoph Frieben recommended using the latest pre-release installer and specifying Rawhide repositories during the repository selection step<ref>http://lists.fedoraproject.org/pipermail/test/2010-October/094977.html</ref>. [[User:Rhe|Rui He]]<ref>http://lists.fedoraproject.org/pipermail/test/2010-October/094995.html</ref> and [[User:jkeating|Jesse Keating]]<ref>http://lists.fedoraproject.org/pipermail/test/2010-October/094983.html</ref> also suggested this method.
Following some discussion on possible improvements to monitoring blocker bug trackers<ref>http://fedorahosted.org/fedora-qa/ticket/89</ref>, [[User:Bruno|Bruno Wolff]] provided some prefab Bugzilla queries for finding blocker bugs which have been closed but not verified<ref>http://fedoraproject.org/wiki/User:Bruno#Mockup_for_QA_-_Tracking_bug_queries</ref>, to help ensure that blocker bugs do not drop off the radar if they are improperly closed.


<references/>
<references/>


=== Testing updates just prior to release ===
=== Update testing process improvements ===


[[User:Kparal|Kamil Paral]] asked how one can test the installation of updates shortly before a release, when none are available in the official update repositories<ref>http://lists.fedoraproject.org/pipermail/test/2010-October/095001.html</ref>. [[User:Jlaska|James Laska]] recommended downgrading an installed package such as gcalctool<ref>http://lists.fedoraproject.org/pipermail/test/2010-October/095003.html</ref>, and noted he has a repository available for this purpose.
[[User:Kevin|Kevin Fenzi]] posted a call for ideas and comments on potential improvements and adjustments to the update testing processes<ref>http://lists.fedoraproject.org/pipermail/test/2010-November/095756.html</ref>. An extensive discussion followed, and the various ideas presented and discussed will feed into FESCo's consideration of the topic.


<references/>
<references/>


=== Fedora 12 critical path testing ===
=== Critical path test case creation process ===


[[User:Adamwill|Adam Williamson]] noted a Fedora 12 updates-testing report which listed many critical path updates which had been awaiting the required proventester testing for some weeks<ref>http://lists.fedoraproject.org/pipermail/test/2010-October/095135.html</ref>. He proposed removing the proven tester requirement for Fedora 12 critical path updates as a practical measure to allow the updates to go through before EOL. In the mean time, he reported that he had tested several of the updates in a virtual machine<ref>http://lists.fedoraproject.org/pipermail/test/2010-October/095147.html</ref>, and Gene did the same<ref>http://lists.fedoraproject.org/pipermail/test/2010-October/095150.html</ref>, allowing several of the updates to go through.
[[User:Adamwill|Adam Williamson]] announced<ref>http://lists.fedoraproject.org/pipermail/test/2010-December/095857.html</ref> that he had opened a trac ticket<ref>http://fedorahosted.org/fedora-qa/ticket/154</ref> to track the creation of a framework for package-specific test cases to aid the critical path package update testing process. Several recent discussions within both the development and QA groups had reinforced the need for specific test cases for critical path package updates, and he planned to create a framework to aid the creation of these tests and their integration into Bodhi, fedora-easy-karma and similar tools.


<references/>
<references/>

Revision as of 01:46, 9 December 2010

QualityAssurance

In this section, we cover the activities of the QA team[1]. For more information on the work of the QA team and how you can get involved, see the Joining page[2].

Contributing Writer: Adam Williamson

Call for Anaconda test cases

Chris Lumens posted a call for test cases[1] for automated storage testing in Anaconda, the Fedora system installer. Several people followed up with suggestions for tests.

Blocker bug tracking process improvements

Following some discussion on possible improvements to monitoring blocker bug trackers[1], Bruno Wolff provided some prefab Bugzilla queries for finding blocker bugs which have been closed but not verified[2], to help ensure that blocker bugs do not drop off the radar if they are improperly closed.

Update testing process improvements

Kevin Fenzi posted a call for ideas and comments on potential improvements and adjustments to the update testing processes[1]. An extensive discussion followed, and the various ideas presented and discussed will feed into FESCo's consideration of the topic.

Critical path test case creation process

Adam Williamson announced[1] that he had opened a trac ticket[2] to track the creation of a framework for package-specific test cases to aid the critical path package update testing process. Several recent discussions within both the development and QA groups had reinforced the need for specific test cases for critical path package updates, and he planned to create a framework to aid the creation of these tests and their integration into Bodhi, fedora-easy-karma and similar tools.