You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@openoffice.apache.org by bu...@apache.org on 2013/02/07 19:19:37 UTC

svn commit: r849792 - in /websites/staging/openoffice/trunk/content: ./ orientation/intro-qa.html

Author: buildbot
Date: Thu Feb  7 18:19:36 2013
New Revision: 849792

Log:
Staging update by buildbot for openoffice

Modified:
    websites/staging/openoffice/trunk/content/   (props changed)
    websites/staging/openoffice/trunk/content/orientation/intro-qa.html

Propchange: websites/staging/openoffice/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Thu Feb  7 18:19:36 2013
@@ -1 +1 @@
-1442795
+1443641

Modified: websites/staging/openoffice/trunk/content/orientation/intro-qa.html
==============================================================================
--- websites/staging/openoffice/trunk/content/orientation/intro-qa.html (original)
+++ websites/staging/openoffice/trunk/content/orientation/intro-qa.html Thu Feb  7 18:19:36 2013
@@ -216,59 +216,73 @@ generally every few weeks, are built in 
 <p>Everyone in QA needs a Bugzilla account, which you can get <a href="https://issues.apache.org/ooo/createaccount.cgi">here</a>.  Once 
 you have a Bugzilla account, you should send a note to the QA list asking to be added to the QA role in 
 Bugzilla.  This will give you some additional permissions in Bugzilla.  Include your Bugzilla login ID in your request.</p>
-<h2 id="easy-qa-tasks">Easy QA Tasks</h2>
-<p>The easiest tasks for a new QA Volunteer are:</p>
-<ul>
-<li>Verify bug fixes.  This helps you gain familiarity with the OpenOffice product, and our process.  This 
-verification is also very important, since some bug fixes either fail to fix the bug, or cause
-a new bug.</li>
-<li>Confirm new defect reports.   You review incoming defect reports, often from users and not very clearly written.
-You learn to "read between the lines" and fill in missing steps to turn the raw report into a reproducible
-defect that the developers can debug and fix.</li>
-<li>Manual testing.  This gains you further familiarity with QA process, by executing pre-defined test cases and
-writing up defect reports for any new defects found</li>
-<li>Writing new test cases.  This is a more advanced topic, but after mastery of the above two steps, and learning
-to "think like a bug", you will be ready for this.</li>
-</ul>
-<h3 id="verifying-fixed-defects">Verifying Fixed Defects</h3>
-<p>You can get resolved bug list from this query: <a href="https://issues.apache.org/ooo/buglist.cgi?cmdtype=dorem&amp;remaction=run&amp;namedcmd=Fixed_After_340&amp;sharer_id=248432">All fixed bugs after AOO 3.4 release</a></p>
+<h2 id="easy-qa-task-confirm-new-defect-reports">Easy QA Task: Confirm New Defect Reports</h2>
+<p>Most new volunteers start by reviewing incoming defect reports and attempting to "confirm" them.   The defect reports are 
+often from users and are often not very clearly written.  You learn to "read between the lines" and ask the user clarifying questions
+in order to turn the raw report into a reproducible defect that the developers can debug and fix.</p>
+<p>You can get a list of unconfirmed defect reports with from <a href="https://issues.apache.org/ooo/buglist.cgi?bug_status=UNCONFIRMED&amp;f2=keywords&amp;f3=cf_bug_type&amp;known_name=NeedConfirm&amp;list_id=39759&amp;o2=notsubstring&amp;o3=equals&amp;query_format=advanced&amp;resolution=---&amp;v2=needmoreinfo&amp;v3=DEFECT&amp;order=bug_id%20DESC&amp;query_based_on=NeedConfirm">this query</a>.</p>
+<p>Or, if you are just starting out, you can post a note to the QA mailing list and ask for a small batch of reports to be assigned to you.  This can be a good first
+step, since we'll try to give you easier reports to review at first.</p>
+<p>Here's what to do to confirm a new defect report:</p>
+<ol>
+<li>First, assign the report to yourself by setting your Bugzilla username (your email address) in the "QA Contact" field.</li>
+<li>Then read over the report.  What are they really saying?  Are the reporting a bug?  Asking for a new feature?  Asking a support question?  Just because it is in Bugzilla
+ does not mean that it is a defect report.<br />
+</li>
+<li>Ask yourself:  Are they saying that something is working incorrectly?  Or are they asking for new functionality?
+If they are asking for a new feature, change the Issue Type field to "FEATURE".  If they are asking for an enhancement of an existing feature, set the Issue Type field to "ENHANCEMENT".
+You can now set the Status to CONFIRMED and then save your changes.  You are done with the report.<br />
+</li>
+<li>Search Bugzilla to see if this is a duplicate defect report.  If it is, change the Status to RESOLVED, DUPLICATE and type in the defect number that this report is a duplicate of.<br />
+ You are now done with this report.<ol>
+<li>If the report is actually reporting a defect, then you have more work to do.  Try to reproduce it with the latest release of OpenOffice. If you can reproduce the defect, 
+ set the Status to CONFIRMED, set the "Last Confirmation" field to the release that you tested with, and set the Importance field to an appropriate value, depending on the severity 
+ of the defect.</li>
+<li>If the report is not clear enough to reproduce, enter a comment asking the user for more information and add "needmoreinfo" to the Keyword field. Be specific about what information
+ you need:  more detailed steps, a test document, clarification about what version they are running, etc.  When the user responds you will be copied on 
+ their response and can continue with this report.  But for now you are done with this report.</li>
+<li>If you testing cannot reproduce the bug, and you <em>do not</em> need more information from the user, then change the status to RESOLVED/IRREPRODUCIBLE.</li>
+<li>If the user was confused, did not understand the functionality, was asking a support question, etc., then point them to the <a href="http://forum.openoffice.org">Community Support Forums</a>
+ and mark the issue as RESOLVED/INVALID.  Of course, you can help if it is a simple question, but the forums are the better place for a user to find help.  Bugzilla is not for 
+ support.  It is for reporting bugs.</li>
+</ol>
+</li>
+</ol>
+<p>Note: Once you have reviewed a bug report, it should only be left in the UNCONFIRMED state if you are waiting for more information from the user, in which case you should also
+set the "needsmoreinfo" value into the Keyword field.  In all other cases you should push the report forward to a new status, either CONFIRMED, RESOLVED/IRREPRODUCIBLE,
+RESOLVED/INVALID or RESOLVED/DUPLICATE, or by changing the Issue Type to FEATURE or ENHANCEMENT.</p>
+<p>Also, it is a judgement call on whether to immediately mark an issue RESOLVED/IRREPRODUCIBLE or to send the user a question and wait for a response. </p>
+<p>An intermediate approach, when confirming defects report written against older versions of OpenOffice, is to mark the bug as RESOLVED/IRREPRODUCIBLE and at the same time add a 
+comment saying, "I was not able to confirm the bug given these steps in the current version of OpenOffice (AOO 3.4.1), so I'm closing this report.  If you are still seeing this 
+problem after upgrading to AOO 3.4.1 please post the details and we can reopen the report".</p>
+<p>Finally, think of the confirmation process as the opportunity for the QA Team to improve the value of information we receive from users.  We're taking the raw bug reports,
+sorting through them, eliminating the ones that do not report new bugs, and then passing on the good ones to the programmers.  So anything you can do to improve the quality
+of the incoming defect reports will help.  This includes clarifying the steps needed to reproduce the problem, attaching sample documents that you might create to reproduce the
+problem, improving report titles to make them more accurate/relevant to the real issue, correcting classifications and adjusting defect priorities.</p>
+<h2 id="easy-qa-task-verifying-fixed-defects">Easy QA Task: Verifying Fixed Defects</h2>
+<p>Verifying bug fixes (re-testing a bug report after a developer has fixed it) is also very important, since some bug fixes either fail to fix the bug, or cause
+a new bug.</p>
+<p>You can get a list of fixed bugs from this query: <a href="https://issues.apache.org/ooo/buglist.cgi?cmdtype=dorem&amp;remaction=run&amp;namedcmd=Fixed_After_340&amp;sharer_id=248432">All fixed bugs after AOO 3.4 release</a></p>
 <p>Select the bug you want to verify:</p>
 <ol>
-<li>First you need to understand which fault does the defect report is referring to.</li>
+<li>First you need to understand which problem the defect report is referring to.</li>
 <li>Install the latest build.</li>
 <li>Follow the steps to reproduce and check to see if the defect has been fixed.</li>
 <li>Add additional comments to the bug with your test result. e.g. build revision number, platform you have been tested etc.</li>
 <li>"Test around" the bug to make sure that nothing was broken when fixing it.  You will develop and intuition for
 this as you learn to "think like a bug".</li>
-<li>Change defect status to "Verified" (this action requires "CanEdit" privilege" in Bugzilla system, if you cannot do that then send mail to mailing list and ask other QA do this for you.)</li>
-</ol>
-<h3 id="confirm-new-defect-reports">Confirm New Defect Reports</h3>
-<p>You can get a list of unconfirmed defect reports with from <a href="https://issues.apache.org/ooo/buglist.cgi?bug_status=UNCONFIRMED&amp;f2=keywords&amp;f3=cf_bug_type&amp;known_name=NeedConfirm&amp;list_id=39759&amp;o2=notsubstring&amp;o3=equals&amp;query_format=advanced&amp;resolution=---&amp;v2=needmoreinfo&amp;v3=DEFECT&amp;order=bug_id%20DESC&amp;query_based_on=NeedConfirm">this query</a>.</p>
-<p>Select the report you want to confirm:</p>
-<ol>
-<li>Incoming reports could be from other project members, from power users or from new users.   Some might not
-even be real defect reports.  It might be a support question or a request for a new feature.  So your first
-task is to do determine what you really have here. </li>
-<li>Ask yourself:  Are they saying that something is working incorrectly?  Or are they asking for new functionality?
-If they are asking for a new feature, change the Issue Type field to "FEATURE".  You are now done with that report.</li>
-<li>Search Bugzilla to see if this is a duplicate defect report.  If it is, change the Status to Resolved, Duplicate
-and type in the defect number that this report is a duplicate of.  You are now done with this report.</li>
-<li>If the report is reporting a defect, try to reproduce it with the latest release of OpenOffice.  If the report
-is not clear enough to reproduce, enter a comment asking for more information and add the "needmoreinfo" keyword.<br />
-When the user responds you will be copied on their response and can continue with this report.  But for now you
-are done with this report.</li>
-<li>If you can reproduce the defect, set the status to CONFIRMED, set the "Last Confirmation" field to the 
-release that you tested with, and set the Importance field to an appropriate value, depending on the severity
-of the defect.</li>
-<li>If you cannot confirm the bug, and the bug report was clear, then change the status to RESOLVED/IRREPRODUCIBLE.</li>
+<li>Change defect status to "Verified" </li>
 </ol>
-<h3 id="manual-testing">Manual Testing</h3>
+<h2 id="easy-qa-task-manual-testing">Easy QA Task: Manual Testing</h2>
+<p>Manual testing gains you further familiarity with QA process, by executing pre-defined test cases and
+writing up defect reports for any new defects found</p>
 <p>To get more familiar with AOO, now you can try to perform some manual test cases.</p>
 <ul>
 <li>Browse test management tool, <a href="http://aootesting.adfinis-sygroup.org">Testlink</a> to find available test cases.<br></li>
 <li>Read this guide if you are not familiar with Testlink tool. <a href="http://wiki.openoffice.org/wiki/QA/Testlink">Testlink usage guide</a></li>
 </ul>
-<h3 id="test-case-authoring">Test Case Authoring</h3>
+<h2 id="easy-qa-task-test-case-authoring">: Easy QA Task: Test Case Authoring</h2>
+<p>This is a more advanced topic, but after mastery of the above two steps, and learning to "think like a bug", you will be ready for this.</p>
 <p>After some practice on test case execution, now you can start writing new test cases.</p>
 <p>Useful guide for writing manual test cases:</p>
 <ul>
@@ -277,8 +291,8 @@ of the defect.</li>
 </ul>
 <h2 id="module-completion">Module Completion</h2>
 <p>Once you have done the above, go to our our <a href="https://cwiki.apache.org/confluence/display/OOOUSERS/Directory+of+Volunteers">Directory of Volunteers</a> wiki page and add or update your 
-information.  Congratulations!  Please send a note to <a href="mailto:qa@openoffice.apache.org?subject=Completed Introduction to QA">qa@openoffice.apache.org</a> 
-so we know.</p>
+information.  Also, add an entry for yourself to the <a href="https://cwiki.apache.org/confluence/display/OOOUSERS/QA+Testing+Preferences">QA Testing Preferences</a> page. Congratulations!<br />
+Please send a note to <a href="mailto:qa@openoffice.apache.org?subject=Completed Introduction to QA">qa@openoffice.apache.org</a> so we know.</p>
   </div>
 
   <div id="footera">