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
Test Days
This week's Test Day[1] on 2010-08-26 will be on OpenSCAP[2], an open implementation of SCAP, which aims to provide a standardized approach to maintaining the security of systems. This Test Day is most likely to be of interest to those who already have some knowledge of SCAP and are interested in an open source implementation within the Fedora project. As always, the Test Day will run all day in the #fedora-test-day IRC channel.
Next week's Test Day[3] on 2010-09-02 will be on preupgrade[4], the Fedora in-place upgrade system. This is always an important test day as we attempt to ensure the upgrade mechanisms for the next release work as expected. As upgrading is a complex process and highly dependent on the installed system, it would help to have as many testers as possible to help track down any bugs we can find. As always, the Test Day will run all day in the #fedora-test-day IRC channel. You will need to have an installed Fedora 13 system you don't mind hurting in order to help out with the testing - but remember, testing in a virtual machine is easy and non-destructive!
If you would like to propose a main track Test Day for the Fedora 14 cycle, please contact the QA team via email or IRC, or file a ticket in QA Trac[5].
Fedora 14 Alpha testing
As always, the QA team was very active in testing the latest pre-release, Fedora 14 Alpha, conducting desktop[6] and installation[7] validation testing (with the valued help of the desktop SIGs) for each build as we worked through the test candidate[8], RC1[9], RC2[10], RC3[11] and RC4[12]. At the initial go/no-go meeting on 2010-08-12[13], the QA representative Adam Williamson had to propose a slip due to a remaining blocker issue[14]. This issue was resolved in RC4. A second potential blocker lingered, but extensive feedback from many QA group members to Adam's request for testing[15] was instrumental in identifying it as not blocking the release, and at the second go/no-go meeting, QA along with the development and release engineering groups agreed to go ahead with the Alpha release[16].
- ↑ http://fedoraproject.org/wiki/Test_Day:2010-08-26_OpenSCAP
- ↑ http://fedoraproject.org/wiki/Features/OpenSCAP
- ↑ http://fedoraproject.org/wiki/Test_Day:2010-09-02_Preupgrade
- ↑ http://fedoraproject.org/wiki/Preupgrade
- ↑ http://fedorahosted.org/fedora-qa/
- ↑ http://fedoraproject.org/wiki/QA:Desktop_validation_testing
- ↑ http://fedoraproject.org/wiki/QA:Installation_validation_testing
- ↑ http://lists.fedoraproject.org/pipermail/test/2010-August/092367.html
- ↑ http://lists.fedoraproject.org/pipermail/test/2010-August/092468.html
- ↑ http://lists.fedoraproject.org/pipermail/test/2010-August/092493.html
- ↑ http://lists.fedoraproject.org/pipermail/test/2010-August/092573.html
- ↑ http://lists.fedoraproject.org/pipermail/test/2010-August/092700.html
- ↑ http://meetbot.fedoraproject.org/fedora-meeting/2010-08-12/gonogo.2010-08-12-00.00.html
- ↑ https://bugzilla.redhat.com/show_bug.cgi?id=623129
- ↑ http://lists.fedoraproject.org/pipermail/test/2010-August/092681.html
- ↑ http://meetbot.fedoraproject.org/fedora-meeting/2010-08-19/fedora-meeting.2010-08-19-00.00.html
Release criteria update
The blocker review process for Fedora 14 Alpha made it clear that there were several areas where the coverage of the release criteria[1] was incomplete, so Adam Williamson proposed several new criteria in two mailing list threads[2] [3], to cover booting to a console and the 'basic graphics mode' of the installer. The proposals were generally positively received, so Adam went ahead and added them to the criteria[4].
Learning lessons from updates
Kevin Fenzi created a page[1] to track problems caused by updates to stable Fedora releases, and brought it up for discussion during the weekly QA meeting of 2010-08-16[2]. James Laska suggested that issues tracked there should be discussed at the FESCo level, and any issues of concern for QA passed back down to the QA group by FESCo. James also volunteered to adjust the wiki page to track recommendations and results for each issue.
AutoQA
Vojtěch Aschenbrenner created a test case[1] for checking if a new package for a given release would be considered a 'newer' package than the newest version of the same package available in the repositories for later releases, a situation which causes problems with upgrades. Will Woods and Kamil Paral continued to work on the complex dependency check tests, and Will recently posted a summary of the current status and next steps[2].