On Mon, Nov 26, 2012 at 10:50 AM, luis kantun <[email protected]> wrote: > Hi, I'm new to the area I'm currently in QA reading User Guides. It would > help if I could provide a little more information about the mentioned point > 1 on the familiarization with the new voluntrios bugzilla. as I think that > would be the area where I would focus. >
Hi Luis, So the first thing you'll want to do is sign up for a Bugzilla account here: https://issues.apache.org/ooo/createaccount.cgi Once you've done that let me know what your account name is (email address you registered with). I'll then give you additional permissions in Bugzilla to edit defect reports. Then take a look at these flow charts: http://www.openoffice.org/qa/issue_handling/workflowcharts/defect_triaging.pdf The flow chart on the first page is the general workflow for newly reported bugs. They come in in rough shape sometimes. The description can be unclear. They can be misclassified. They may be duplicates of another bug. They might be missing steps. Some are old reports where the bug is already fixed. The triage process is how we sort through this raw input and close out the invalid reports, and prioritize the good ones and send them to the developers for fixing. We have many unconfirmed bugs in the database. One approach is to do a query for interesting ones and focus on those. For example, I might feel like testing spreadsheet editing bugs on Windows. I define that as an advanced query, and see these 7 unconfirmed bugs: https://issues.apache.org/ooo/buglist.cgi?resolution=---&op_sys=Windows%2C%20all&query_format=advanced&bug_status=UNCONFIRMED&component=editing&product=spreadsheet Personally, I think this is the easiest way, since I can do an entire session in one application on one platform. Regards, -Rob > regards > > > 2012/11/25 Rob Weir <[email protected]> > >> If you are following the Dev mailing list you see that there is >> discussion about the next major release, Apache OpenOffice 4.0, with >> proposed ship dates in the March/April time frame. We should discuss >> a QA Plan for that release. My apologies in advance if this is >> already written down someplace. >> >> My proposal: >> >> The major QA activities between now and the release of 4.0 should be: >> >> 1) Ongoing work to review incoming defect reports from users of AOO >> 3.4.1 and earlier releases. Attempt verification and set severity and >> priority appropriately. We should probably have 2-3 volunteers >> focusing on this. This is a great task for new volunteers since it >> helps them gain familiarity with OpenOffice and Bugzilla. >> >> 2) Follow closely the design discussions related to new 4.0 features. >> They are listed on the Wiki (still evolving): >> >> https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Planning >> . >> We need to figure out how we will test these new features. We need >> a test plan for new features so we can execute on the testing quickly >> once the code is ready to test. >> >> 3) We need to maintain and enhance a "smoke test" that can be run >> frequently (ideally on every build) to verify that it is not broken. >> This should be an automated test that can run in an hour or two. The >> goal here is to catch new defects very early. >> >> 4) We need to maintain and enhance a "regression test suite" of manual >> and/or automated test cases that thoroughly test all functions of the >> product (ideally). Depending on how many volunteers are working on >> this, a full regression test pass might take a week or more. >> >> 5) Once "feature freeze" arrives (when all new features are >> implemented) we need to execute regression tests and new feature >> tests. Depending on how many bugs are found and their severity, this >> might require iteration. In other words, we might need to run two >> test passes before we're confident we've reached a sufficient quality >> level to release. Maybe we just plan for two passes? >> >> We also know that releasing is a week long process of voting on a >> Release Candidate, updating the website, etc. >> >> So working backwards, a schedule might look like this: >> >> March 8th : Feature Freeze -- all new features are testable >> >> March 11th-18th: First full test pass (regression and new feature) >> >> March 30th: Translation Freeze (all new translation work done) >> >> April 1st-8th: Second full test pass (regression and new feature) >> >> April 15th: Release Candidate build available, final verification of fixes >> occur >> >> April 22nd: Release Vote starts >> >> April 29th: Release announcement >> >> This is assuming we have enough volunteers that we can do a full test >> pass in one week. Let's aim for that. And the whole schedule can >> move depending on when the developers actually reach feature freeze. >> >> The above suggests that QA is working in two phases: Phase I is >> before feature freeze. In that time we're focused on processing 3.4.1 >> defect reports and preparing for the AOO 4.0 test passes. And Phase >> II comes in March when feature freeze is hit, when we have 4 or 5 >> weeks of intense work to test the AOO 4.0 builds. >> >> >> Regards, >> >> -Rob >>
