From Fedora Project Wiki

(Corrected some links to point to our articles)
(Cleaned up a few links)
Line 1: Line 1:
{{Draft}}
{{Draft}}


A '''proven tester''', also known as a '''critical path wrangler''', verifies and reports on the stability of test updates to [[critical path packages]]. They retrieve their updates from the [[QA/Updates_Testing|updates-testing]] repository and report their findings as karma using [[Bodhi]]. Positive karma from a proven tester is required for each critical path update before it can be pushed to the stable repository.
A '''proven tester''', also known as a '''critical path wrangler''', verifies and reports on the stability of test updates to [[critical path package]]s. They retrieve their updates from the [[updates-testing]] repository and report their findings as karma using [[Bodhi]]. Positive karma from a proven tester is required for each critical path update before it can be pushed to the stable repository.


Individuals must must be mentored and approved before becoming proven testers. A proven tester is a member of the [https://admin.fedoraproject.org/accounts/group/view/proventesters proventesters] group.
Individuals must must be mentored and approved before becoming proven testers. A proven tester is a member of the [https://admin.fedoraproject.org/accounts/group/view/proventesters proventesters] group.
Line 8: Line 8:
Proven testers verify a basic level of stability before releasing an update to the public. They do not need to test for total correctness or ensure complete test coverage. Some tests will vary depending on the type of the package, while others must pass for all updates. Generally speaking, an update should successfully execute all applicable [[critical path action]]s. The [[Fedora release criteria]] is another useful guide for minimum testing criteria.
Proven testers verify a basic level of stability before releasing an update to the public. They do not need to test for total correctness or ensure complete test coverage. Some tests will vary depending on the type of the package, while others must pass for all updates. Generally speaking, an update should successfully execute all applicable [[critical path action]]s. The [[Fedora release criteria]] is another useful guide for minimum testing criteria.


Proven testers verify updates by installing them from the ''updates-testing'' repository. To ensure rapid detection of regressions, a full system update from this repository should be performed at least once a day. Individual packages may be updated more quickly if the need for verification is urgent.
Proven testers verify updates by installing them from the updates-testing repository. To ensure rapid detection of regressions, a full system update from this repository should be performed at least once a day. Individual packages may be updated more quickly if the need for verification is urgent.


=== General Tests ===
=== General Tests ===
Line 38: Line 38:
== External Links ==
== External Links ==
* [http://bodhi.fedoraproject.org Bodhi]
* [http://bodhi.fedoraproject.org Bodhi]
* [http://redhat.bugzilla.com Fedora Bugzilla]
* [http://redhat.bugzilla.com Bugzilla]

Revision as of 23:04, 21 June 2010

This page is a draft only
It is still under construction and content may change. Do not rely on the information on this page.

A proven tester, also known as a critical path wrangler, verifies and reports on the stability of test updates to critical path packages. They retrieve their updates from the updates-testing repository and report their findings as karma using Bodhi. Positive karma from a proven tester is required for each critical path update before it can be pushed to the stable repository.

Individuals must must be mentored and approved before becoming proven testers. A proven tester is a member of the proventesters group.

Testing Updates

Proven testers verify a basic level of stability before releasing an update to the public. They do not need to test for total correctness or ensure complete test coverage. Some tests will vary depending on the type of the package, while others must pass for all updates. Generally speaking, an update should successfully execute all applicable critical path actions. The Fedora release criteria is another useful guide for minimum testing criteria.

Proven testers verify updates by installing them from the updates-testing repository. To ensure rapid detection of regressions, a full system update from this repository should be performed at least once a day. Individual packages may be updated more quickly if the need for verification is urgent.

General Tests

  1. The system must be able to shut down and reboot.
  2. The user must be able to log in to the desktop.
  3. The user must be able to access the network.

Testing Applications

If the package is an application, run the application and check that basic operations work.

Testing Libraries and Shared Components

If it is a library or other shared component, run an application which uses the component and ensure that that works.

Feedback Procedures

Since a proven tester's karma determines whether an update is allowed to be promoted, they follow special procedures based on the severity of regressions they encounter. Use fedora-easy-karma to list all installed packages from the updates-testing repository and allow to file feedback on each one at a time. Pay particular attention to updates whose description notes that they are critical path updates.

Major bugs

If you identified any serious problems in earlier testing and were able to identify the package responsible, post negative feedback for that package. If possible, please file a bug report on the problem and link to the bug report in your feedback message. A good feedback message quickly and clearly identifies the behavior change and the cause, if you were able to determine it.

Minor bugs

If you identify a problem which is minor in nature and does not impede the actual critical path functionality, please do not post negative feedback. Post neutral or positive feedback with a note of the issue encountered (and a link to a bug report if appropriate).

Previously reported bugs

If your testing uncovers no problems but you see that another tester has identified a serious problem with the package, please try to replicate their problem, and post negative feedback if you are now able to confirm it. If you are not able to confirm the problem but you suspect this may be because you cannot recreate the necessary conditions, please post neutral feedback noting that you were unable to duplicate the problem. Only post positive feedback if you are sure your testing indicates the other reporter's negative feedback is a mistake.

Unfamiliar packages

If you are not sure what the component does or how to test it, do not post positive or negative feedback. If the above general tests of booting, network functionality and update functionality identified no problems, it is fine to leave a neutral feedback message noting that you were able to boot the system and perform critical path tasks with the update installed.

External Links