As someone who has been filing bugs for a long time but who is new to this mailing list, I have some suggestions regarding wiki page cleanup. I see four "main" QA pages floating around: http://fedoraproject.org/wiki/QA http://fedoraproject.org/wiki/User:Johannbg/Draft/QA https://fedoraproject.org/wiki/User:Leam http://fedoraproject.org/wiki/SIGs/QA First of all, some clarity is needed whether BugZappers and QA are "subprojects" or a "SIGs", and [[SIG/QA]] should be merged with [[QA]] and its subpages. The User:Leam page is intended as a destination for a link from http://fedoraproject.org/wiki/Join. I think it would be a good idea to add a "Tester" role to [[Join]], since "OS Developer" to me means someone who can write or edit code, but there is plenty of work to be done by people who only do testing. I guess a new table could be added for that role, with specific tasks, but I don't think there's a need for an entirely separate page just for new volunteers. The "Testing" link points to [[QA]], and making that the one-stop shop for "what's up with this subproject" seems like a good idea to me. To be honest, I prefer the current copy of http://fedoraproject.org/wiki/QA to the Johannbg draft. Splitting up activities into "Quality Control", "Quality Assurance" and "Development" does not seem helpful, especially since "Quality Control" and "Quality Assurance" sound like synonyms to many people, and the latter has no content in that draft. And as far as I can tell, "Development" (actually fixing bugs) is outside the scope of the QA subproject. This is what [[Package Maintainers]] does. [[Development]] is also something of a mess; [[QA]] is listed as a subset, along with [[PackageMaintainers]] and (implicitly) [[ReleaseEngineering]]. This page should probably just go away. The most important thing for [[QA]] to do is clearly list all of the activities of the subproject on one page, so volunteers can find tasks of interest, and the content for everything is really easy to find. As far as I can tell, this is what people do now or want to be able to do: Documented by [[BugZappers]]: * Bug Triage: Examine bugs reported by other people and resolve duplicates, incomplete reports, and other problems to save time for [[PackageMaintainers]]. This is coordinated at the independent [[BugZappers]] subproject, which shares the fedora-test-list mailing list. Documented by [[Testing]] and [[BugsAndFeatureRequests]] * Post-release testing: Run or install Fedora 9 or 10 and report bugs either as you find them spontaneously or while intentionally testing a particular component. * Update pre-release testing: Run newly-built software from the Fedora 9 or 10 updates-testing repositories and report problems or approval for general public release in Bodhi. * Rawhide testing: Run or install Fedora 11 Rawhide (updated daily) and report bugs as you find them spontaneously or while intentionally testing a particular component. Systematic QA: * Re-testing on request: Test bugs labelled NeedsRetesting. * Systematic manual testing: Use one of the test plans listed at [[QA/TestPlans]] to perform a specific list of tasks and report any bugs found. Especially important when alpha, beta, and release candidate installers are released. * Semi-automated testing: Run QA scripts and file problems in Bugzilla. * Develop automated and semi-automated tools for QA testing - see [[Beaker]], [[Automated QA Testing Project]], etc. Events: * [[QA/Test Days]] Documented in other SIGs: * Font testing * Documentation testing * etc... I'm not sure that "Stream Liasion" as described in the Leam draft is distinct from these processes, since there are a variety of reasons to engage in testing, and different people will naturally focus on different components. I assume Adam is taking the lead on updating the main QA wiki pages, so I haven't implemented these suggestions myself (and I didn't feel comfortable doing so unilaterally). I found these pages: https://fedoraproject.org/wiki/Testing https://fedoraproject.org/wiki/BugsAndFeatureRequests exceedingly useful in answering questions that testers like me have, such as, "when should I use the mailing list vs. filing a bug report" and "what should I put in reports for this type of bug"? Just now, I signed up for an account and did some tidying up to make these pages clearer. There is still plenty of room for improvement. I encourage other testers to read these pages if they haven't already, and encourage everyone to make additions, especially of the type "If you have a bug of type X, try doing Y yourself to diagnose the problem before reporting it." -- Beland -- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
