From Fedora Project Wiki

< FWN‎ | Beats

(whoops, remove a chunk of 225 that was left in my draft)
(create fwn 229 qa beat)
Line 8: Line 8:
<references/>
<references/>


=== Fedora 13 testing ===
=== Fedora 11 EOL bug closure ===


The QA group spent the last two weeks completing Fedora 13 testing and documentation. Following the one week delay of the Fedora 13 release discussed in FWN 225<ref>http://fedoraproject.org/wiki/FWN/Issue225#QualityAssurance</ref>, the team got down to testing the third release candidate<ref>http://lists.fedoraproject.org/pipermail/test/2010-May/090918.html</ref>. We were able to produce a full installation test matrix<ref>http://fedoraproject.org/wiki/Test_Results:Fedora_13_Final_RC3_Install</ref> and desktop test results for GNOME and KDE<ref>http://fedoraproject.org/wiki/Test_Results:Fedora_13_Final_RC3_Desktop</ref>, thanks to the contributions of many team members. With the help of these results, the group was able to confidently support the nomination of RC3 as the final Fedora 13 release compose at the 2010-05-18 go/no-go meeting<ref>http://meetbot.fedoraproject.org/fedora-meeting/2010-05-18/f-13-final-eng-readiness.2010-05-18-23.58.html</ref>. Finally, the group tested an updated preupgrade package for Fedora 12<ref>http://lists.fedoraproject.org/pipermail/test/2010-May/091132.html</ref> which was being prepared in order to be ready for the final Fedora 13 public release date, to ensure that preupgrade-based upgrades from Fedora 12 would run smoothly.
[[User:Poelstra|John Poelstra]] requested<ref>http://lists.fedoraproject.org/pipermail/test/2010-May/091213.html</ref> help from the group in checking his planned procedure for closing Fedora 11 bugs at Fedora 11 EOL, 2010-06-25. [[User:Mooninite|Michael Cronenworth]] couldn't see any problems<ref>http://lists.fedoraproject.org/pipermail/test/2010-May/091215.html</ref>, while [[DaveMalcolm|Dave Malcolm]] suggested a small change<ref>http://lists.fedoraproject.org/pipermail/test/2010-May/091216.html</ref>.


<references/>
<references/>


=== Fedora 13 QA Retrospective ===
=== AutoQA initscript testing ===


At the 2010-05-17 weekly meeting<ref>http://fedoraproject.org/wiki/QA/Meetings/20100517</ref>, [[User:Jlaska|James Laska]] reminded the group that there was a page<ref>http://fedoraproject.org/wiki/Fedora_13_QA_Retrospective</ref> to gather thoughts about the QA process throughout the Fedora 13 cycle, including things that had gone well, things which had not gone so well, and ideas for future enhancements to the QA process.
[[User:Jskladan|Josef Skladanka]] explained<ref>http://lists.fedoraproject.org/pipermail/test/2010-May/091311.html</ref> that the AutoQA team is working on creating tests of LSB compliance in Fedora initscripts, and asked the group for help in validating the tests, and even in creating new ones. He pointed to a wiki page<ref>http://fedorahosted.org/autoqa/wiki/initscripts</ref> which provided details on how to help out.


<references/>
<references/>


=== Making QA sexy ===
=== Real life Bugzapping class ===


At the same meeting, [[User:maxamillion|Adam Miller]] initiated a heroic attempt to achieve the improbable: making QA work sexy. Adam suggested providing customized swag for top QA contributors, such as a special QA group t-shirt. Others were thinking of ways to identify top contributors. [[User:Jlaska|James Laska]] suggested looking at Bodhi feedback. [[User:Wwoods|Will Woods]] thought about a way for developers to nominate testers and bug reporters who had made significant contributions.  
[[User:Vedranm|Vedran Miletić]] mentioned<ref>http://lists.fedoraproject.org/pipermail/test/2010-May/091318.html</ref> that he was again planning to focus on triage during one of his university classes. [[User:Adamwill|Adam Williamson]] offered to be around on IRC during the class to help<ref>http://lists.fedoraproject.org/pipermail/test/2010-May/091321.html</ref>. The class eventually went ahead successfully on 2010-06-07.


<references/>
<references/>


=== Triage scripting ===
=== Proven testers policy finalized ===


At the 2010-05-18 Bugzappers weekly meeting<ref>http://meetbot.fedoraproject.org/fedora-meeting/2010-05-18/fedora-meeting.2010-05-18-15.03.log.html</ref>, [[User:Mcepl|Matej Cepl]] mentioned that he was rewriting his browser scripts to assist the process of triaging, and would be presenting on the topic at GUADEC on 2010-07-28<ref>http://live.gnome.org/GUADEC/2010/Schedule/Main</ref>. He explained that "the idea is a) to propagate existence of the scripts around among developers, b) to make them compatible with multiple instances and making upstream ... I have somebody working on something similar for (Mozilla)".
[[User:maxamillion|Adam Miller]] announced<ref>http://lists.fedoraproject.org/pipermail/test/2010-June/091374.html</ref> that the "proven testers" policy/process had been finalized and published<ref>http://fedoraproject.org/wiki/QA/JoinProvenTesters</ref>. He noted that the form of the mentoring process had not yet been decided, and asked applicants to have patience while the group worked it out. [[User:Jlaska|James Laska]] asked<ref>http://lists.fedoraproject.org/pipermail/test/2010-June/091404.html</ref> "are we ready to start processing these requests?" [[User:Adamwill|Adam Williamson]] suggested<ref>http://lists.fedoraproject.org/pipermail/test/2010-June/091407.html</ref> first agreeing on what mentors should teach applicants, and proposed that the overall aim be to test that critical path updates do not break the tasks which are defined as the basis of the critical path policy<ref>http://fedoraproject.org/wiki/Critical_Path_Packages_Proposal#What_is_the_critical_path_of_actions.3F</ref>. James posted in broad agreement<ref>http://lists.fedoraproject.org/pipermail/test/2010-June/091408.html</ref>.  


<references/>
<references/>


=== AutoQA ===
=== Triage scripts ===


[[User:Jlaska|James Laska]] proposed an email update instead of a weekly meeting for 2010-05-24. In his email<ref>http://lists.fedoraproject.org/pipermail/test/2010-May/091164.html</ref>, he noted that a new version of AutoQA was due, which would include backlinks from test results to the test logs<ref>http://fedorahosted.org/autoqa/ticket/130</ref>, and the ability to subscribe to test results for a specific package<ref>http://fedorahosted.org/autoqa/ticket/151</ref>. Replying<ref>http://lists.fedoraproject.org/pipermail/test/2010-May/091180.html</ref>, [[User:Kparal|Kamil Paral]] noted that his package sanity tests were now working "for the most basic cases" and he was now looking into sandboxing the testing via libvirt. [[User:Wwoods|Will Woods]] reported<ref>http://lists.fedoraproject.org/pipermail/test/2010-May/091188.html</ref> that he was continuing to work on a watcher script for noticing Bodhi updates (as part of the dependency check tests), and hoped to have the post-bodhi-update hook "up and running by the end of this week".
During the Bugzappers weekly meeting of 2010-06-01<ref>http://meetbot.fedoraproject.org/fedora-meeting/2010-06-01/bugzappers.2010-06-01-15.06.log.html</ref>, [[User:Mcepl|Matej Cepl]] outlined his plans for the currently Jetpack prototype-based triage assistance scripts<ref>http://mcepl.fedorapeople.org/scripts/install-bugzillaBugTriage.html</ref>. He explained that the Jetpack prototype had been discontinued by Mozilla in favour of the Jetpack SDK, which carries the same name and has similar goals but is a completely different design, being an SDK which facilitates the creation of regular Firefox extensions, rather than being an extension in its own right on which scripts are run. Matej intends to rewrite the triage scripts on top of the Jetpack SDK, over time and as the SDK becomes more mature. This has the benefit of making it easier and safer to install and run the scripts, and potentially making them easier to port to other browsers.


<references/>
<references/>

Revision as of 00:56, 10 June 2010

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

Fedora 11 EOL bug closure

John Poelstra requested[1] help from the group in checking his planned procedure for closing Fedora 11 bugs at Fedora 11 EOL, 2010-06-25. Michael Cronenworth couldn't see any problems[2], while Dave Malcolm suggested a small change[3].

AutoQA initscript testing

Josef Skladanka explained[1] that the AutoQA team is working on creating tests of LSB compliance in Fedora initscripts, and asked the group for help in validating the tests, and even in creating new ones. He pointed to a wiki page[2] which provided details on how to help out.

Real life Bugzapping class

Vedran Miletić mentioned[1] that he was again planning to focus on triage during one of his university classes. Adam Williamson offered to be around on IRC during the class to help[2]. The class eventually went ahead successfully on 2010-06-07.

Proven testers policy finalized

Adam Miller announced[1] that the "proven testers" policy/process had been finalized and published[2]. He noted that the form of the mentoring process had not yet been decided, and asked applicants to have patience while the group worked it out. James Laska asked[3] "are we ready to start processing these requests?" Adam Williamson suggested[4] first agreeing on what mentors should teach applicants, and proposed that the overall aim be to test that critical path updates do not break the tasks which are defined as the basis of the critical path policy[5]. James posted in broad agreement[6].

Triage scripts

During the Bugzappers weekly meeting of 2010-06-01[1], Matej Cepl outlined his plans for the currently Jetpack prototype-based triage assistance scripts[2]. He explained that the Jetpack prototype had been discontinued by Mozilla in favour of the Jetpack SDK, which carries the same name and has similar goals but is a completely different design, being an SDK which facilitates the creation of regular Firefox extensions, rather than being an extension in its own right on which scripts are run. Matej intends to rewrite the triage scripts on top of the Jetpack SDK, over time and as the SDK becomes more mature. This has the benefit of making it easier and safer to install and run the scripts, and potentially making them easier to port to other browsers.