From Fedora Project Wiki

< FWN‎ | Beats

Revision as of 22:26, 19 February 2010 by Adamwill (talk | contribs) (fwn 214 beat)

QualityAssurance

In this section, we cover the activities of the QA team[1].

Contributing Writer: Adam Williamson

Test Days

Last week's Test Day was on color management[1]. Turnout was moderate, but those who did come helped us resolve several problems in gnome-color-manager. With the fixes introduced by Richard Hughes throughout the day, all testers reported success in using the application to import and apply color profiles. Unfortunately no testers had the extra hardware and/or accessories needed to test generation of accurate profiles for monitors, webcams and scanners, but we tested these features as far as possible without them.

Next week's Test Day[2] will be on the langpack plugin for yum[3]. This feature is intended to automatically install langpacks - packages containing translations for a particular language - for packages which use them. So if your system is configured with French support, when installing a package which keeps its French translation in a separate langpack, the langpack will be automatically installed. This is a great convenience feature for all those who use languages other than English, so please come out and help us test it! The Test Day will run all day on Thursday 2010-02-25 in the #fedora-test-day IRC channel.

If you would like to propose a main track Test Day for the Fedora 13 cycle, please contact the QA team via email or IRC, or file a ticket in QA Trac[4].

Weekly meetings

The QA group weekly meeting[1] was held on 2010-02-15. The full logs are available[2]. James Laska reported that Kevin Fenzi had set up watchers for the IRC bot zodbot for the Fedora 13 blocker bug trackers. John Poelstra had updated the wording on the group calendars slightly to refer to test milestones rather than specifically to installation testing.

James Laska gave an update on the third automated Rawhide testing milestone. He had also sent a recap to the mailing list[3]. As well as finding some more installer bugs, the test run had exposed some areas for improvement in the test scripts, so James and Will Woods would be working on those.

James Laska noted that the second build of the Alpha test compose was now available for testing, and result matrices for installation[4] and desktop[5] validation testing were now available.

James Laska raised Adam Williamson's suggestion that live images be provided along with traditional installer images for specific testing points - pre-releases and candidate builds - to assist in desktop validation testing and live installation testing. Jesse Keating felt this would be an unnecessary complication, as the nightly live images could be used instead, and would in fact ultimately be closer to the final release. Adam pointed out that this made it harder to co-ordinate testing across multiple testers and be confident they were all testing the same code, but was willing to let it slide.

Kamil Paral explained his idea of giving candidate builds different names from the final builds (currently, Alpha candidate images have the same name as the final Alpha image, and so on). Jesse Keating felt this could potentially lead to a case where a bug would only happen with the final image name, and not with the candidate name. It was also difficult in that the name of the built image is tightly linked to the image building process. In the end there was a consensus not to try and uniquely name candidate builds.

Kamil Paral reported that the AutoQA group had discussed plans for the prospective results database, and logged the discussion on the mailing list[6]. They are currently studying other similar projects for ideas and welcome any feedback on the mailing list. Will Woods recapped the general outline of the project: to provide a unified database where all AutoQA tests will report results, for ease of viewing and analysis. He mentioned that use cases for viewing the AutoQA results were one useful type of feedback that would be welcome.

Josef Skladanka explained he had been working with Kamil Paral on the potential use of beakerlib[7] in AutoQA. They had created a simple example test[8] to demonstrate the use of beakerlib in AutoQA. They hope to test migrating some of the existing tests to use beakerlib soon.

James Laska noted that Liam Li had updated the status of automated DVD installation testing on the mailing list[9]. He had continued to work on techniques for providing boot arguments in automated installations, and welcomed ideas on that front.

Finally, James Laska gave an update on the status of gwt packaging, where he had continued to work on the dependency list with the assistance of the Java team. He was aiming to make a start on packaging in the upcoming week.

No Bugzappers group weekly meeting was held on 2010-02-16 as there were no items needing discussion.

The next QA weekly meeting will be held on 2010-02-22 at 1600 UTC in #fedora-meeting. The next Bugzappers weekly meeting will be held on 2010-02-23 at 1500 UTC in #fedora-meeting.

Fedora 13 Alpha test compose validation

Kamil Paral announced[1] the availability of the initial Alpha test compose images. However, these turned out to be unusable[2], and a second set of images was announced[3] by James Laska. Finally, James announced a supplementary update image[4] to fix some major issues encountered in the second test compose. With the second test compose and updates image, group members helped to fill out the installation[5] and desktop[6] results matrices. Andre Robatino provided deltaisos for both F12 to TC1[7] and TC1 to TC2[8].

Privilege escalation policy

Adam Williamson announced that the privilege escalation policy the group had worked on had been accepted by FESCo. It was now in place on the wiki[1].

Security spin QA

Adam Miller presented an outline[1] for testing efforts for the new security spin[2]. He asked the group for help in contributing test cases for the applications that would be specific to the spin.