From Fedora Project Wiki

< FWN‎ | Beats

(create fwn 283 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>. [[User:Noriko|Noriko Mizumoto]] proposed a localization Test Day for 2011-08-22<ref>http://fedorahosted.org/fedora-qa/ticket/222</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>. At the weekly group meeting of 2011-07-18<ref>http://fedoraproject.org/wiki/QA/Meetings/20110718</ref>, the group agreed to delay the planned Fedora 15 on Amazon EC2 Test Day on 2011-07-19, as the images would not be ready in time. [[User:Adamwill|Adam Williamson]] pencilled in the X Test Week for 2011-08-30 to 2011-09-01<ref>http://fedorahosted.org/fedora-qa/ticket/223</ref>, and [[User:Jskarvad|Jaroslav Škarvada]] proposed a power management Test Day for 2011-09-29<ref>http://fedorahosted.org/fedora-qa/ticket/225</ref>. Adam sent out a call for Test Days<ref>http://lists.fedoraproject.org/pipermail/test/2011-July/101393.html</ref>.


<references/>
<references/>


=== Release criteria and validation testing ===
=== oVirt node spin review and testing ===


[[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>.
At the weekly meeting, the group held an initial discussion of the proposed oVirt node spin<ref>http://fedoraproject.org/wiki/Ovirt_Node_Spin</ref>, from the standpoint of whether to grant it QA approval. [[User:Athmane|Athmane Madjoudj]] volunteered to work on making sure the necessary testing framework was in place. By 2011-07-22, he had a draft validation matrix<ref>http://fedoraproject.org/wiki/User:Athmane/Draft_Ovirt_Node_validation_matrix</ref> ready for review<ref>http://lists.fedoraproject.org/pipermail/test/2011-July/101439.html</ref>.


[[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>.
<references/>
 
=== QA group meeting SOP ===
 
[[User:Jlaska|James Laska]] announced<ref>http://lists.fedoraproject.org/pipermail/test/2011-July/101358.html</ref> that he had put the draft group meeting SOP (see [[FWN/Issue282#QA_group_meeting_SOP|FWN #282]]) into production<ref>http://fedoraproject.org/wiki/QA:SOP_IRC_meeting_process</ref>.


<references/>
<references/>
Line 24: Line 28:
=== Separation of release validation and feature processes ===
=== 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>.
At the FESCo meeting of 2011-07-18<ref>http://meetbot.fedoraproject.org/fedora-meeting/2011-07-18/fesco.2011-07-18-17.01.log.html</ref>, FESCo approved the group's proposal (see [[FWN/Issue282#Separation_of_release_validation_and_feature_processes|FWN #282]]) to formalize the separation between the release validation and feature processes. [[User:Adamwill|Adam Williamson]] subsequently announced that he had made the necessary changes to the wiki<ref>http://lists.fedoraproject.org/pipermail/test/2011-July/101368.html</ref>.


<references/>
<references/>


=== Shortening blocker bug review meetings ===
=== Fedora 16 Alpha RATs run ===


[[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.
[[User:twu|Tao Wu]] announced the completion of the first RATs (Rawhide Acceptance Tests) automated installation testing run for Fedora 16 Alpha<ref>http://lists.fedoraproject.org/pipermail/test/2011-July/101376.html</ref>. He reported that the testing failed due to a major bug in installation<ref>http://bugzilla.redhat.com/show_bug.cgi?id=723144</ref>.


<references/>
<references/>


=== QA group meeting SOP ===
=== Instalatron anaconda testing framework ===


[[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>.
Sergio Rubio of FrameOS<ref>http://frameos.org</ref> wrote to let the group know<ref>http://lists.fedoraproject.org/pipermail/test/2011-July/101384.html</ref> of the release of Instalatron<ref>http://github.com/abiquo/instalatron</ref>, a testing framework for anaconda based around VirtualBox input automation and ImageMagick image comparison. [[User:Jlaska|James Laska]] replied to thank Sergio for reaching out, and to point out the similar work being done by [[User:twu|Tao Wu]] and [[User:Hongqing|Hongqing Yang]] to automate the Fedora installation validation matrix<ref>http://lists.fedoraproject.org/pipermail/test/2011-July/101385.html</ref>. [[User:Tflink|Tim Flink]] asked some questions about the design of Instalatron<ref>http://lists.fedoraproject.org/pipermail/test/2011-July/101387.html</ref>, and Sergio provided some answers<ref>http://lists.fedoraproject.org/pipermail/test/2011-July/101399.html</ref>. [[User:Eblake|Eric Blake]] noted that KVM had recently grown the ability to inject keyboard scancodes<ref>http://lists.fedoraproject.org/pipermail/test/2011-July/101400.html</ref>, which Sergio had cited as the main reason for choosing VirtualBox. [[User:Dcantrel|David Cantrell]] gave a heads-up that the design of anaconda would soon change quite drastically<ref>http://lists.fedoraproject.org/pipermail/test/2011-July/101415.html</ref>, and James recommended the use of AT-SPI in preference to image analysis<ref>http://lists.fedoraproject.org/pipermail/test/2011-July/101416.html</ref>. Sergio thanked everyone for their feedback<ref>http://lists.fedoraproject.org/pipermail/test/2011-July/101417.html</ref>.


<references/>
<references/>


=== AutoQA ===
=== Release criteria updates ===
 
[[User:Jlaska|James Laska]] followed up his initial survey of ways to handle secondary architecture release criteria (see [[FWN/Issue281#Release_criteria_and_validation_testing|FWN #281]]) with a draft<ref>http://lists.fedoraproject.org/pipermail/test/2011-July/101431.html</ref> of the preferred approach<ref>http://lists.fedoraproject.org/pipermail/test/2011-July/101431.html</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>.  
James also proposed some changes to the criteria following from the second Alpha blocker bug review meeting<ref>http://lists.fedoraproject.org/pipermail/test/2011-July/101446.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>.
<references/>
 
=== AutoQA ===


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>.  
[[User:Jlaska|James Laska]] wondered if it would be possible to run depcheck tests on EPEL packages<ref>http://fedorahosted.org/pipermail/autoqa-devel/2011-July/002615.html</ref>. [[User:Kparal|Kamil Paral]] said it had not been tried yet, and had some questions about the benefits. He summarized that "Overall it should be doable, but it requires quite some work and resources."<ref>http://fedorahosted.org/pipermail/autoqa-devel/2011-July/002616.html</ref>. James said he would check if it was the EPEL SIG or individual maintainers who were interested<ref>http://fedorahosted.org/pipermail/autoqa-devel/2011-July/002621.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>.
[[User:Jskladan|Josef Skladanka]] posted<ref>http://fedorahosted.org/pipermail/autoqa-devel/2011-July/002620.html</ref> a "brain dump" of ideas he and Kamil had come up with around depcheck<ref>http://fedoraproject.org/wiki/User:Jskladan/Sandbox:Depcheck</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.
Kamil proposed (and later carried out) the inclusion of a NEWS file in the AutoQA source<ref>http://fedorahosted.org/pipermail/autoqa-devel/2011-July/002622.html</ref>, and provided a draft<ref>http://kparal.fedorapeople.org/autoqa/NEWS</ref>.


[[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>
The group continued to work on several tasks related to making AutoQA output more attractive and legible<ref>http://fedorahosted.org/autoqa/ticket/351</ref> <ref>http://fedorahosted.org/autoqa/ticket/359</ref> <ref>http://fedorahosted.org/autoqa/ticket/361</ref>.


<references/>
<references/>

Revision as of 05:53, 28 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]. At the weekly group meeting of 2011-07-18[2], the group agreed to delay the planned Fedora 15 on Amazon EC2 Test Day on 2011-07-19, as the images would not be ready in time. Adam Williamson pencilled in the X Test Week for 2011-08-30 to 2011-09-01[3], and Jaroslav Škarvada proposed a power management Test Day for 2011-09-29[4]. Adam sent out a call for Test Days[5].

oVirt node spin review and testing

At the weekly meeting, the group held an initial discussion of the proposed oVirt node spin[1], from the standpoint of whether to grant it QA approval. Athmane Madjoudj volunteered to work on making sure the necessary testing framework was in place. By 2011-07-22, he had a draft validation matrix[2] ready for review[3].

QA group meeting SOP

James Laska announced[1] that he had put the draft group meeting SOP (see FWN #282) into production[2].

Separation of release validation and feature processes

At the FESCo meeting of 2011-07-18[1], FESCo approved the group's proposal (see FWN #282) to formalize the separation between the release validation and feature processes. Adam Williamson subsequently announced that he had made the necessary changes to the wiki[2].

Fedora 16 Alpha RATs run

Tao Wu announced the completion of the first RATs (Rawhide Acceptance Tests) automated installation testing run for Fedora 16 Alpha[1]. He reported that the testing failed due to a major bug in installation[2].

Instalatron anaconda testing framework

Sergio Rubio of FrameOS[1] wrote to let the group know[2] of the release of Instalatron[3], a testing framework for anaconda based around VirtualBox input automation and ImageMagick image comparison. James Laska replied to thank Sergio for reaching out, and to point out the similar work being done by Tao Wu and Hongqing Yang to automate the Fedora installation validation matrix[4]. Tim Flink asked some questions about the design of Instalatron[5], and Sergio provided some answers[6]. Eric Blake noted that KVM had recently grown the ability to inject keyboard scancodes[7], which Sergio had cited as the main reason for choosing VirtualBox. David Cantrell gave a heads-up that the design of anaconda would soon change quite drastically[8], and James recommended the use of AT-SPI in preference to image analysis[9]. Sergio thanked everyone for their feedback[10].

Release criteria updates

James Laska followed up his initial survey of ways to handle secondary architecture release criteria (see FWN #281) with a draft[1] of the preferred approach[2].

James also proposed some changes to the criteria following from the second Alpha blocker bug review meeting[3].

AutoQA

James Laska wondered if it would be possible to run depcheck tests on EPEL packages[1]. Kamil Paral said it had not been tried yet, and had some questions about the benefits. He summarized that "Overall it should be doable, but it requires quite some work and resources."[2]. James said he would check if it was the EPEL SIG or individual maintainers who were interested[3].

Josef Skladanka posted[4] a "brain dump" of ideas he and Kamil had come up with around depcheck[5].

Kamil proposed (and later carried out) the inclusion of a NEWS file in the AutoQA source[6], and provided a draft[7].

The group continued to work on several tasks related to making AutoQA output more attractive and legible[8] [9] [10].