#268: asking to join the proven testers and requesting a mentor
------------------------------------------+-----------------
Reporter: arifiauo | Owner:
Type: proventester request | Status: new
Priority: major | Milestone:
Component: Proventester Mentor Request | Version:
Resolution: | Keywords:
Blocked By: | Blocking:
------------------------------------------+-----------------
Comment (by mcloaked):
When you originally stated in your first entry to this ticket that "I also
have read and understand how the process of testing" - I believed that you
had indeed read the details in the provestester wiki entry at:
http://fedoraproject.org/wiki/Proven_tester
In that web page it states:
"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 - see the page for
instructions on installing and using this tool - to list all installed
packages from the updates-testing repository and allow to file feedback on
each one at a time. Note that you can use the parameter --critpath-only,
which will cause f-e-k to list only unapproved critical path updates, if
you are short on time for testing. If you do not use this parameter, pay
particular attention to updates whose description notes that they are
critical path updates.
Positive feedback
Usually, you will be able to post positive feedback on an update. If you
do not encounter any of the situations below, and find that the update
passes the tests mentioned above and does not cause you any other
problems, you should leave positive feedback and note that you were able
to use the package successfully and did not notice any significant
problems.
Major bugs
If you identified any serious problems in your testing and were able to
identify the update responsible, post negative feedback for that update.
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.
Update does not fix a bug it claims to
If you find an update does not fix a bug it claims to fix, this is not
usually a case where you should file negative karma. Only file negative
karma if that is the only change in the update. If an update claims to fix
five bugs, but only fixes four of them, it is not helpful to post negative
karma as this may result in the update being rejected, which does not help
those suffering from the bug that wasn't fixed, and hurts those suffering
from the bugs that are fixed. When you test an update that claims to fix a
particular bug and doesn't, but does not have any of the issues listed as
meriting negative or neutral feedback above, please leave positive
feedback with a note that the bug in question is not fixed, or neutral
feedback with such a note if the issue prevents you from otherwise
properly testing the update.
Update does not fix a bug it does not claim to
Please do not leave negative feedback on an update simply because it does
not fix a bug that also existed prior to the update, and which the update
does not claim to fix. Doing so serves no purpose: preventing the update
from being released doesn't help you when the already-released version of
the package also has the bug. In this case, making it harder for the
update to be approved only serves to prevent other users from getting the
fixes for their bugs.
Unfamiliar packages
If you are not sure what the component does or how to test it, do not post
positive or negative feedback. For critical path updates, 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. This is generally not useful for non-
critical path updates, however: please only comment on them if you are
familiar with the package and able to test it directly."
Please will you make sure that you indeed have read this properly and
apply any comments to testing according to these guidelines.
When you test a package you should install it - and then check whenever
possible whether any bugs that were reported to be fixed are indeed fixed
in your own test system. Please also ensure that you run a package for
long enough that no new bugs appear in the system after the package has
been installed.
It is also useful for some packages to say whether you are using x86 or
x86_64 since in some cases bugs were only reported for one architecture.
In general for unfamiliar packages note the guidance that "For critical
path updates, 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." - on other words
if you have not done detailed tests but your system runs with no apparent
regressions then say so and give neutral karma, not +1.
I think it would be appreciated by testers and developers if you stick
within these published guidelines, and I am repeating these here as your
mentor.
I will look forward to more useful comments and appropriate karma in your
bodhi comments from now on, and I hope these suggestions will be helpful
in your further testing as a proventester.
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/268#comment:9>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
--
test mailing list
test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
