From Fedora Project Wiki

< FWN‎ | Beats

(create fwn 257 qa beat)
(update fwn 257 qa beat)
Line 17: Line 17:


[[User:Fcami|François Cami]] posted a refined version of his Bodhi patch<ref>http://lists.fedoraproject.org/pipermail/test/2010-December/096017.html</ref> which improves the messages it posts to Bugzilla when an update is sent to updates-testing and then to stable. The updated patch reflects feedback from other team members at QA meetings.
[[User:Fcami|François Cami]] posted a refined version of his Bodhi patch<ref>http://lists.fedoraproject.org/pipermail/test/2010-December/096017.html</ref> which improves the messages it posts to Bugzilla when an update is sent to updates-testing and then to stable. The updated patch reflects feedback from other team members at QA meetings.
<references/>
=== Package-specific and critical path test case process ===
Following up on his earlier proposals (see this beat in FWN #255) [[User:Adamwill|Adam Williamson]] announced<ref>http://lists.fedoraproject.org/pipermail/test/2010-December/096095.html</ref> two draft Wiki pages<ref>http://fedoraproject.org/wiki/User:Adamwill/Draft_QA_SOP_test_case_creation</ref> <ref>http://fedoraproject.org/wiki/User:Adamwill/Draft_QA_SOP_package_test_plan_creation</ref> that would implement a process for creating and categorizing test cases such that they can be identified as related to specific packages and/or related to critical path functionality. Following useful feedback from [[User:Jlaska|James Laska]]<ref>http://lists.fedoraproject.org/pipermail/test/2010-December/096098.html</ref>, Adam revised the proposals, and continues to do so based on further feedback on the mailing lists and the trac ticket<ref>http://fedorahosted.org/fedora-qa/ticket/154</ref>.


<references/>
<references/>

Revision as of 22:41, 5 January 2011

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

The Fedora 15 Test Day calendar is starting to take shape, and you can see what events are planned so far on the Wiki page[1]. The first Test Day slot is 2011-01-27. 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[2].

Refining Bugzilla messages on updated packages

François Cami posted a refined version of his Bodhi patch[1] which improves the messages it posts to Bugzilla when an update is sent to updates-testing and then to stable. The updated patch reflects feedback from other team members at QA meetings.

Package-specific and critical path test case process

Following up on his earlier proposals (see this beat in FWN #255) Adam Williamson announced[1] two draft Wiki pages[2] [3] that would implement a process for creating and categorizing test cases such that they can be identified as related to specific packages and/or related to critical path functionality. Following useful feedback from James Laska[4], Adam revised the proposals, and continues to do so based on further feedback on the mailing lists and the trac ticket[5].

Test case management system proposal and requirements

Rui He has been working on the possibility of implementing a test case management system (TCMS) for Fedora. This is being tracked in a trac ticket[1] and she has now started drafting the requirements any TCMS would have to satisfy to replace the use of the Fedora Wiki to store test cases[2].

AutoQA

Work on AutoQA continues to progress apace - there is much more than I am able to reliably relay in these newsletters, those who are very interested are recommended to follow the mailing list[1]. The anaconda storage tests contributed by Chris Lumens have been reviewed and are ready for merging[2]. Martin Krizek's patch for allowing results to be reported to Bodhi[3] has been reviewed and accepted[4]. Martin and Kamil Paral have been working on implementing a staging server for results, and Will Woods continues to work on dependency check testing. He has now decided to serialize dependency check tests to avoid the complexity involved in supporting parallel tests, having worked out that even at the busiest point, dependency check testing will only be needed, on average, once every 33 minutes.

Consequences of negative karma

Brendan Jones asked about the consequences of negative karma, wondering whether test updates he filed negative karma against should be immediately un-pushed, or prevented from being sent to the stable update repository[1]. Kevin Fenzi[2] and Adam Williamson[3] both explained that negative feedback was considered advisory in nature, and maintainers are able to push updates despite the existence of negative feedback, if they believe it is proper to do so. They both suggested that Brendan could alert FESCo if he felt a packager was ignoring negative feedback inappropriately. Brendan replied that he had asked only for clarification, and did not feel the cases in question were inappropriate[4].