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
Localization testing
Discussion on the topic of localization testing continued, with Rui He proposing to run a Test Day during the Fedora 14 cycle for localization testing, particularly of keyboard layouts[1]. Igor Pires Soares thought this was a great idea and proposed some dates[2]. Eventually, Rui and Igor agreed on 2010-09-09 as the date, and added the event to the schedule[3].
Upstream bug reporting
Discussion also continued on the topic of providing instructions for reporting bugs to upstream bug trackers. Ankur Sinha proposed[1] a rough draft[2]. Jonathan Kamens felt it encouraged users to report bugs upstream instead of reporting them to Fedora, which he thought was a bad idea[3]. Adam Williamson suggested focusing solely on the actual steps for reporting bugs upstream, rather than providing any potential reasons why someone might want to do so[4]. Jóhann Guðmundsson suggested that the instructions should be incorporated into the pages for particular components in the Wiki, rather than being a separate page of their own[5].
- ↑ http://lists.fedoraproject.org/pipermail/test/2010-July/092266.html
- ↑ http://fedoraproject.org/wiki/User:Ankursinha/Reporting_Bugs
- ↑ http://lists.fedoraproject.org/pipermail/test/2010-July/092269.html
- ↑ http://lists.fedoraproject.org/pipermail/test/2010-July/092271.html
- ↑ http://lists.fedoraproject.org/pipermail/test/2010-July/092272.html
Rawhide acceptance testing
James Laska reported[1] on the third (and final) automated Rawhide acceptance test plan[2] run for Fedora 14, and linked to the full results[3]. The run encountered only a single bug, and the test images were declared 'last known good'. However, James cautioned that the images had not included systemd or Python 2.7, which could cause significant changes for the test composes.
SELinux use in testing
Adam Williamson reminded the group that SELinux should always be enabled when testing Fedora, if possible[1]. He explained that since SELinux being enabled is the default configuration of Fedora, it is best for testers to enable SELinux so problems related to it can be caught and fixed as soon as possible.
Proven tester special testing procedures
Adam Williamson recalled a previous proposal to have special testing procedures for the kernel for proven testers, and suggested the idea be put into place as a general concept and proposed some specific procedures for PackageKit, in light of a recent update which had broken update notification for some users[1]. The general response to the proposal was positive. Bob Lightfoot suggested integration with fedora-easy-karma, so that it would display the special testing procedure, or a link to it, when requesting feedback on a package for which a special procedure existed[2]. Adam thought this was a good idea and promised to look into it[3].
Automated bug checking tools release criteria
Adam Williamson proposed adding release criteria to cover the functionality of default automated bug checking tools (such as abrt and sealert)[1]. John Dulaney wondered why making such tools submit reports at an early stage was a high priority. Adam clarified[2] that the tools should usually always be able to submit reports, and when they cannot, it's an unexpected bug: no regular groundwork is required for the tools to be able to submit reports for new releases.
Proven testers working on Fedora 14
Adam Williamson announced that, with the branching of Fedora 14, proven testers are now needed to test and approve critical path package updates for this release[1], just as with the stable Fedora 13 release. He explained that the procedure for proven testers to follow was just the same as that for the existing stable release.