From Fedora Project Wiki

< FWN‎ | Beats

(create fwn 282 qa beat)
(create fwn 283 qa beat)
Line 10: Line 10:
=== Test Days ===
=== Test Days ===


The Fedora 15 Test Day track is now finished, and the main Fedora 16 Test Day track has not yet started. If you would like to propose a main track Test Day for the Fedora 16 cycle, please contact the QA team via email or IRC, or file a ticket in QA Trac<ref>http://fedorahosted.org/fedora-qa/</ref>.
The Fedora 15 Test Day track is now finished, and the main Fedora 16 Test Day track has not yet started. If you would like to propose a main track Test Day for the Fedora 16 cycle, please contact the QA team via email or IRC, or file a ticket in QA Trac<ref>http://fedorahosted.org/fedora-qa/</ref>. [[User:Noriko|Noriko Mizumoto]] proposed a localization Test Day for 2011-08-22<ref>http://fedorahosted.org/fedora-qa/ticket/222</ref>.


<references/>
<references/>
Line 16: Line 16:
=== Release criteria and validation testing ===
=== Release criteria and validation testing ===


[[User:Rhe|Rui He]] added the finished VNC installation test cases to the install testing template<ref>http://fedorahosted.org/fedora-qa/ticket/210#comment:3</ref>. [[User:Adamwill|Adam Williamson]] provided a survey comparing the Beta release criteria against the validation test cases<ref>http://fedorahosted.org/fedora-qa/ticket/151#comment:15</ref>, as he previously had for the Alpha release criteria (see FWN #280), and began filing tickets to request updates to the validation tests where needed.
[[User:Rhe|Rui He]] worked on adding new release validation tests and extending existing ones in response to the results of the Beta release criteria / validation test concordance survey [[User:Adamwill|Adam Williamson]] performed the previous week (see FWN 282)<ref>http://fedorahosted.org/fedora-qa/ticket/216</ref> <ref>http://fedorahosted.org/fedora-qa/ticket/217</ref> <ref>http://fedorahosted.org/fedora-qa/ticket/218</ref> <ref>http://fedorahosted.org/fedora-qa/ticket/219</ref>.


[[User:Jlaska|James Laska]] put into production<ref>http://lists.fedoraproject.org/pipermail/test/2011-July/101156.html</ref> his proposed changes to the release criteria to make them more generic (see FWN #280). James proceeded on to considering ways to implement release criteria and criteria variations specific to secondary architectures, outlining several possible ways to proceed with this<ref>http://lists.fedoraproject.org/pipermail/test/2011-July/101177.html</ref>. [[User:Johannbg|Jóhann Guðmundsson]]<ref>http://lists.fedoraproject.org/pipermail/test/2011-July/101178.html</ref>, [[User:Adamwill|Adam Williamson]]<ref>http://lists.fedoraproject.org/pipermail/test/2011-July/101182.html</ref> and [[User:Ausil|Dennis Gilmore]]<ref>http://lists.fedoraproject.org/pipermail/test/2011-July/101192.html</ref> provided feedback on his proposals, and all involved generally agreed on an approach to the problem.
[[User:Athmane|Athmane Madjoudj]] put the security lab spin validation matrix he had been working on into production<ref>http://fedorahosted.org/fedora-qa/ticket/207#comment:3</ref>. [[User:Adamwill|Adam Williamson]] did the same with the base validation matrix he had been working on, and emailed the list with details of the two new matrices and some related changes he had made to the validation testing wiki pages at the same time<ref>http://lists.fedoraproject.org/pipermail/test/2011-July/101284.html</ref>.


[[User:Adamwill|Adam Williamson]] expanded his proposed 'base' release validation test matrix into a full proposed template page<ref>http://lists.fedoraproject.org/pipermail/test/2011-July/101180.html</ref>, and requested feedback on the draft.
<references/>
 
=== Separation of release validation and feature processes ===
 
After [[User:Jlaska|James Laska]] announced the first Fedora 16 blocker bug review meeting<ref>http://lists.fedoraproject.org/pipermail/test/2011-July/101303.html</ref>, [[User:Bruno|Bruno Wolff]] asked what was to be done<ref>http://lists.fedoraproject.org/pipermail/test/2011-July/101304.html</ref>. with the large amount of proposed blocker bugs relating to the Fedora 16 feature of porting core system services from SysV to systemd<ref>http://fedoraproject.org/wiki/Features/SysVtoSystemd</ref>. [[User:Adamwill|Adam Williamson]] noted that the group had lately been consistent in rejecting proposed blockers which related simply to the implementation of features, preferring to keep the feature and release validation processes separate, and consider the release blocker system part of the release validation process. He proposed that the proposed blocker bugs related to this feature should be rejected en masse, and suggested that the separation between the feature and release validation processes should be made more explicit<ref>http://lists.fedoraproject.org/pipermail/test/2011-July/101305.html</ref>. He clarified this idea in a subsequent message<ref>http://lists.fedoraproject.org/pipermail/test/2011-July/101316.html</ref>. The idea met with the approval of James and [[User:Johannbg|Jóhann Guðmundsson]]<ref>http://lists.fedoraproject.org/pipermail/test/2011-July/101320.html</ref>, so Adam proposed it to FESCo (as the stewards of the feature process) via the development mailing list<ref>http://lists.fedoraproject.org/pipermail/devel/2011-July/154345.html</ref>.
 
<references/>
 
=== Shortening blocker bug review meetings ===
 
[[User:Tflink|Tim Flink]] kicked off an effort to reduce the length of blocker bug review meetings with several ideas<ref>http://fedorahosted.org/fedora-qa/ticket/221</ref>. [[User:Adamwill|Adam Williamson]] chipped in with some comments. At the blocker bug review meeting of 2011-07-15<ref>http://meetbot.fedoraproject.org/fedora-bugzappers/2011-07-15/f16-alpha-blocker.2011-07-15-17.00.log.html</ref>, those present at the meeting discussed Tim's ideas, and came away with a plan of following up on the idea of trying to provide more information in the bug reports outside of meetings in a more informal way than Tim had produced.


<references/>
<references/>


=== A plea to proventesters ===
=== QA group meeting SOP ===


[[User:Mschwendt|Michael Schwendt]] reminded proventesters<ref>http://lists.fedoraproject.org/pipermail/test/2011-July/101159.html</ref> not to file positive feedback on an update for which a previous tester had provided negative feedback unless they were very sure the negative feedback was erroneous.
[[User:Jlaska|James Laska]] posted<ref>http://lists.fedoraproject.org/pipermail/test/2011-July/101253.html</ref> a draft SOP (standard operating procedure) for running the QA group meetings<ref>http://fedoraproject.org/wiki/User:Jlaska/QA:SOP_IRC_meeting</ref>. [[User:Gbraad|Gerard Braad]] suggested it could be applied more generally<ref>http://lists.fedoraproject.org/pipermail/test/2011-July/101256.html</ref>. [[User:Bruno|Bruno Wolff]], Gerard and James elaborated this into a plan to provide a general meeting SOP and customized, group-specific versions using Wiki templates<ref>http://lists.fedoraproject.org/pipermail/test/2011-July/101261.html</ref>. [[MatthiasClasen|Matthias Clasen]] thought the idea of an SOP for one of 'the most basic things' was unnecessary<ref>http://lists.fedoraproject.org/pipermail/test/2011-July/101268.html</ref>, but James disagreed<ref>http://lists.fedoraproject.org/pipermail/test/2011-July/101270.html</ref>, and Bruno and [[User:Jdulaney|John Dulaney]] said they had found themselves hosting the group meetings in the past, and would have found such a guide valuable <ref>http://lists.fedoraproject.org/pipermail/test/2011-July/101272.html</ref> <ref>http://lists.fedoraproject.org/pipermail/test/2011-July/101273.html</ref>.


<references/>
<references/>
Line 32: Line 42:
=== AutoQA ===
=== AutoQA ===


Having finished and released AutoQA 0.5.0, the AutoQA team was planning for the 0.6.0 development cycle<ref>http://fedorahosted.org/pipermail/autoqa-devel/2011-July/002524.html</ref>. [[User:Jlaska|James Laska]] and [[User:Kparal|Kamil Paral]] have been working on an SOP for AutoQA releases<ref>http://fedoraproject.org/wiki/AutoQA_Release_Process</ref>.
[[User:Kparal|Kamil Paral]] continued to work on the SOP for AutoQA releases<ref>http://fedoraproject.org/wiki/AutoQA_Release_Process</ref> with input from [[User:Tflink|Tim Flink]]<ref>http://fedorahosted.org/pipermail/autoqa-devel/2011-July/002536.html</ref> and [[User:Jlaska|James Laska]]<ref>http://fedorahosted.org/pipermail/autoqa-devel/2011-July/002530.html</ref>.
 
The group also continued to work on planning for AutoQA 0.6. They held an IRC planning meeting on 2011-07-14, and Tim sent the minutes to the list<ref>http://fedorahosted.org/pipermail/autoqa-devel/2011-July/002594.html</ref>.
 
Tim suggested having a custom 404 page for the AutoQA results site, containing information likely to be useful to people hitting missing pages, which are likely to be old logs which are no longer retained<ref>http://fedorahosted.org/pipermail/autoqa-devel/2011-July/002546.html</ref>.
 
Tim was also working on improving automated self-testing of AutoQA, and proposed identifying situations that would make for good functional regression tests<ref>http://fedorahosted.org/autoqa/ticket/352</ref> and creating mockups of AutoQA's external dependencies (other systems without which it is difficult to run or test AutoQA correctly)<ref>http://fedorahosted.org/autoqa/ticket/353</ref>.
 
Pausing only for a coffee and a handful of amphetamines, Tim continued with a demo of AutoQA documentation converted to use the Sphinx system<ref>http://fedorahosted.org/pipermail/autoqa-devel/2011-July/002569.html</ref>. [[User:Kparal|Kamil Paral]]<ref>http://fedorahosted.org/pipermail/autoqa-devel/2011-July/002575.html</ref>, [[User:Jskladan|Josef Skladanka]]<ref>http://fedorahosted.org/pipermail/autoqa-devel/2011-July/002576.html</ref> and [[User:Jdulaney|John Dulaney]]<ref>http://fedorahosted.org/pipermail/autoqa-devel/2011-July/002580.html</ref> provided feedback and suggestions. A side thread<ref>http://fedorahosted.org/pipermail/autoqa-devel/2011-July/002571.html</ref> provided a venue for a discussion on a more general level of the correct approach to documentation.
 
[[User:Jlaska|James Laska]] announced the availability of AutoQA 0.5.1 packages in the testing repository <ref>http://fedorahosted.org/pipermail/autoqa-devel/2011-July/002603.html</ref>


<references/>
<references/>

Revision as of 22:25, 20 July 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 track is now finished, and the main Fedora 16 Test Day track has not yet started. If you would like to propose a main track Test Day for the Fedora 16 cycle, please contact the QA team via email or IRC, or file a ticket in QA Trac[1]. Noriko Mizumoto proposed a localization Test Day for 2011-08-22[2].

Release criteria and validation testing

Rui He worked on adding new release validation tests and extending existing ones in response to the results of the Beta release criteria / validation test concordance survey Adam Williamson performed the previous week (see FWN 282)[1] [2] [3] [4].

Athmane Madjoudj put the security lab spin validation matrix he had been working on into production[5]. Adam Williamson did the same with the base validation matrix he had been working on, and emailed the list with details of the two new matrices and some related changes he had made to the validation testing wiki pages at the same time[6].

Separation of release validation and feature processes

After James Laska announced the first Fedora 16 blocker bug review meeting[1], Bruno Wolff asked what was to be done[2]. with the large amount of proposed blocker bugs relating to the Fedora 16 feature of porting core system services from SysV to systemd[3]. Adam Williamson noted that the group had lately been consistent in rejecting proposed blockers which related simply to the implementation of features, preferring to keep the feature and release validation processes separate, and consider the release blocker system part of the release validation process. He proposed that the proposed blocker bugs related to this feature should be rejected en masse, and suggested that the separation between the feature and release validation processes should be made more explicit[4]. He clarified this idea in a subsequent message[5]. The idea met with the approval of James and Jóhann Guðmundsson[6], so Adam proposed it to FESCo (as the stewards of the feature process) via the development mailing list[7].

Shortening blocker bug review meetings

Tim Flink kicked off an effort to reduce the length of blocker bug review meetings with several ideas[1]. Adam Williamson chipped in with some comments. At the blocker bug review meeting of 2011-07-15[2], those present at the meeting discussed Tim's ideas, and came away with a plan of following up on the idea of trying to provide more information in the bug reports outside of meetings in a more informal way than Tim had produced.

QA group meeting SOP

James Laska posted[1] a draft SOP (standard operating procedure) for running the QA group meetings[2]. Gerard Braad suggested it could be applied more generally[3]. Bruno Wolff, Gerard and James elaborated this into a plan to provide a general meeting SOP and customized, group-specific versions using Wiki templates[4]. Matthias Clasen thought the idea of an SOP for one of 'the most basic things' was unnecessary[5], but James disagreed[6], and Bruno and John Dulaney said they had found themselves hosting the group meetings in the past, and would have found such a guide valuable [7] [8].

AutoQA

Kamil Paral continued to work on the SOP for AutoQA releases[1] with input from Tim Flink[2] and James Laska[3].

The group also continued to work on planning for AutoQA 0.6. They held an IRC planning meeting on 2011-07-14, and Tim sent the minutes to the list[4].

Tim suggested having a custom 404 page for the AutoQA results site, containing information likely to be useful to people hitting missing pages, which are likely to be old logs which are no longer retained[5].

Tim was also working on improving automated self-testing of AutoQA, and proposed identifying situations that would make for good functional regression tests[6] and creating mockups of AutoQA's external dependencies (other systems without which it is difficult to run or test AutoQA correctly)[7].

Pausing only for a coffee and a handful of amphetamines, Tim continued with a demo of AutoQA documentation converted to use the Sphinx system[8]. Kamil Paral[9], Josef Skladanka[10] and John Dulaney[11] provided feedback and suggestions. A side thread[12] provided a venue for a discussion on a more general level of the correct approach to documentation.

James Laska announced the availability of AutoQA 0.5.1 packages in the testing repository [13]