On Mon, 2009-02-09 at 01:17 +0530, Rahul Sundaram wrote: > http://fedoraproject.org/wiki/QA/ReleaseCriteria I'm of the mindset that QA should not solely define the release criteria. Defining what a release should be must be a collaborative decision. Perhaps the above link is something that each team provides *minimal* content for and FESCO reviews/approves? QA can then taylor testing around what expectations the development teams are setting along with the approved release criteria. Should all this data eventually land in each test plan as 'exit criteria'? I'd love to see a world where each test team defines their exit criteria for testing. I find it difficult to fill a single document with absolutes that properly apply to all levels of testing throughout the operating system. Success for the Fingerprint feature will look much different than success for KDE4.2 and kernel. That doesn't mean that QA cannot or should not be involved in deciding whether something blocks the release. I wonder if the release blocking decision could be more collaborative? The issues should be flagged/raised/escalated appropriately along with a basic risk assessment (e.g. users will not be able to run 'yum update'). This raises some questions for me ... * How to assign defect severity? # should we bother? * When to escalate a defect? * How to escalate a defect? Thanks, James > Is this, currently, the case? If not, what is the release-critical > process? What do you guys think about this? Should we have a process? > Should it be as I described? Who should be in charge? (I would say > -bugzappers). Thanks, James
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
