From Fedora Project Wiki
(New page: = Quality Assurance = == Summary == Bringing current QA project to [ http://en.wikipedia.org/wiki/Software_Quality_Assurance SQA ] == Owner == * Name: [[User:Johannbg| Jóhann Benedi...)
 
No edit summary
 
(4 intermediate revisions by the same user not shown)
Line 3: Line 3:


== Summary ==
== Summary ==
Bringing current QA project to [ http://en.wikipedia.org/wiki/Software_Quality_Assurance SQA ]  
Bringing current QA project to [http://en.wikipedia.org/wiki/Software_Quality_Assurance SQA]  


== Owner ==
== Owner ==
Line 23: Line 23:


'''SQC'''
'''SQC'''
Oh great time out in the wiki on what I had written teaches me to save more often.
Here's sum of what I had written hit me with questions and I will answer... 


* Improving documentation on the wiki
* Improving documentation on the wiki
( How to etc )
* Create a calender on the wiki which project assign them self to a certain time slots and what to test
* Create a calender on the wiki which project assign them self to a certain time slots and what to test  
( Takes test days to next level ). 
* Build an automated test system.
* Build an automated test system.
* Increase communication with testers.
* Build a better/more active test community.
( Meetings agenda for example etc. )
* Get developers to redirect test traffic from the devel-list to the test-list
* Get developers to redirect test traffic from the devel-list to the test-list
* Get Gnome/KDE/XFCE etc to have something like properties item which would show what's being executed and perhaps
to which package it belongs to get correcter bug reports.
* Create each listen "component" in bugzilla to have it's own wiki page with relevant info on debuging testing etc see
[[Anaconda|Anaconda]] for example. VERY VITAL THAT THIS IS ACHIEVED.
* and more...


== Benefit to Fedora ==


== Benefit to Fedora ==
*Improved Documentation
<!-- What is the benefit to the platform?  If this is a major capability update, what has changed?  If this is a new feature, what capabilities does it bring? Why will Fedora become a better distribution or project because of this feature?-->
*Proper QA process
*Better bug reports
*Better testing.
*Easier triaging


== Scope ==
== Scope ==
<!-- What work do the developers have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
 
Requires Developers/maintainers of listed components in bugzilla to create or assist in creating its own wiki page.


== Test Plan ==
== Test Plan ==
<!-- This does not need to be a full-fledged document.  Describe the dimensions of tests that this feature is expected to pass when it is done.  If it needs to be tested with different hardware or software configurations, indicate them.  The QA team will turn this information into a more complete test plan.  The more specific you can be, the better the final test plan will be.


A good Test Plan should answer these four questions:
This is mostly wiki add-ons/changes.
There will be some RFE that can be tested if they are accepted by upstream...


0. What special hardware / data / etc. is needed (if any)?
== User Experience ==
1. How do you prepare your system to test this feature? What packages
need to be installed, config files edited, etc.?
2. What specific actions do you perform to check that the feature is
working like it's supposed to?
3. What are the expected results of those actions?


-->
The project itself will get a more professional QA.
Developers will get better bug reports.
Tester will learn more.


== User Experience ==
== Dependencies ==
<!-- If this feature is noticeable by its target audience, how will their experiences change as a result?  Describe what they will see or notice. -->


== Dependencies ==
Depends highly on each bugzilla component has it wiki page..
<!-- What other packages (RPMs) depend on this package?  Are there changes outside the developers' control on which completion of this feature depends?  In other words, completion of another feature owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate?  Other upstream projects like the kernel (if this is not a kernel feature)? -->


== Contingency Plan ==
== Contingency Plan ==
Line 79: Line 85:
----
----


[[Category:FeaturePageIncomplete]]
[[Category:ProposedFeature]]
<!-- When your feature page is completed and ready for review -->
<!-- When your feature page is completed and ready for review -->
<!-- remove Category:FeaturePageIncomplete and change it to Category:FeatureReadyForWrangler -->
<!-- remove Category:FeaturePageIncomplete and change it to Category:FeatureReadyForWrangler -->
<!-- After review, the feature wrangler will move your page to Category:FeatureReadyForFesco... if it still needs more work it will move back to Category:FeaturePageIncomplete-->
<!-- After review, the feature wrangler will move your page to Category:FeatureReadyForFesco... if it still needs more work it will move back to Category:FeaturePageIncomplete-->
<!-- A pretty picture of the page category usage is at: https://fedoraproject.org/wiki/Features/Policy/Process -->
<!-- A pretty picture of the page category usage is at: https://fedoraproject.org/wiki/Features/Policy/Process -->

Latest revision as of 18:21, 4 November 2008

Quality Assurance

Summary

Bringing current QA project to SQA

Owner

Current status

  • Targeted release: Fedora 11
  • Last updated: 2008-11-04
  • Percentage of completion: 01%

Detailed Description

QA

  • Creation of QA board which would be elected or otherwise selected individuals from each "sub project"
  • Fesco could be that board.

SQC

Oh great time out in the wiki on what I had written teaches me to save more often.

Here's sum of what I had written hit me with questions and I will answer...

  • Improving documentation on the wiki
  • Create a calender on the wiki which project assign them self to a certain time slots and what to test
  • Build an automated test system.
  • Build a better/more active test community.
  • Get developers to redirect test traffic from the devel-list to the test-list
  • Get Gnome/KDE/XFCE etc to have something like properties item which would show what's being executed and perhaps

to which package it belongs to get correcter bug reports.

  • Create each listen "component" in bugzilla to have it's own wiki page with relevant info on debuging testing etc see

Anaconda for example. VERY VITAL THAT THIS IS ACHIEVED.

  • and more...

Benefit to Fedora

  • Improved Documentation
  • Proper QA process
  • Better bug reports
  • Better testing.
  • Easier triaging

Scope

Requires Developers/maintainers of listed components in bugzilla to create or assist in creating its own wiki page.

Test Plan

This is mostly wiki add-ons/changes. There will be some RFE that can be tested if they are accepted by upstream...

User Experience

The project itself will get a more professional QA. Developers will get better bug reports. Tester will learn more.

Dependencies

Depends highly on each bugzilla component has it wiki page..

Contingency Plan

Keep the process as is...

Documentation

QA Will hold the new QA wikipage along with it sub pages.. Hack at will...


Release Notes

Comments and Discussion

Retrieved from "https://fedoraproject.org/w/index.php?title=Features/QA&oldid=57966"