Christopher Beland wrote:
An introduction would be nice.
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:
This is the official one
http://fedoraproject.org/wiki/QA
This is the approved replacement
http://fedoraproject.org/wiki/User:Johannbg/Draft/QA
This is a new idea.
https://fedoraproject.org/wiki/User:Leam
And if i'm not mistake this is old one from moin?
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.
Leam's page is to formal seems more directed at QE' s then an new linux
user
that might have the dream or just wanting to try out testing or triaging
Any mention on certification a degree in any form or way or reference to
coding
and from my perspective my scare people away instead of encourage them
to 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.
There already is work in creating a QA joining page
( which is missing from the http://fedoraproject.org/en/join-fedora )
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.
Well you clearly did not understand this page correctly which just means
I failed my task
and need rewrite the whole thing again.
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).
The process so far is that people create drafts then they are review and
the community reaches
conscious.
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.
Do not edit the official wiki pages directly and if you did either on
those you mentioned
and potentially any others that you might have made some changes to
please revert those changes asap.
You might upset a lot of people of if you altered any of the official
wiki pages
JBG.
--
fedora-test-list mailing list
fedora-test-list@xxxxxxxxxx
To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-test-list
