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
Instructions and process for moving bug reports upstream
Ankur Sinha began a discussion[1], [2] on providing instructions for users on the Wiki for reporting bugs to upstream bug trackers. Jóhann Guðmundsson felt that this was the wrong approach[3] and that it should be the responsibility of package maintainers to submit reports upstream when appropriate. In general, though, the group felt that providing instructions for users would be helpful in at least some cases, and Ankur said he would work on a draft of such a page[4].
Rawhide acceptance testing
James Laska reported[1] on the first automated Rawhide acceptance test plan[2] run for Fedora 14, and linked to the full results[3]. The run exposed four bugs, which were significant enough that the test images could not be declared 'last known good'.
Proven testers
Adam Williamson announced[1] that he had updated the Wiki proven testers material, making the main page[2] cover all aspects of the project (based on his previous draft mentioned in last week's issue) and turning the JoinProvenTesters page into a redirect to it. Later in the week he updated the instructions again[3].
AutoQA package acceptance testing
During the QA weekly meeting of 2010-07-12[1], Will Woods explained that the AutoQA team had decided to consider automating the package update acceptance test plan[2] as its highest priority. They felt this would provide a very visible and useful example of the potential of AutoQA as soon as possible. Automated package acceptance testing would prevent packages with certain types of serious problems, such as broken dependencies, from being accepted as updates. Will had identified clear areas of focus which are necessary to implement automated package acceptance testing, and these can be tracked on the AutoQA roadmap[3].
Localization testing
Igor Pires Soares announced[1] that he would be working to update the Fedora 13 localization results template[2] for Fedora 14 use at FUDCon Santiago, and asked for feedback and ideas on improving it. James Laska suggested[3] a page to explain the general testing procedure, and asked where test results are recorded. Igor accepted the general procedure idea, and explained that the template was intended to allow local teams to record results in whatever way they felt most appropriate[4].
After a contentious first Fedora 14 blocker bug review meeting[1], Adam Williamson proposed two alternative ways to cover boot menu functionality in the release criteria[2]. He suggested either having a basic test of essential functionality (the installer eventually boots without manual interaction) at the Alpha stage and a more advanced test (the graphical boot menu appears as intended) at Beta or Final stage, or simply having the more advanced test at Alpha stage. James Laska[3] and Jesse Keating[4] both came down in favour of simply requiring the menu to work correctly at Alpha stage.