Re: [Bugzilla] Please add version 4.1.2 to Target field
On Wed, Jan 28, 2015 at 2:52 AM, Herbert Duerr h...@apache.org wrote: On 27.01.2015 21:39, Rob Weir wrote: On Sun, Jan 25, 2015 at 5:20 PM, Andrea Pescetti pesce...@apache.org wrote: Resending again with modified subject line. Bugzilla admins, if you need more admins in the team just call for help. Thanks, Andrea. Based on past pattern, we'd add 4.1.2-dev now, and 4.1.2 once that version has released, yes? For the target field we should use the version on the horizon (i.e. 4.1.2) and for the version field the versions where new bug reports are useful (i.e. 4.1.2-dev). Great. It looks like you (or someone else) added these value, yes? I've also added a 4.1.2 Release Blocker flag, so we're set with that also. -Rob Herbert - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: how to close a non-recommended ENHACEMENT issue?
On Tue, Jan 27, 2015 at 5:27 PM, Kay Schenk kay.sch...@gmail.com wrote: What is the procedure for closing an ENHANCEMENT issue when the enhancement is not recommended? IMHO, the set of all open ENHANCEMENT issues comprise a wish list which volunteer developers are welcome to dip into if they want. We will always have more such enhancement requests than we can address. This is true of every project. Only a dead project has no more ideas for enhancement, But if an idea is objectively bad then we should probably close it. For example, if it would break a standard, break another feature, perhaps if it is redundant, etc. I recall reading about a survey Microsoft did of Office 2003 users, asking them what features they wanted added to Office. When the survey results were tallied they found that many of the feature requests were already in the product, but hard to find. Does this make sense? Just because no one has implemented a feature yet does not mean the idea is a bad one. Regards, -Rob See issue 125954 as an example -- https://issues.apache.org/ooo/show_bug.cgi?id=125954 So far I have found 6919 issues for ENHANCEMENTS regardless of status. None of them are RESOLVED, so my assumption is that a negative recommendation doesn't get any special status handling. Should we make an attempt to go through the old ENHANCEMENT/FEATURE issues and see if we can finalize the ones that have been turned down by some means -- RESOLVED/NOT AN ISSUE -- or ?? -- - MzK An old horse for a long, hard road, a young pony for a quick ride. -- Texas Bix Bender - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: to get bug repositories
On Fri, Oct 3, 2014 at 7:56 AM, Andrea Pescetti pesce...@apache.org wrote: On 03/10/2014 dhyanendra singh wrote: i have created an account with username singh.cs@gmail.com mailto:singh.cs@gmail.com at https://issues.apache.org/ooo/ as you suggested. now tell me how can get access to the repositories. What do you need exactly? You already have access to all bugs by registering (I mean: from the website you can access every bug and make queries). Do you want to be able to download the full Bugzilla database as one file? In that case, what information can be anonymized? I'm not sure this can be done and for sure I can't do it since I don't have the required permissions, but if the request is clear we can investigate and see what's possible. As Andrea mentions we're unlikely to give you a copy of the underlying Bugzilla database, since that has personal information like login records, hashed passwords, email addresses, etc. However, in addition to browsing Bugzilla through the UI there is also a REST API that you can call to extract BZ records in XML format. This makes it easier (assuming you can do some simple scripting to process the XML) to automate some analysis. For example, to retrieve issue number 60129 you would make this request: https://issues.apache.org/ooo/show_bug.cgi?ctype=xmlid=60129 And you would receive back this XML: ?xml version=1.0 encoding=UTF-8 standalone=yes ? !DOCTYPE bugzilla SYSTEM https://issues.apache.org/ooo/page.cgi?id=bugzilla.dtd; bugzilla version=4.4.1 urlbase=https://issues.apache.org/ooo/; maintainer=aoo-bugzilla-ad...@apache.org bug bug_id60129/bug_id creation_ts2006-01-06 12:51:00 +/creation_ts short_descinitial table formatting is broken: table does not split/short_desc delta_ts2013-08-07 14:44:35 +/delta_ts reporter_accessible1/reporter_accessible cclist_accessible1/cclist_accessible classification_id2/classification_id classificationApplication/classification productWriter/product componentformatting/component versionOOo 1.0.0/version rep_platformAll/rep_platform op_sysAll/op_sys bug_statusCONFIRMED/bug_status resolution/resolution bug_file_loc/bug_file_loc status_whiteboard/status_whiteboard keywords/keywords priorityP2/priority bug_severitytrivial/bug_severity target_milestone---/target_milestone everconfirmed1/everconfirmed reporterjsc/reporter assigned_to name=AOO issues mailing listissues/assigned_to ccissues/cc ccjsc/cc cf_bug_typeDEFECT/cf_bug_type cf_lastconfirmedver---/cf_lastconfirmedver cf_fix_difficulty---/cf_fix_difficulty votes0/votes comment_sort_orderoldest_to_newest/comment_sort_order long_desc isprivate=0 commentid1658113/commentid comment_count0/comment_count who name=jsc/who bug_when2006-01-06 12:51:58 +/bug_when thetextinitial table formatting is broken: table does not split after first load/thetext /long_desclong_desc isprivate=0 commentid1658114/commentid comment_count1/comment_count who name=Mathias_Bauer/who bug_when2006-01-20 16:57:21 +/bug_when thetextWe will not finish this until 2.0.2 code freeze -gt; retargetting to 2.0.3/thetext /long_desclong_desc isprivate=0 commentid1658115/commentid comment_count2/comment_count who name=frank.meies/who bug_when2006-04-26 10:48:39 +/bug_when thetextFME: I discussed this issue with KSO. The code changes for this fix will require a lot of testing resources, since the code in this area is quite fragile. Since the time frame for 2.0.3 release is very thight and ressources are limited, I re-target this issue to 2.0.4./thetext /long_desclong_desc isprivate=0 commentid1658116/commentid comment_count3/comment_count who name=frank.meies/who bug_when2006-05-15 12:09:33 +/bug_when thetext./thetext /long_desclong_desc isprivate=0 commentid1658117/commentid comment_count4/comment_count who name=frank.meies/who bug_when2008-01-14 09:35:31 +/bug_when thetextCannot be implemented until code freeze =gt; target 3.x/thetext /long_desc /bug /bugzilla One approach I've used is to narrow down which issues you are interested in, via the UI, maybe filter by component or date range or status, and from that determine a list of issue numbers. Then you can retrieve the XML via calls to the REST API. I have a python script that helps with that part of things, if you are interested. Regards, -Rob Regards, Andrea. - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail:
Re: Question about using broken / corrupt documents and crash reports
On Fri, Sep 19, 2014 at 4:43 PM, Kuchta, Tomasz t.kucht...@imperial.ac.uk wrote: Hi All, I’m a PhD student at Imperial College London, where I work on techniques for recovering broken documents, i.e. files that either crash a program or do not load correctly. One of the problems that I came across is the availability of good benchmarks. As far as I know, OpenOffice has a bug reporting feature, and I was wondering whether it might be possible to use some of these reports and associated documents to try our recovery mechanism on them. Hi Tomasz, The crash reporting feature existed in older versions of OpenOffice.org and sent reports to servers controlled by Sun Microsystems. We stripped out this feature from OpenOffice when it came to Apache. It raised data privacy issues that we did not want to deal with. Two alternative approaches you might want to consider: 1) Our Bugzilla data contains many documents submitted by users that illustrate the bugs they were reporting. Not all were crashes or load issues, but many were. http://issues.apache.org/ooo/ 2) Using fuzzing automation techniques, you can randomly modify the bits of a file, looking for crashes.We've done a good deal of this to search for crashes with security ramifications. You can see my presentation on this technique here: http://www.robweir.com/blog/publications/AOOFuzzing.pdf As you'll see from that presentation, I seeded the fuzzing campaign with documents from our bug database, which helps since it starts with documents that are already, in some way, problematic. Regards, -Rob Thank you, Tomasz Kuchta - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Progress and Quality
On Tue, Sep 16, 2014 at 6:06 PM, Pedro Lino pedl...@gmail.com wrote: Hi Andrea Thank you for the quick answer. I'm wondering if I'm missing something or development really stopped/slowed down since the 4.1.1 release? I can't speak for the others. But since the latest visible commit is mine, I've been working more on the website in recent days. Actually my question was more in the sense Am I looking at the right statistics? because I find it hard to believe that with so much to be done and so many people participating, there hasn't been a code change in 7 days... On a separate note, from a Quality perspective it would probably would be a good idea if Apache OpenOffice code was scanned by one of these Coverity analysis The Apache OpenOffice code is scanned by Coverity, and (since this is considered security-relevant) data are privately accessible to some developers. Is it possible to make public the project's defect density for Apache OpenOffice? I'm quite curious since I find AOO more stable than LO. If I recall correctly (I've never seen them), most of the reports and metrics did not seem very useful, since they included a lot of false positives; one could silence those warnings by writing extra code or extra assertions just to help the analyzer understand that nothing was wrong, but this would be merely to please the analyzer and not to enhance the real quality. That makes sense. But there are possibly some real leaks and bugs that could be attended... Our main focus for finding latent security flaws has been via document fuzzing. It is more complicated to set up than just running a static analysis tool but since it involves probing the actual running code it is more effective in many ways. Historically this is one of the primary ways that editors like OpenOffice are exploited.Also, when security researches report security flaws to us, they are often flaws found from fuzzing. I don't recall ever seeing a report that was derived from static analysis. If you want to read more about what we're doing with fuzzing you can see my presentation from ApacheCon: http://www.robweir.com/blog/publications/AOOFuzzing.pdf Also, if you are really interested in this area I can help you set up a fuzzing environment. It works best if you have a machine (or a VM) your can dedicate to it for a couple of weeks . Regards, -Rob I haven't read the article you linked to yet, but if your point was Coverity should scan Apache OpenOffice the answer is This is already happening. Actually I meant some sort of scan, but since AOO is also scanned by Coverity then it would be interesting to know how the two compare. Regards, Pedro - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Progress and Quality
On Wed, Sep 17, 2014 at 10:40 AM, Pedro Lino pedl...@gmail.com wrote: Hi Rob Our main focus for finding latent security flaws has been via document fuzzing. It is more complicated to set up than just running a static analysis tool but since it involves probing the actual running code it is more effective in many ways. Historically this is one of the primary ways that editors like OpenOffice are exploited.Also, when security researches report security flaws to us, they are often flaws found from fuzzing. I don't recall ever seeing a report that was derived from static analysis. You are focusing on security and exploits (which is obviously a very important area). But I was thinking more in terms of program stability *during* usage. I assume that Coverity's project's defect density would reflect this? The correlation is not clear. I'd note, for example, that the Swiss Supreme Court gave a presentation recently where they said they prefer Apache OpenOffice over LibreOffice because of the greater stability of AOO. If I had to guess, what is probably true is that defect density in newly written code is correlated to real-world quality, as seen by users. But 10-year old code? Over a long period of time serious bugs of this kind -- crash bugs and other instability issues -- tend to be identified by users and are either fixed or at least well-known. We're unlikely to find new serious instabilities by examining ancient code. The other factor is the source of bugs. Research has shown (general academic research, not AOO specifically) that a large percentage of bugs in software are introduced when fixing other bugs. Whenever you touch the code there is an opportunity for adding a new bug. So I'm not a big fan of changing thousands of lines of code based on static analysis. It can very well make the code less stable, not more. Where we've used Coverity results it has been in a much more focused way, looking for specific defects with impact. If you want to read more about what we're doing with fuzzing you can see my presentation from ApacheCon: http://www.robweir.com/blog/publications/AOOFuzzing.pdf Also, if you are really interested in this area I can help you set up a fuzzing environment. It works best if you have a machine (or a VM) your can dedicate to it for a couple of weeks . Very interesting stuff. Actually the few times I had any problem with AOO usage was not while opening files. They happen during regular work sessions where Calc/Writer/Impress would freeze completely and leave no other choice other than killing soffice (with consequent data loss) So I would be more interested in running a debug build that could log these occasional crashes (if they are not occasional and I can replicate them, I create a regular Issuezilla bug report). What OS are you running on? Regards, -Rob Regards, Pedro - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Request for addition to the QA team
On Fri, Sep 5, 2014 at 1:10 PM, Deborah Digges deborah.gertrude.dig...@gmail.com wrote: Hello, I request you to kindly add me to the QA team on Bugzilla. This would allow me to assign issues to myself, which I am currently unable to do due to the lack of the required privileges. I do not see the take command below the assigned to section of a bug. Done. regards, -Rob Thanks, Deborah Digges - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Intro
On Wed, Aug 20, 2014 at 2:37 AM, Sushmita Karan sus.j...@gmail.com wrote: Hi , I , Myself Sushmita KaranI am new to this IT software field. I want to start my career in QA tester/analyst. I am recently doing training in QA from a institute online...have done manual testing and now automation testing tools class going on. I have learned the testing lifecycle and is familiar with it in bits and pieces .I am trying hard to understand but without hands on experience am finding it difficult. I want help with writing test cases, identifying the bugs and defect and how to jot down in spreadsheets. I want to learn from experienced personals so that i can make my interest of becoming a tester successful. I have my degree as a Bachelors of Science from India. I have no prior knowledge of any computer related programmings or work. Please help me in starting out . Hello Sushmita, Welcome to the Apache OpenOffice project! A couple others have pointed you to the Orientation pages on our website: http://openoffice.apache.org/orientation/intro-qa.html This page will help you get signed up for an account on Bugzilla and help explain the kinds of things the QA team works on. Since you have prior experience with SQA a lot of this will be familiar. The QA effort tracks the project's overall lifecycle. Since we just released Apache OpenOffice 4.1.1 a week ago, it is natural that we focus now on reviewing incoming bugs reports from users. We'll want to determine, over the next few weeks, whether any new and serious bugs slipped through into this release. The section called Easy QA Task: Confirm New Defect Reports on the Orientation page will help you get started with that. If you have any questions, please send them to the qa@openoffice.apache.org mailing list and someone will respond. It may be a little slow right now, since August is vacation time for many project volunteers, but it will pick up again in September. Regards, -Rob Thanks, Sushmita. - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: New QA Volunteer
On Wed, Aug 20, 2014 at 5:52 PM, victoria.hardy victoria.ha...@vecna.com wrote: Hello everyone, My name is Victoria Hardy. I am a QA tester working for Vecna Technologies in Cambridge. My company has a strong emphasis on community Hello Victoria, and welcome to the Apache OpenOffice project! Ah, Cambridge. I used at Lotus Development Corporation, many years ago, both in Lechmere and Kendall Square. Boca Grande burritos, yummm... But now I'm out in the 'burbs. service and open source projects, so I have decide to get involved with the OpenOffice community. I have been a software tester for about 2 years. I have particular experience with manual testing, test case writing, and accessibility standards for software. Although I have mostly been doing manual testing I know how to use Selenium and I hope to learn jBehave soon. I have some programming skills in Java, C++ and Python. Wow, it sounds like you have a great set of skills and experience. We can always use someone with this kind of background. What I don't really have experience with is the Open Source Community. I have been reading through the QA orientation module. I have opened a Bugzilla account. I am used to working with Jira, but Bugzilla looks fairly similar so I don't think the learning curve on it should be that steep. If you are entirely new to open source you might want to review some of the other orientation pages as well, so you get a feel for how we're organized and how we make decisions. It is very different from a hierarchical top-down corporate structure. We're very flat and self-directed. http://openoffice.apache.org/orientation/ Perhaps it would be best for me to start with reviewing some of the bug reports? Is there a specific procedure for doing that? We just release Apache OpenOffice 4.1.1 last week. So reviewing incoming bug reports from users, to see if there is anything surprising (we hope not!) found by them in this release is a good place to start. You can find details in the Easy QA Task: Confirm New Defect Reports section of the QA Orientation page. Regards, -Rob I look forward to working with you all. Thank you, Victoria -- Victoria Hardy/br Software Tester/br victoria.ha...@vecna.com/br 401-499-3942 (mobile)/br www.vecna.com/br Cambridge Research Laboratory/br Vecna Technologies, Inc./br 36 Cambridge Park Drive Cambridge, MA 02140/br Office: (617) 864-0636 Fax: (617) 864-0638 http://vecna.com/br Better Technology, Better World (TM)/br The contents of this message may be privileged and confidential. Therefore, if this message has been received in error, please delete it without reading it. Your receipt of this message is not intended to waive any applicable privilege. Please do not disseminate this message without the permission of the author. - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Please add me to the qa-team in Bugzilla
On Wed, Aug 20, 2014 at 5:54 PM, victoria.hardy victoria.ha...@vecna.com wrote: Hello, Please add me to the qa-team in Bugzilla. My username is victoria.ha...@vecna.com. Done. -Rob Thank you, Victoria -- Victoria Hardy/br Software Tester/br victoria.ha...@vecna.com/br 401-499-3942 (mobile)/br www.vecna.com/br Cambridge Research Laboratory/br Vecna Technologies, Inc./br 36 Cambridge Park Drive Cambridge, MA 02140/br Office: (617) 864-0636 Fax: (617) 864-0638 http://vecna.com/br Better Technology, Better World (TM)/br The contents of this message may be privileged and confidential. Therefore, if this message has been received in error, please delete it without reading it. Your receipt of this message is not intended to waive any applicable privilege. Please do not disseminate this message without the permission of the author. - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Please add me to the qa-team in Bugzilla
On Tue, Aug 26, 2014 at 11:52 AM, Sushmita Karan sus.j...@gmail.com wrote: please add my username tooadd me to qa-team in bugzilla. username sus.j...@gmail.com I don't see an account in Bugzilla with that name. Did you create an account? You need to create the account first, then I can add your ID to the qa-team group. Regards, -Rob On Tue, Aug 26, 2014 at 10:31 AM, Rob Weir robw...@apache.org wrote: On Wed, Aug 20, 2014 at 5:54 PM, victoria.hardy victoria.ha...@vecna.com wrote: Hello, Please add me to the qa-team in Bugzilla. My username is victoria.ha...@vecna.com. Done. -Rob Thank you, Victoria -- Victoria Hardy/br Software Tester/br victoria.ha...@vecna.com/br 401-499-3942 (mobile)/br www.vecna.com/br Cambridge Research Laboratory/br Vecna Technologies, Inc./br 36 Cambridge Park Drive Cambridge, MA 02140/br Office: (617) 864-0636 Fax: (617) 864-0638 http://vecna.com/br Better Technology, Better World (TM)/br The contents of this message may be privileged and confidential. Therefore, if this message has been received in error, please delete it without reading it. Your receipt of this message is not intended to waive any applicable privilege. Please do not disseminate this message without the permission of the author. - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: QA - team group in Bugzilla
Done. -Rob On Fri, Jun 6, 2014 at 4:09 PM, udaya Muduganti udaya.muduga...@gmail.com wrote: Hello, Can you please add me to QA - team group in Bugzilla? My Bugzilla id is udaya.muduga...@gmail.com. Thanks Udi - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: AOO Post 4.1 Test Starts! Call for volunteers!
On Wed, May 21, 2014 at 9:48 AM, Noel Shantell noel.shant...@gmail.com wrote: Thanks, I have completed the installation. Bugzilla Username: noelshant...@gmail.com I've added you to the QA Team group in Bugzilla, so you should now be able to edit bugs. -Rob TestLink Username: PQATester When you have time, please let me know which test cases you would like me to review. Thanks, Noel Prude On Tue, May 20, 2014 at 5:10 AM, Yuzhen Fan fanyuz...@gmail.com wrote: Hi Noel, Here is the installation guide, hope it helps: http://www.openoffice.org/download/common/instructions.html#winoverview On Wed, May 14, 2014 at 10:01 PM, Noel Shantell noel.shant...@gmail.com wrote: Hello - How do you install Open Office? Test Environment Operating System: Windows 7 Internet Explorer Version: 11 Thanks, Noel Prude Software Quality Assurance noelshant...@gmail.com On Mon, May 5, 2014 at 4:46 AM, Yuzhen Fan fanyuz...@gmail.com wrote: Hi All, We have released AOO 4.1 successfully on Apr 29 with voting, but we still have some test cases not completed during 4.1 stage, in order to check the post 4.1 quality status, here comes the call for volunteers on AOO post 4.1 testing. If you have interest and can help over the next few weeks, on Linux Redhat 64bit, Linux Redhat 32bit, Linux Ubuntu 64bit, Mac 10.9, Windows 7 and Windows 8, please send a note to the QA mailing list ( qa@openoffice.apache.org). If you have a Testlink account[1] send your ID as well as what platform you can help test(if you haven't a Testlink account, you can register one). You should also get installation sets from trunk [2] and report issues in Bugzilla [3]. You may want to see detail instructions in Test Guidence [4]. [1] http://aootesting.adfinis-sygroup.org/index.php [2] http://ci.apache.org/projects/openoffice/ [3] https://issues.apache.org/ooo/ [4] https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1+Full+Regression+Test+Guidance Thanks! -- Regards, Yu Zhen -- Regards, Yu Zhen - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: AOO Post 4.1 Test Starts! Call for volunteers!
On Tue, May 6, 2014 at 12:45 PM, Hitesh Jain jainhi...@gmail.com wrote: Hi I have created my Bugzilla account. Please add me to the qa-team group in Bugzilla. Hitesh Sorry for the delay. We had some email problems at Apache a few weeks ago and I did not see your note until now. You are now added to the QA Team! -Rob On May 6, 2014, at 4:33 AM, Yuzhen Fan fanyuz...@gmail.com wrote: Hi Edwin, Thanks for your help all along, I have assigned you 17 manual test cases on Linux Deb 64 bit. On Mon, May 5, 2014 at 6:31 PM, Edwin Sharp el...@mail-page.com wrote: Hi Yu Zhen Please assign Linux Deb 64 bit and Win 7 manual cases, TestLink ID elish. Thanks, Edwin On Mon, May 5, 2014, at 12:46, Yuzhen Fan wrote: Hi All, We have released AOO 4.1 successfully on Apr 29 with voting, but we still have some test cases not completed during 4.1 stage, in order to check the post 4.1 quality status, here comes the call for volunteers on AOO post 4.1 testing. If you have interest and can help over the next few weeks, on Linux Redhat 64bit, Linux Redhat 32bit, Linux Ubuntu 64bit, Mac 10.9, Windows 7 and Windows 8, please send a note to the QA mailing list ( qa@openoffice.apache.org). If you have a Testlink account[1] send your ID as well as what platform you can help test(if you haven't a Testlink account, you can register one). You should also get installation sets from trunk [2] and report issues in Bugzilla [3]. You may want to see detail instructions in Test Guidence [4]. [1] http://aootesting.adfinis-sygroup.org/index.php [2] http://ci.apache.org/projects/openoffice/ [3] https://issues.apache.org/ooo/ [4] https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1+Full+Regression+Test+Guidance Thanks! -- Regards, Yu Zhen - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org -- Regards, Yu Zhen - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Introducing Myself to list
On Sat, Apr 19, 2014 at 3:26 PM, Matthew Harelick msharel...@gmail.com wrote: Hello: My name is Matthew. I am from northeast United States. I have been involved with functional testing and system testing for about 9 years. I have been writing test automation for about 15 years. This is my first open source project. I will probably get involved in development as well, but I would like to learn a lot more about the product , so QA is the place to do that. The technology I know from work experience is Linux, Java, C++, Python, Windows, .NET, and C#. The technology I have access to for the purpose of open source assistance is Mac OS, iPad, python, java, Windows 7. I have built test automation for GUI¹s , Linux based command line applications, messaging based applications, and .NET based applications. Hello Matthew, Welcome to the Apache OpenOffice project! I'm in the NE as well, in Massachusetts. You list an impressive range of skills. We have a Java/Eclipse based GUI automation testing tool for OpenOffice, where test cases are written in Java, but it has been neglected recently, since relatively few QA volunteers know Java. Maybe you want to take a look at it? In general we're in the end game for the OpenOffice 4.1 release, hoping to release before the end of the month. I'd expect another Release Candidate (RC4) in the next few days. They'll be some targeted testing to verify some fixes, but it will be very limited. It is a good time to regroup and plan for what we want to do for QA on the next release. Have you seen our New Volunteer Orientation page? It has a bunch of information useful for new volunteers, about Apache, about the OpenOffice project, as well as a specific page about QA: http://openoffice.apache.org/orientation/ Scan over those pages at your leisure. The QA page will deserve more attention since it will lead you to get signed up for the right mailing lists, wikis, Testlink, Bugzilla -- the tools we use for QA. Feel free to post back to the list with any questions. I or one of the other volunteers will try to help. Regards, -Rob I am following the instructions, so I do not yet have a Bugzilla ore test link account. Matthew - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Răspuns: New QA Volunteer
On Wed, Apr 23, 2014 at 3:53 PM, Alexandro Colorado j...@oooes.org wrote: Afaik Bugzilla should be automated, check your spam box. Or try to do it again. Yes. I do not see any BZ account for lavinia46...@yahoo.com . So see if there is a confirmation in your spam folder, or try again. The only manual process is to upgrade your account level to QA auditor. You have the following permission bits set on your account: canconfirm Can confirm a bug or mark it a duplicate editbugsCan edit all bug fields qa-team Members of the AOO QA team registered-user All registered users I also wonder if maybe Yuhzen can help speed out the process. I am able to do that, once Lavinia has an account. -Rob On 4/23/14, Lavinia 桜 lavinia46...@yahoo.ro wrote: No response yet . ID would be lavinia46...@yahoo.com :D thank you În Miercuri, 23 Aprilie 2014 20:06:40, Rob Weir robw...@apache.org a scris: On Wed, Apr 23, 2014 at 4:06 AM, Lavinia 桜 lavinia46...@yahoo.ro wrote: Ping! :D Success! -Testlink: lavinia46203 -Bugzilla: waiting for confirmation e-mail :D Any response on the Bugzilla ID? If you can let me know your ID I can add you to the qa-team group, for added permissions. Regards, -Rob - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org -- Alexandro Colorado Apache OpenOffice Contributor http://www.openoffice.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
OpenOffice Weekly News
In another thread I pointed to an interesting thing the CouchDb project was doing on their blog: https://blogs.apache.org/couchdb/entry/couchdb_weekly_news_april_3 I suggested doing something similar for AOO, perhaps by collecting stories on the wiki and then copying into a blog post at regular intervals. The feedback was good, so let's give it a try! The template, with a little content to get started is on the wiki here: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=40508638 As you come across interesting content, from within the community, the forums, in the press, blogs, wherever, feel free to add it to the wiki. When April 21st comes, I (or someone else if they want) will copy it into the blog, do some light editing, publish and then reset the wiki so we can start again for the next issue. Thanks! -Rob - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: [VOTE]: Release Apache OpenOffice 4.1.0 (RC2)
On Apr 9, 2014, at 8:46 AM, Jürgen Schmidt jogischm...@gmail.com wrote: We found a new showstopper 124639 and have to prepare a new RC 3. IMHO it would be best if, in such cases, the Release Manager formally propose to end the previous vote. This reinforces the fact that the PMC decides when a vote fails or not. An easy way to do this is to send a note like, I propose to cancel the current vote because insert reasons. If there are no objections the vote is canceled That gives the opportunity for someone to object. In that case the vote would continue. -Rob But nevertheless we found several showstopper issues late in RC builds. Even in code that is in the product since December last year. I would like to invite all volunteers to test the current available RC2 more intensive and report potential problems. A new RC 3 build will be prepared later this week. Juergen On 4/8/14 11:00 AM, Jürgen Schmidt wrote: Hi all, this is a call for vote on releasing the available release candidate (RC2) as Apache OpenOffice 4.1.0. Apache OpenOffice 4.1 is a minor update with many bugfixes and at least 2 major improvements. It's the first version where we have the iAccessibility2 support integrated and available. A very huge step forward to reach and better support disabled users especially on Windows. The second improvement is the switch to 64 bit on MacOS. A long and overdue must do shift forward to support newer APIs (replace deprecated APIs) and platforms on MacOS. And we can provide again more complete UI translations and have now support for 38 languages. New languages for this release compared to 4.0.1 are Bulgarian, Danish, Hebrew, Hindi, Norwegian Bokmal and Thai. Apache OpenOffice 4.1 will be a further key milestone to continue the success of OpenOffice. An overview of the integrated release issues can be found under: http://people.apache.org/~jsc/milestones/4.1.0-rc2/AOO4.1.0_RC2_fixes.html The RC2 fixed 4 further problems: [1] https://issues.apache.org/ooo/show_bug.cgi?id4599 [2] https://issues.apache.org/ooo/show_bug.cgi?id4607 [3] https://issues.apache.org/ooo/show_bug.cgi?id4509 [4] https://issues.apache.org/ooo/show_bug.cgi?id4394 The release candidate artifacts (1) (source release, as well as binary releases for 38 languages) and further information how to verify and review Apache OpenOffice 4.1.0 can be found on the following wiki page: https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds The RC is based on the release branch AOO410, revision 1585426! And a fresh and clean RAT scan output of this revision can be found under http://people.apache.org/~jsc/milestones/4.1.0-rc2/AOO4.1.0_RAT_Scan.html Please vote on releasing this package as Apache OpenOffice 4.1.0 The vote starts now and will be open until: Friday, 11 April: 2014-04-11 11:00am UTC+2. But we invite all people to vote (non binding) on this RC. We would like to provide a release that is supported by the majority of our project members. [ ] +1 Release this package as Apache OpenOffice 4.1.0 [ ] 0 Don't care [ ] -1 Do not release this package because... (1) the upload for the Linux artifacts is still ongoing, expected to be available in 2-3 hours. - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Reminder: Make sure you are included in our AOO 4.1 credits page
The Help/About box of OpenOffice has a link to this credits page: http://www.openoffice.org/welcome/credits.html We link to that page from our website and mention it in release announcements. That page links to this wiki page for a list of our volunteers: https://cwiki.apache.org/confluence/display/OOOUSERS/Directory+of+Volunteers If you are a newer volunteer you might not have an entry there yet. If so, please add one. If you already have an entry, please review and update if needed. Note: This is not just for programmers. Everyone who contributed is encouraged to add their name. This includes QA, beta testers, translators, those helping answer user questions, writing documentation, admin work on our web sites and services, etc. Thanks! -Rob - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: [RELEASE]: propose AOO 4.1.0 RC - Showstoppers?
On Sun, Apr 6, 2014 at 2:18 AM, Oliver-Rainer Wittmann orwittm...@googlemail.com wrote: Hi, On 06.04.2014 09:06, Rainer Bielefeld wrote: Hi, we have a potential showstopper Issue 124607 - .odt with (Page-No) field in header/footer and comment for text range fails to open with Read Error. Error reading file https://issues.apache.org/ooo/show_bug.cgi?id=124607 For me it is a show-stopper. I propose to prepare a new RC which includes a corresponding fix. The fix is already in progress. Hi Oliver, Could you say a few words about the defect. Did it exist in the beta as well? -Rob Best regards, Oliver. CU Rainer - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Bugs already fixed in LibreOffice
On Sat, Mar 29, 2014 at 11:43 AM, Pedro Lino pedl...@gmail.com wrote: Hi all I have reported many bugs and some have already been solved in LibreOffice. I'm wondering if it makes sense to report them *again* to the Apache bugzilla... If you know the bug exists in AOO as well, then feel free to report it in BZ. But it is worth checking, since there are many LO bugs that never existed in AOO. However, since the LibreOffice license is not compatible with Apache, does this mean that the solution used by LibreOffice can no longer be used? E.g. if the solution for problem X is 1+1 then Apache must find a workaround to reach the same result (something like (2*(1+1))/2 )??? What if there is a *single* solution to a problem (e.g. there should be a comma where there is a semi comma by mistake)? Are the Apache developers forbidden to use the same solution because someone already submitted a patch to LibreOffice that does this? We cannot copy the source code of LO into AOO. But looking at bug reports and even developer comments on bug reports is fine. So if a LO bug report says LO crashes when doing Foo and a developer later comments, Fixed. Issue was that X must be 1+1, then it is fine for us to confirm the bug exists in AOO and for a developer to try a similar fix. If there is only a single reasonable solution to a bug then it would be natural for the bug fixes to be quite similar. But in general AOO developers should avoid looking at LO source code. Also, if there is a 3rd party patch attached to an issue, we could contact the author of the patch and ask if they agree to make it available to AOO as well, under the Apache License. We've integrated several LO patches in this way. Regards, -Rob Cheers, Pedro - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Introduction
On Tue, Mar 25, 2014 at 11:29 PM, Danette Fernando danette.ferna...@gmail.com wrote: Hi I am new to this group and I am excited about learning more about qa. I am from Chicago, IL and am looking to make a career change into qa from marketing. I look forward to working on this project. Hello Danette, Welcome to the Apache OpenOffice project! You'll want to subscribe to the QA mailing list so you get all the messages. You can do that by sending an email to qa-susbscr...@openoffice.apache.org. We're just finishing up our 4.1 release, so things are a bit crazy right now and responses might be slower than normal. Are you already an OpenOffice users? How familiar with the product are you? What operating systems do you have access to for testing? Regard, -Rob Danette Feranndo - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: AOO 4.1 Full Regression Test Starts! Call for volunteers!
On Mon, Mar 24, 2014 at 8:16 AM, Pedro Lino pedl...@gmail.com wrote: Hi all I'm curious: does this mean Apache OpenOffice is dropping support for Windows XP? No. It just means that we focus this test pass on the recent OS versions. We still support Windows XP. -Rob My PC runs Windows XP and I know it will not be updated in the near future (with the current economic situation this is simply NOT a priority) This is possibly the case for many PCs since XP is running on nearly 30% of all PCs worlwide according to netmarketshare ( http://www.netmarketshare.com/operating-system-market-share.aspx?qprid=10qpcustomb=qpcustomd=0 ) Is there an official position on support for Windows XP? Regards, Pedro - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: German authorities want to improve AOO - LibO
On Mon, Mar 24, 2014 at 12:09 PM, Louis Suárez-Potts lui...@gmail.com wrote: Hi, On 2014-03-24, at 06:18, Rainer Bielefeld rainerbielefeld_ooo...@bielefeldundbuss.de wrote: Hi, is someone from Germany observing this? http://www.heise.de/open/meldung/Behoerden-wollen-Libre-OpenOffice-verbessern-2152858.html I had a discussion on improving OO with the lead of the (mostly German) Open Source Business Alliance, Peter G. Sounded great… but the emphasis for him was on LibreOffice. Not AOO. The English press release is here: http://www.osb-alliance.de/en/working-groups/projekte/major-features-in-loaoo/ That links to a PDF where they describe the requirements. On page 5 it says: The code implementing the use cases must be delivered to OSBA in two versions: one suitable for LibreOffice integration, one suitable for Apache OpenOffice integration. That means each version of the code changes must be developed, rebased and tested against a commit of the respective project that is not older than 60 days at the time of the delivery. And then later on that page: The contractor must publish the software source code developed for this project under license suitable for integration in the respective projects, ideally dual licensed Apache License Version 2.0, and Mozilla Public License Version 2.0. The contractor may choose to publish under Apache License Version 2.0 only. So it looks like regardless of who bids and wins, the results will be available for AOO to use as well. Regards, -Rob Best regards Rainer -louis - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
AOO 4.1 Beta Survey
I've put up a short survey related to the AOO 4.1 Beta. If you have installed 4.1 Beta, and can spare a few minutes, please fill out the survey. This will give us some important information on what configurations received a lot of exposure in the Beta and which parts did not. http://survey.openoffice.org/index.php/732688/ -Rob - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Bug Wrangler Heroes
On Wed, Mar 19, 2014 at 11:43 AM, Oliver-Rainer Wittmann orwittm...@googlemail.com wrote: Hi, On 18.03.2014 16:26, Rob Weir wrote: On Wed, Mar 12, 2014 at 4:41 AM, Rainer Bielefeld rainerbielefeld_ooo...@bielefeldundbuss.de wrote: Hi all, May be you are interested to know how who are the most active bug wranglers in Bugzilla? Because my scripting skills are not very good I used AOO Calc to find out with following steps (something quick and dirty): We should think of what stats we want. I can help with scripting it in Python. 1) Maybe a monthly summary, count of new bugs, closed bugs, etc., categorized by product. Also total comments, count of volunteers contributing. 2) Highlight the bugs with most activity that month 3) Volunteers with most new bug reports 4) Volunteers with most comments/activity 0 Downloadedhttps://mail-archives.apache.org/mod_mbox/openoffice-issues/201402.mbox 1 Copied to a .csv 2 opened document in AOO Calc 3 Filtered for --- Comment # to find comment headings 4 Copied visible rows to new sheet 5 Deleted all until From: Regular expressions find .*from and replace with nothing 6 Delete anything behind name: Regular expressions find .* and replace with nothing 7 Copy to new table and sort 8 Filter for not empty – no duplicates 9 Behind every visible contents =COUNTIF(A$1:A$3000;A1) (Example for row 1)counts number of duplicates 10 Copy to empty text documents and replace tabulators by blanks for posting here The result (only contributors with more than 3 comments) for February 2014: Comments / Name --- 824 Edwin Sharp 294 Rainer Bielefeld 174 Armin Le Grand 142 Oliver-Rainer Wittmann 126 SVN Robot 089 Andre 051 hanya 041 h...@apache.org 041 j...@apache.org --- 035 Marcus 035 Regina Henschel 034 Ariel Constenla-Haile 025 j.nitsc...@ok.de --- 023 zhaoshzh 022 Sam Jennings 018 V Stuart Foote 017 fanyuz...@gmail.com --- 016 Andrea Pescetti 016 Thorsten Wagner 015 brinzing 014 liuping 013 Clarence GUO 012 jolatt 012 Rob Weir 011 aterb...@progressive.com --- 011 Yuri Dario 010 bmarcelly 010 kurt.pfei...@gmail.com --- 009 Kevin Chilton 009 lauhub 009 r...@apache.org --- 007 gvalla...@gmail.com --- 007 oooforum 007 Raphael Bircher 007 richlv 007 snoff 006 Apostolos Syropoulos 006 behnoosh 006 hhu...@gmail.com --- 006 jmpoo 006 John 006 Shenfeng Liu 006 slacka 005 Aivaras Stepukonis 005 Andreas S=C3=A4ger 005 annette_ciancibe...@progressive.com --- 005 beckyfiedler 005 digulla 005 ella_no...@progressive.com --- 005 Jon Peli Oleaga 005 JP CASSOU 004 Akriti 004 bnjroo 004 hbie...@gmail.com --- 004 Kay 004 Kim Tidwell 004 laura h 004 Oukcha 004 schlocke 004 SharPorz 004 Sreedevi 004 sworddragon 004 trebly 004 veathako Some more statistics for February: - 2513 Comments 180 Commenters I'm getting different results, though using a Python script, perhaps with different assumptions. I took all the posts from the February mbox for iss...@openoffice.apache.org. I rejected ones that were release blocker processing issues, the ones starting with review or 4.1.0_release_blocker in the subject. For the remaining I looked at the X-Bugzilla-Who header to get the name of the person who changed the BZ issue. This gives me 3295 changes, from 228 people, more than what you have. My top 10 list is: el...@apache.org: 1020 rainerbielefeld_ooo...@bielefeldundbuss.de: 406 o...@apache.org: 212 armin.le.gr...@me.com: 175 svn...@dev.null.org: 126 awf@googlemail.com: 108 mar...@apache.org: 90 h...@apache.org: 79 j...@apache.org: 62 hanya.r...@gmail.com: 51 Maybe I'm counting more than comments and new issue reports? What changes do not require a comment? Changing the priority of an issue, for example? Often, I add myself to or remove myself from CC without any comment. For my review of issues fixed for AOO 4.1.0 I also just changed the Target Milestone field. That must be it. If I filter my results to show only those who entered a comment then my script matches Rainer's results. Well, almost. I'm off by 1 on the commenter count. For February I see: 99 people submitted 181 new bugs 181 people contributed 2513 comments Regards, -Rob Just my observations. Best regards, Oliver. Regards, -Rob Problems: New reports are not in the statistics, not a real problem, but my time was too limited. Hope I did not integrate too many fallacies into my calculations ;-) Best regards Rainer - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Bugzilla - new status request
On Tue, Mar 18, 2014 at 12:10 PM, Edwin Sharp el...@mail-page.com wrote: Hi Unconfirmed bugs which can not be evaluated (e.g. lack of knowledge or lack of hardware) get keyword needhelp. Currently, according [1]https://wiki.openoffice.org/wiki/Issue_lifecycle : Unconfirmed bug with lacking description - keyword=needmoreinfo - 14 days with no answer - Status=RESOLVED-IRREPRODUCIBLE. Something to keep in mind: we have the ability, in BZ, to send reminder notes on issues. For example, we can send a note to all needmoreinfo issues untouched for X number of days, warning that the issue will be closed if there is no response. We could also invite the reporter to retest with the latest version of AOO.I did such a cleanup a few years ago, but it is worth repeating every now and then. I suggest: Unconfirmed bug with lacking resources to evaluate - keyword=needhelp - 30 days with no answer - Status=RESOLVED-QA_GAP. I'd reserve needhelp for bugs that require a unique special set of skills, hardware, 3rd party software, etc., to confirm. Judge this with respect to the issue's product and component. For example, if a bug is a crash when running Writer with a 3rd party commercial OCR or voice transcription software, then mark it needhelp. Or if it only crashes when entering Thai text. Or it crashes only with a specific printer. I wouldn't mark an ordinary report needhelp only because no one has looked at it yet. To me the key thing about needmoreinfo is we've already tried to reproduce and could not. So we've asked for more information from the user. If we don't get a response from them we believe it would be impossible to reproduce the bug. In fact, it could be quite likely that there is no bug, only user error. So closing it is not a big deal. But needhelp bugs might be real bugs. Their problem is not lack of information, but lack of expertise or tools. Do we really want to lose track of them? I feel worse about marking them as resolved. If we can identify a specific QA gap, we can use that as an opportunity to recruit some more QA volunteers. Especially if there are themes to which issues are marked needhelp, we could try to find volunteers with those specific skills. Regards, -Rob Cheers, Edwin References 1. https://wiki.openoffice.org/wiki/Issue_lifecycle - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Beta Survey
On Fri, Mar 14, 2014 at 9:16 AM, Rob Weir robw...@apache.org wrote: The purpose of having a beta release of 4.1 is to gather feedback from users. Reports to Bugzilla or the mailing list is one source of feedback. But that doesn't give us a good sense of coverage. If there were no beta testers of the Bulgarian translation (for example) then we'd probably want to take a closer look, at that specific package. I'm putting together a beta survey that we can have beta testers fill out, to record their testing experience. I'm thinking of questions like: My question was not very clear. Sorry. This note was not a survey. It was asking for feedback on what questions we should ask on a survey. The questions I have here were proposed questions. If we can reach consensus on this I can code the survey into our LimeSurvey instance and we can collect this information from users of the public beta. Regards, -Rob 1) What platform they ran with 2) What language they used 3) How many hours they have used AOO beta 4) Which apps did they use 5) What file formats did they read/write 6) Link to a list of P1 bugs reported on beta: Did they encounter any of these bugs? 7) Did they encounter any other bugs? (Nudge them to enter a BZ report) 8) Did they try any of the new features in AOO 4.1 (list them) 9) Any other comments (free text response) Does anyone have any other suggested questions? The plan would be to send out the survey early next week, before the beta period is done, so we can react to any feedback. -Rob - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Beta Survey
The purpose of having a beta release of 4.1 is to gather feedback from users. Reports to Bugzilla or the mailing list is one source of feedback. But that doesn't give us a good sense of coverage. If there were no beta testers of the Bulgarian translation (for example) then we'd probably want to take a closer look, at that specific package. I'm putting together a beta survey that we can have beta testers fill out, to record their testing experience. I'm thinking of questions like: 1) What platform they ran with 2) What language they used 3) How many hours they have used AOO beta 4) Which apps did they use 5) What file formats did they read/write 6) Link to a list of P1 bugs reported on beta: Did they encounter any of these bugs? 7) Did they encounter any other bugs? (Nudge them to enter a BZ report) 8) Did they try any of the new features in AOO 4.1 (list them) 9) Any other comments (free text response) Does anyone have any other suggested questions? The plan would be to send out the survey early next week, before the beta period is done, so we can react to any feedback. -Rob - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Please Review 4.1 Release Notes
https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1+Release+Notes I notice that the Release Notes say nothing about the IAccesible2 support. Shouldn't we have something there about it? Maybe mention what AT have been tested and work, and if there are any useful tips for users? Any other topics? The hope is to release the beta early next week. So it is important that we have good release notes for that. Regards, -Rob - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Seeking test files in SGF and SGV formats
Two of the formats we support for import in Draw are: *.sgf == StarWriter Graphics and *.sgv == StarDraw 2.0 Neither are supported for export, so I'm unable to create these formats from within Draw. I didn't find any files with these extensions in our SVN tree. I also checked Bugzilla to see if any attachments were in these formats. I did not find any. I also searched via Google and did not find any. Does anyone have, or know where to find a few example files in these formats. Thanks in advance for any clues! Note: I was able to find or create sample files in all of the other formats supported by Draw. -Rob - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Seeking test files in SGF and SGV formats
All set. Max Merbald sent me some old sgf files he had. And I was pointed to some sgv files in the LibreOffice tree (thanks, Caolan!). -Rob On Fri, Mar 7, 2014 at 9:11 AM, Rob Weir robw...@apache.org wrote: Two of the formats we support for import in Draw are: *.sgf == StarWriter Graphics and *.sgv == StarDraw 2.0 Neither are supported for export, so I'm unable to create these formats from within Draw. I didn't find any files with these extensions in our SVN tree. I also checked Bugzilla to see if any attachments were in these formats. I did not find any. I also searched via Google and did not find any. Does anyone have, or know where to find a few example files in these formats. Thanks in advance for any clues! Note: I was able to find or create sample files in all of the other formats supported by Draw. -Rob - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: [RELEASE]: refined AOO 4.1 beta schedule
On Thu, Feb 27, 2014 at 11:38 AM, jan i j...@apache.org wrote: On 27 February 2014 17:18, Jürgen Schmidt jogischm...@gmail.com wrote: On 2/27/14 5:11 PM, jan i wrote: On 27 February 2014 16:58, Vladislav Stevanovic stevanovicvladis...@gmail.com wrote: Is it too late for update Serbian language? Wlada 2014-02-27 16:50 GMT+01:00 Jürgen Schmidt jogischm...@gmail.com: Hi, we are still verifying some fixes to identify the Beta as real beta, means some branding elements, names etc. And we are working on some serious bugfixes that we have identified already. The current plan is to start the build tomorrow and do the upload over the weekend. That means we should have a RC for AOO 4.1 beta available at the beginning of next. The new icons are still not complete and I am not sure how we can or should continue here. Replacing them for the final release is probably not a good idea. Work remaining before beta 1) Defect verification 2) Release Notes check, update and finalize the release notes [1] 3) Communications Clarify the communication/promotion for the beta. For example how many users do we want to reach with the beta. 4) Release vote Based on this a possible schedule can be March 4th: availability of AOO 41. Beta RC + start vote just for my understanding, dont we need to vote on the beta as well as the release. We send the beta out to general public, that would normally require a vote (might be a fast one). exactly, --- availability of Beta RC + start vote ;-) ?? you cannot make the beta available before the vote period for the beta ends. Right. That is what it says availability Beta RC. It is only the Release Candidate that is available before the vote. Before we can release the beta we need to have a release vote on the beta RC. -Rob Then while the beta is out, we can of course vote for the release. rgds jan I. Juergen rgds jan I. March 10th: public availability of AOO 41. Beta (until March 31th) ...: additional snapshot builds based on the beta including showstopper fixes April 2th: availability of AOO 4.1 RC April 7th: public availability of AOO 4.1 Any opinions or feedback Juergen [1] https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1+Release+Notes - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: [RELEASE]: refined AOO 4.1 beta schedule
On Thu, Feb 27, 2014 at 12:09 PM, Edwin Sharp el...@mail-page.com wrote: IMHO don't implement new icons. If beta is not general public then increase RC-final duration. One approach would be to have a quiet beta release, announced only on dev, qa, users mailing lists and forum.That will attract users who are already somewhat familiar with the product. Some users might see it as well on our download webpage, but it would not be the default choice. So we might get 1000-2000 users of the beta. If we think we want more, then we can promote it via blog, social network, website home page, etc. This will get more users, potentially 100,000 or more. But that does not mean we get more good quality bug reports in BZ. It could be messy. So it is a trade-off. If we wanted we could start small and then increase the publicity after a week. -Rob On Thu, Feb 27, 2014, at 17:50, Jürgen Schmidt wrote: Hi, we are still verifying some fixes to identify the Beta as real beta, means some branding elements, names etc. And we are working on some serious bugfixes that we have identified already. The current plan is to start the build tomorrow and do the upload over the weekend. That means we should have a RC for AOO 4.1 beta available at the beginning of next. The new icons are still not complete and I am not sure how we can or should continue here. Replacing them for the final release is probably not a good idea. Work remaining before beta 1) Defect verification 2) Release Notes check, update and finalize the release notes [1] 3) Communications Clarify the communication/promotion for the beta. For example how many users do we want to reach with the beta. 4) Release vote Based on this a possible schedule can be March 4th: availability of AOO 41. Beta RC + start vote March 10th: public availability of AOO 41. Beta (until March 31th) ...: additional snapshot builds based on the beta including showstopper fixes April 2th: availability of AOO 4.1 RC April 7th: public availability of AOO 4.1 Any opinions or feedback Juergen [1] https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1+Release+Notes - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: New QA Volunteer
On Wed, Feb 26, 2014 at 7:23 AM, Jochen Nitschke j.nitsc...@ok.de wrote: Hi, I would like to join the bugzilla qa-team (j.nitsc...@ok.de). My interests lie in code quality and I would like to learn more about unit testing. I read the good volunteer orientation till Level 3 dev qa, subscribed some mailing lists and managed to compile the code. Is it possible to sign me up for mwiki too? I couldn't find a link. Hello Jochen, I've added you to the qa-team in Bugzilla, so you should be OK there now. We had some spam issues on the MWiki and new accounts were suspended. But Andrea might be able to help you get in. As for testing, we're right now doing verification testing of the 4.1 beta release candidate, to make sure that the critical bugs that the developers marked as fixed are actually fixed. If you want to help with that Yuzhen can help you get started. But you mentioned unit testing... You might want to ask on the dev mailing list about that (d...@openoffice.apache.org). QA doesn't touch unit testing. But we do have a Java/Eclipse based GUI automation testing framework that needs some attention, if you are interested in that. Regards, -Rob Best regards Jochen Nitschke - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Bugzilla: Keyword regression
On Thu, Feb 6, 2014 at 5:12 AM, Edwin Sharp el...@mail-page.com wrote: I'm against this recommendation. Nothing more harmful to AOO reputation than an old unanswered problem because: Lack of basic respect to the person who took the time to report it. An indication for no control over the project. I think the primary sorting mechanism for fixes is based on user impact, i.e., the severity of the issue, how many users will run into it, and whether there are adequate workarounds. An issue is not necessarily more important just because it is old. Regressions are special for a different reason. A regression could be high severity or low severity. But a regression is caused by a recent code change. So with a regression we're more likely to have a developer active in the project who caused the defect, who knows that area of the code well and is able to fix it quickly. It is easiest to fix a new bug quickly than to investigate it years later. I wonder whether a combination of the regression flag and the version field would give us everything we need to know? If something is marked as found in version N and marked as regression then that tells us that the regression occurred between version N-1 and N, yes? -Rob On Thu, Feb 6, 2014, at 11:52, Rainer Bielefeld wrote: Hi, currently the manual on https://issues.apache.org/ooo/describekeywords.cgi seems to suggest to use that keyword also for problems what appeared between OOo 1.0.2 and OOo 1.0.3. Such use might be correct as a matter of form, but I think useless for QA and developers daly work. regression key word indicates a major priority for fixing a bug, because appearance of new problems is bad for AOO's reputation. But a regression between OOo 1.0.0 and OOo 1.0.1 from 2001 (as an overstated example) is nothing what should cause major reputation loss for AOO in 2014. So I recommend to limit use of Keyword regression for all Problems what appeared with AOO 3.4-dev or later and to add a corresponding hint in Bugzilla Help. BTW: I recommend to keep those hints in Bugzilla short (not more than 2 text rows or so) and do link to more elaborated help in the Wiki (for example). Best regards Rainer - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Reminder: ApacheCon 2014 Call for Papers Deadline is Feb 1st
The big ApacheCon conference will be April 7-9 in Denver. You can see the Call for Papers here: http://events.linuxfoundation.org/events/apachecon-north-america/program/cfp Who is planning on attending from OpenOffice? -Rob - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Testing
On Tue, Jan 21, 2014 at 2:41 PM, Daniel Nilsson dannilminus...@gmail.com wrote: Hi, My name is Daniel and I would like to start doing some testing for the OpenOffice project. I was wondering if someone could add me to qa-team in bugzilla (dannilminus...@gmail.com) and direct me to some beginners tasks Hello Daniel, I've added you to the qa-team in Bugzilla. Welcome aboard! Right now most of the testers are doing a Feature Verification Test pass of OpenOffice 4.1. If you are interested in helping with that then you should: 1) Sign up for a Testlink account 2) Respond back to this note with your Testlink ID and tell us what platform(s) you can test on. Yuzhen can then assign you a set of test cases to try. Regards, -Rob Best regards Daniel Nilsson - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: request for adding to 'qa-team' in Bugzilla
On Wed, Jan 15, 2014 at 2:33 PM, Nadya Polidorova moooncan...@gmail.com wrote: Hello, Could you add my Bugzilla account to 'qa-team'? It's moooncan...@gmail.com. Done. -Rob Best regards, Nadya - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Web accessibility guidelines -- which ones?
On Fri, Jan 10, 2014 at 5:55 AM, Christophe Strobbe stro...@hdm-stuttgart.de wrote: Hi, I agree that WCAG 2.0 is the way to go; the current Section 508 is still based on a pre-final version of WCAG 1.0 and will hopefully get updated by the end of the year. I wouldn't aim higher than WCAG 2.0 AA; even WCAG 2.0 A may be a challenge at the start. With regard to tools, I currently don't know what to recommend because I haven't evaluated any such tools recently. WebAIM's WAVE http://wave.webaim.org/ (and the Firefox toolbar http://wave.webaim.org/toolbar/) and the IDRC's AChecker http://achecker.ca/checker/index.php were developed by competent teams. I don't know who's behind Total Validator (meaning: I don't know the developers). Thanks. I'll take a look at the other tools as well. The thing I liked about Total Validator is it integrates HTML validation, CSS validation, accessibility checking and spell checking in a single tool. I'm seeing errors in all of these areas (though spelling errors are most usually US versus UK inconsistencies), so it would be good to fix them all at once. Regards, -Rpb Best regards, Christophe Am Fr, 10.01.2014, 04:35 schrieb V Stuart Foote: Rob, *, ... However, there was a confusing (to me) number of authorities for accessibility standards. It is really pretty simple--WCAG 2.0 is the gold standard for Web content, and is applicable to Non-Web Information and Communications Technologies (ICT). National and International Standards bodies are basing conformance against this standard. WCAG 2.0 A, AA, AAA ( also published as ISO/IEC 40500:2012 ) are functional levels of conformance with accessibility standards. http://www.w3.org/WAI/intro/wcag The reworked AOO Website should probably meet majority of WCAG v2.0 AA level requirements. And Apache OpenOffice as a document preparation and review program should also strive to meet WCAG level A AA conformance criteria for ICT (http://www.w3.org/TR/wcag2ict/ ). Fortunately much of that is accomplished for the website with valid HTML 5.0 and WAI-ARIA markup. While the introduction of IAccessible2 to supplement MSAA, and improvements in ATK and NSAccessibility move the office suite proper into a better compliance with some notable shortcommings. In the United States, the existing Accessibility Board US Section 508 requirements were loosely equivalent to WCAG v1, and are being rewritten to match functional levels of WCAG 2.0 A AA. The draft proposal for U.S. conformance can be found here: http://www.access-board.gov/attachments/article/490/draft-rule.pdf Also, relevant parts of the European Union EN 301 549 ( http://www.etsi.org/deliver/etsi_en/301500_301599/301549/01.00.00_20/en_301549v01c.pdf ) as work of the European Commision (EC) Mandate M 376 ( http://www.mandate376.eu/ ) are also based on WCAG v2.0 level A and AA. So running conformance validators for WCAG 2.0 A, AA, AAA is probably the correct choice in reworking the web site. Stuart -- Christophe Strobbe Akademischer Mitarbeiter Adaptive User Interfaces Research Group Hochschule der Medien Nobelstraße 10 70569 Stuttgart Tel. +49 711 8923 2749 - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Discussion: Test Effort Estimation Techniques
On Thu, Jan 9, 2014 at 6:10 AM, Edwin Sharp el...@mail-page.com wrote: Hello How is this relevant to us? From the Wikipedia page on test effort it is for cost estimation - Apache OpenOffice is developed 100% by volunteers. It might still make sense, even in a volunteer-led non-profit context. It is not a cost in a commercial sense, but we still need to coordinate things like translation due dates, estimated beta and release dates, and so on. We try to line up communications, interviews with the press, etc., to coincide with milestone dates like this. So being able to estimate how long a test pass will take is useful to predicting these dates. That said, I'm not sure we do anything very sophisticated here. What I've seen is mainly counting test cases and estimating how test cases/hour a volunteer can execute on average. -Rob Edwin On Thu, Jan 9, 2014, at 12:30, akriti wrote: Hello All, Happy New Year to all..!! I am interested in learning and implementing Test Effort Estimation techniques. Can we discuss about the latest or greatest Effort Estimation techniques here/ It would be nice if OO QA members share their experience. Thanks Regards, Akriti Jaiswal - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Web accessibility guidelines -- which ones?
I've started taking a look at our website from the perspective of accessibility. Since the website is mainly human-authored HTML, with many authors over several years, we'll need to check individual pages for problems. I was going to focus on the top 50 or so pages, which account for the vast majority of website visits. I found a number of scanning tools, both web-based and standalone, that looked good. However, there was a confusing (to me) number of authorities for accessibility standards. For example, one tool (Total Validator) offered to check against the following 6 guidelines: US Section 508 WCAG v1 A WCAG v1 AA WCAG 2.0 A WCAG 2.0 AA WCAG 2.0 AAA Does anyone have a good sense for which one is the most useful/appropriate for our website? Regards, -Rob - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Discussion: Test Effort Estimation Techniques
On Thu, Jan 9, 2014 at 9:51 PM, akriti email2akr...@gmail.com wrote: Thanks Rob and Edwin for response. It is general topic discussion and there is no significant relevance to open office work related to this topic. * It might be useful for volunteers if one wants to know how much effort he/she is spending (using any effort technique) while executing tests. For any estimation work, where I need to estimate my own person work, I use the techniques described here: http://en.wikipedia.org/wiki/Personal_software_process Essentially, define a metric for measuring the amount of work. Then find or create a tool to automate measurement. Then time how long it takes you do accomplish the tasks. Over time you then develop a baseline for quantity of work per unit time, your own personal productivity value. For example, with writing code the metric might be non-comment lines of code. For testing it might be test cases executed. For documentation it might be number of words. Almost any work where the tasks come in countable or measurable small pieces can be estimated using techniques like this. Where this technique is especially valuable is when you then adjust your personal process and measure whether your productivity increases or decreases. It becomes part of iterative process improvement. Regards, -Rob Thanks. * On Thu, Jan 9, 2014 at 5:05 PM, Rob Weir robw...@apache.org wrote: On Thu, Jan 9, 2014 at 6:10 AM, Edwin Sharp el...@mail-page.com wrote: Hello How is this relevant to us? From the Wikipedia page on test effort it is for cost estimation - Apache OpenOffice is developed 100% by volunteers. It might still make sense, even in a volunteer-led non-profit context. It is not a cost in a commercial sense, but we still need to coordinate things like translation due dates, estimated beta and release dates, and so on. We try to line up communications, interviews with the press, etc., to coincide with milestone dates like this. So being able to estimate how long a test pass will take is useful to predicting these dates. That said, I'm not sure we do anything very sophisticated here. What I've seen is mainly counting test cases and estimating how test cases/hour a volunteer can execute on average. -Rob Edwin On Thu, Jan 9, 2014, at 12:30, akriti wrote: Hello All, Happy New Year to all..!! I am interested in learning and implementing Test Effort Estimation techniques. Can we discuss about the latest or greatest Effort Estimation techniques here/ It would be nice if OO QA members share their experience. Thanks Regards, Akriti Jaiswal - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
What build to use for IAccesible2 testing?
What is the best stable build to use for IAccesible2 testing? Is the aoo-win7-snapshot from November 25th the right one? -Rob - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: introduction
On Sat, Nov 23, 2013 at 11:18 AM, c wrote: Hi, I am a beginner in QA and would like to participate in all activities. But for start need something simple. I can test on the following platforms: Windows 8 64-bit, Ubuntu 64-bit, I can test printing (Samsung ML-2510, EPSON XP-310), have access to MS Office Home and business 2013. Languages: English, French, Russian. I am willing to learn and I can dedicate 10h+ per week. Could someone please add me to the qa-team group in Bugzilla. Hello Maryna, I am one of our Bugzilla admins. I can add you to the qa-team. Have you already created a BZ account? I did not see one with your gmail address. If you have not done so, please create an account for yourself here: https://issues.apache.org/ooo And then send me your BZ user ID. Thanks! -Rob Thanks end regards Maryna Martynenko On Wed, Nov 20, 2013 at 7:56 AM, Yuzhen Fan fanyuz...@gmail.com wrote: Forwarding to Maryna in case s/he is not subscribed. And Maryna, welcome and please let me know your favorite QA tasks (test case execution, test case writing, defect handling, etc) when you are ready! Regards Yu Zhen On Mon, Nov 18, 2013 at 2:33 PM, Alexandro Colorado j...@oooes.org wrote: Welcome marya make sure to request your accounts on bugzilla and also follow the entry module documentation on QA activities. -- Sent from my Nokia N900 On Sun Nov 17 22:26:35 2013 Maryna Martynenko marmary...@gmail.com wrote: Hi, My name is Maryna. I am from Montreal, Canada. I worked as a software support and quality engineer on ERP projects for approx.. 8 yrs and now my goal is to focus more on QA. I would like to join QA team and contribute to OpenOffice project. Thanks and regards, Maryna Martynenko - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
New Committer: YuZhen Fan (fanyuzhen)
The Project Management Committee (PMC) for Apache OpenOffice has asked YuZhen Fan to become a committer and we are pleased to announce that she has accepted and taken the ID fanyuzhen. A warm welcome to YuZhen ! Regards, Rob, on behalf of the Apache OpenOffice PMC - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: QA
On Sat, Oct 19, 2013 at 6:28 AM, phillip brown p.b1...@hotmail.com wrote: Hello, I'm sending this to request to be added to the qa-team group in Bugzilla, my logon is: daer...@hotmail.com Done. Regards, -Rob - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Skills, Resources and Mentors
On Mon, Sep 30, 2013 at 5:43 PM, Kay Schenk kay.sch...@gmail.com wrote: On Mon, Sep 30, 2013 at 8:58 AM, Rob Weir robw...@apache.org wrote: This projects depends on volunteer efforts. We have many routine tasks that need to be performed during a release cycle and even during ordinarily operation of our website and other public-facing services. In many cases a given task is well-understood and many members of the project understand how to do it. For example, moderating the mailing lists. In other areas we might only have a single person who really understands how to do a task. We also have many volunteers, signing up on the mailing list and asking how to help, on nearly a daily basis. There should be a way that we can more clearly identify what the routine tasks are, who knows how to do them, who wants to learn how to do them, and who is willing to mentor or teach others how to get started. So I've started the following wiki page to track some of the most common tasks in the project: https://cwiki.apache.org/confluence/display/OOOUSERS/Skills,+Resources+and+Mentors Feel free to insert additional tasks, or to add your name as an expert, mentor or someone who wants to learn. (Of course there are many other routine tasks performed by Apache Infra and not listed here. I'm focused on the tasks that are owned by the AOO project) This might also help is identify areas where we are currently dependent on a single person and want to train a backup, to cover for holidays, etc. Regards, -Rob - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org I think this is lovely idea but I'm a bit confused over what you mean by Learning Resources -- are you thinking people, or web resources or ??? I was thinking of web resources. So overall the page lists tasks and skills, and also the resources needed to learn how to perform those tasks: web resources and experts/mentors in the project. -Rob Thanks. -- - MzK Truth is stranger than fiction, but it is because Fiction is obliged to stick to possibilities. Truth isn't. -- Following the Equator, Mark Twain - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Skills, Resources and Mentors
On Tue, Oct 1, 2013 at 7:24 AM, Herbert Duerr h...@apache.org wrote: On 01.10.2013 07:14, Rainer Bielefeld wrote: Tal Daniel schrieb: But I couldn't edit the wiki page (I'm logged in to as Talchu). Hi, I can confirm that problem. I am not familiar with with cwiki, but I added myself to Directory of volunteers, where I currently also can't find a way how to edit that page. It seems currently cwiki only can be edited by very few persons? I cannot edit pages in the cwiki either. I was able to do it last week, but this week I can't, because the edit-page option is missing. Is this lock-out a collateral damage of the release notes being protected? The web page says: No edit restrictions are defined for this page. This is under Tools/Restrictions menu item. Do you see something differenent? I was able to edit it (of course). It looks like Andrea was as well. -Rob Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Skills, Resources and Mentors
On Tue, Oct 1, 2013 at 8:10 AM, Rainer Bielefeld rainerbielefeld_ooo...@bielefeldundbuss.de wrote: Rob Weir schrieb: The web page says: No edit restrictions are defined for this page. Hi Rob, I see the same, but unfortunately I see no Click here to edit page link. I can't remember where it was, but because of the other comments here I think it's not a problem with my memory, but simply the edit link is invisible for users with low permission level. Upper right corner of page: Edit, Share, Add, Tools menu items. Can you send a screenshot showing where the Click for Edit function should be visible (or attach it in a new Bug for this issue)? CU Rainer - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Skills, Resources and Mentors
On Tue, Oct 1, 2013 at 9:19 AM, Rainer Bielefeld rainerbielefeld_ooo...@bielefeldundbuss.de wrote: Rob Weir schrieb: Upper right corner of page: Edit, Share, Add, Tools menu items. Hi Rob, Als long as I am not logged in I only see Tools, after LogIn additionally Share. But not Edit, Add. And I am pretty sure that they were available for me few weeks ago. OK. There were some changes made to the ACL to prevent accidental changes to the release notes. But the impact of the ACL change was supposed to be limited to the release notes. I'll see if I can find more. I'll resend the root email when we can all actually edit the wiki ;-) -Rob CU Rainer - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Skills, Resources and Mentors
This projects depends on volunteer efforts. We have many routine tasks that need to be performed during a release cycle and even during ordinarily operation of our website and other public-facing services. In many cases a given task is well-understood and many members of the project understand how to do it. For example, moderating the mailing lists. In other areas we might only have a single person who really understands how to do a task. We also have many volunteers, signing up on the mailing list and asking how to help, on nearly a daily basis. There should be a way that we can more clearly identify what the routine tasks are, who knows how to do them, who wants to learn how to do them, and who is willing to mentor or teach others how to get started. So I've started the following wiki page to track some of the most common tasks in the project: https://cwiki.apache.org/confluence/display/OOOUSERS/Skills,+Resources+and+Mentors Feel free to insert additional tasks, or to add your name as an expert, mentor or someone who wants to learn. (Of course there are many other routine tasks performed by Apache Infra and not listed here. I'm focused on the tasks that are owned by the AOO project) This might also help is identify areas where we are currently dependent on a single person and want to train a backup, to cover for holidays, etc. Regards, -Rob - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Note: Updated BZ for new AOO version
On Mon, Sep 30, 2013 at 5:47 PM, Andrea Pescetti pesce...@apache.org wrote: On 27/09/2013 Rob Weir wrote: I've deactivated 4.0.1-dev as a version for new defects. I've added 4.0.1 as new version. There already exists a 4.1.0-dev version string I also deactivated 4.0.1 as a milestone assignment. Is it possible to add 4.0.1 to the Latest confirmation on field? Done. -Rob Thanks, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Note: Updated BZ for new AOO version
I've deactivated 4.0.1-dev as a version for new defects. I've added 4.0.1 as new version. There already exists a 4.1.0-dev version string I also deactivated 4.0.1 as a milestone assignment. Note: there are three bugs that are assigned the 4.0.1 milestone but are not marked as fixed, or even marked as accepted: 118363 Base code iss...@openoffice.apache.org CONF --- Copy From OOo Base Query Fails To Grab Full Selection 122094 Writer save-exp iss...@openoffice.apache.org CONF --- Protected MS WORD documents opened in OPEN OFFICE lose the protection 123311 Native-L eu iss...@openoffice.apache.org CONF --- UI: Print dialog shows wrong texts in menu 'File - Print - General I'll reset these to have no milestone. I don't think we want defects with a milestone assignment unless someone has taken ownership of them. Regards, -Rob - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Reminder: Time to update your entry in the Directory of Volunteers
We'll soon be releasing Apache OpenOffice 4.0.1. We want to give recognition to the many volunteers who contribute to the success of OpenOffice. One way we give credit is in our Directory of Volunteers. We link to this from the Help/About box of the product, as well as in blog posts and release announcements. If you have not already added yourself to the Directory, please do so. Anyone can sign up for a wiki account. The Directory of Volunteers can be found here: https://cwiki.apache.org/confluence/display/OOOUSERS/Directory+of+Volunteers Thanks! -Rob - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Hi I need 'commit rights' so I can confirm the bugs on Bugzilla.
On Sun, Aug 25, 2013 at 10:32 AM, daf safaa dafsa...@gmail.com wrote: Hi im safaa a moroccan student, i used openoffice for doing report in openerp. I think i can start contributing with QA because it will allow me to put my years as a user to help other users and also learn the suite better, i also want to give back to free software. Hi Safaa, I'm happy to meet you. I'm in the U.S., in Massachusetts, near Boston. You can see the info on our other QA volunteers on the wiki here: https://cwiki.apache.org/confluence/display/OOOUSERS/Directory+of+Volunteers (You're also welcome to add your own testing preferences there) I've added you to the qa-team group in Bugzilla, so you should not be able to edit defect reports. We released Apache OpenOffice 4.0 around a month ago. Right now most of us are reviewing bug reports submitted by 4.0 users and trying to confirm issues. You can find details about this task in the Easy QA Task: Confirm New Defect Reports section of our QA orientation page: http://openoffice.apache.org/orientation/intro-qa.html Regards, -Rob Regards 2013/8/24 Rob Weir robw...@apache.org Hello, and Welcome to the Apache OpenOffice QA Team! I'd recommend that you start with taking a look at our New Volunteer Orientation pages here: http://openoffice.apache.org/orientation/ It is recommended for new volunteers to start with sending a note to the mailing list introducing themselves. Tell us a little bit of who you are, where you are from, any previous experience with OpenOffice or software testing, etc. Thanks! -Rob On Fri, Aug 23, 2013 at 11:50 AM, daf safaa dafsa...@gmail.com wrote: - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Hi I need 'commit rights' so I can confirm the bugs on Bugzilla.
Hello, and Welcome to the Apache OpenOffice QA Team! I'd recommend that you start with taking a look at our New Volunteer Orientation pages here: http://openoffice.apache.org/orientation/ It is recommended for new volunteers to start with sending a note to the mailing list introducing themselves. Tell us a little bit of who you are, where you are from, any previous experience with OpenOffice or software testing, etc. Thanks! -Rob On Fri, Aug 23, 2013 at 11:50 AM, daf safaa dafsa...@gmail.com wrote: - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Is anyone using Apple Pages?
If possible I'd like to get two test files saved from Pages: 1) An Empty document 2) A document that has a simple string, like hello world Both saved in DOC format. I'm seeing some reports claiming that DOC exports from Pages crashes AOO 4.0. I have a complicated example file. But I'd like to see simple ones as well, if possible. If you can create such test documents, please attach them to this BZ issue: https://issues.apache.org/ooo/show_bug.cgi?id=122935 Thanks! -Rob - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Example of spreadsheet formula testing
On Mon, Aug 19, 2013 at 7:47 AM, janI j...@apache.org wrote: On 19 August 2013 13:28, Rob Weir robw...@apache.org wrote: On Mon, Aug 19, 2013 at 6:53 AM, Regina Henschel rb.hensc...@t-online.de wrote: Hi Rob, Rob Weir schrieb: Moving this topic to its own thread. It should be possible to code a very thorough set of test cases in a spreadsheet, without using macros or anything fancy. Just careful reading of the ODF 1.2 specification and simple spreadsheet logic. Reading ODF1.2 specifications will not help for all functions. For example the specification of the Bessel-functions rely on the fact, that interested readers will find the definition other where, using the function names. [I know you will say, write an issue and make a proposal ;)] That's fine. You rely on other sources that are more trusted than the standard or the implementations. Tables of special functions, for example, can be found in books like Abramowicz and Steugen. Also, the NIST's newer Digital Library of Mathematical Functions, which has a nice table of software applications that implement each function: http://dlmf.nist.gov/software/ The main point is that we should not rely on a self-referential definition of a function, automatically taking AOO behavior as the correct behavior. And I would not trust Excel in all cases, since there is ample published criticism of some of their numeric algorithms. So I'd rely more on specialized software. We have a good saying from the the viking times, you need to bake your bread, before you can eat it. Before we get out on a very long math trail (which of course is correct), lets not loose the target. If we just had one or more spreadsheets, that could check that all functions worked like the did yesterday (regression testing), we would have taken a giant step towards automated testing and at the same made better quality and saved tester time to more special problems So in short, lets focus on testing what we have. Assuming it works today is to me a good assumption, and in the few cases where it turns out that it does not, we simply adapt the test spreadsheet. This approach would have the nice benefit, that we can tell our users exactly which functions have changed in a release. As mentioned before, if we make test spreadsheets per the example I gave earlier then you automatically record the current behavior of AOO. It requires no extra work. And you also validate that this is the correct value, which is worth doing as well, though that part does require more work. But in either case a large portion of the work is designing the test so you pick the right input values to fully test the function's behavior, e.g., error cases and other edge values. That is the core essential work, regardless of what kind of automation we use or don't use. That is where the real mental work occurs. -Rob rgds jan I. Regards, -Rob Kind regards Regina - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Example of spreadsheet formula testing
Moving this topic to its own thread. It should be possible to code a very thorough set of test cases in a spreadsheet, without using macros or anything fancy. Just careful reading of the ODF 1.2 specification and simple spreadsheet logic. I'd like to share an example of this that I created for one of the ODF Plugfests. This is a test of a single function -- YEARFRAC. You probably have never touched this function, but it exhibits all the pathological behavior, in a purer form, of the other financial functions. Specifically, it is a pure test of our date counting conventions, the various ways that accountants handle date calculations. The test document is here: http://www.robweir.com/basis-test.xls (I did it in XLS format since I wanted to make sure Microsoft could use it at the Plugfest as well. At that time they were not able to read ODF formulas.) This is likely the most complicated set of test cases of any spreadsheet formula. So if we can test YEARFRAC this way then we can test any function this way. Column C is the formula to evaluate. Column F is the expected value, which is calculated by hand, according to the ODF standard. And colu,mn G reports whether they match or not. (This would be a good place for us to use conditional formatting as well, though in the Plugfest case I needed to make the spreadsheet be as vanilla as possible so every editor could load it) Note that this is an exhaustive set of test cases that aim to test every corner of the formula. It is a torture test. Excel gets all the test cases right. Not a surprise, since we took Excel's behavior as normative when writing this part of the standard. If we used an approach like this on the other spreadsheet functions, we could have a semi-automated test suite that would practically guarantee that Calc is free of calculations errors. Once we're written the test cases, a modest upfront investment, it will benefit us with every release we do. Heck, it would benefit LibreOffice, Gnumeric, Calligra as well, maybe even Microsoft and Google, though they might already have such test cases defined internally. Anyone interesting in helping with this kind of test case development? Any ideas on how to fully automate this? ODF 1.2 is very strict, so we're not starting from a perfect score. But we should find an easy way to report on regressions. -Rob - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Some thoughts on quality
On Thu, Aug 15, 2013 at 6:58 AM, Jürgen Schmidt jogischm...@gmail.com wrote: On 8/15/13 12:19 PM, janI wrote: On Aug 15, 2013 11:14 AM, Jürgen Schmidt jogischm...@gmail.com wrote: On 8/14/13 8:30 PM, Rob Weir wrote: On Wed, Aug 14, 2013 at 1:55 PM, janI j...@apache.org wrote: On 14 August 2013 19:36, Edwin Sharp el...@mail-page.com wrote: Dear Rob The 4.0 release was too ambitious - we should advance in smaller steps. Nothing compares to general public testing - betas and release candidates should not be avoided. TestLink cases should be less comprehesive (in terms of feature coverage) and more stress testing oriented. Regards, Edwin On Wed, Aug 14, 2013, at 19:59, Rob Weir wrote: We're working now on AOO 4.0.1, to fix defects in AOO 4.0.0. The fact that we're doing this, and their are no arguments against it, shows that we value quality. I'd like to take this a step further, and see what we can learn from the defects in AOO 4.0.0 and what we can do going forward to improve. Quality, in the end, is a process, not a state of grace. We improve by working smarter, not working harder. The goal should be to learn and improve, as individuals and as a community. Every regression that made it into 4.0.0 was added there by a programmer. And the defect went undetected by testers. This is not to blame. It just means that we're all human. We know that. We all make mistakes. I make mistakes. A quality process is not about becoming perfect, but about acknowledging that we make mistakes and that certain formal and informal practices are needed to prevent and detect these mistakes. But enough about generalities. I'm hoping you'll join with me in examining the 32 confirmed 4.0.0 regression defects and answering a few questions: 1) What caused the bug? What was the root cause? Note: programmer error is not really a cause. We should ask what caused the error. 2) What can we do to prevent bugs like this from being checked in? 3) Why wasn't the bug found during testing? Was it not covered by any existing test case? Was a test case run but the defect was not recognized? Was the defect introduced into the software after the tests had already been executed? 4) What can we do to ensure that bugs like this are caught during testing? So 2 basic questions -- what went wrong and how can we prevent it in the future, looked at from perspective of programmers and testers. If we can keep these questions in mind, and try to answer them, we may be able to find some patterns that can lead to some process changes for AOO 4.1. You can find the 4.0.0 regressions in Bugzilla here: https://issues.apache.org/ooo/buglist.cgi?cmdtype=doremremaction=runnamedcmd=400_regressionssharer_id=248521list_id=80834 Regards, -Rob I strongly believe that one of the things that went wrong is our limited possibility to retest (due to resources), when I look at our current manual I wonder about that as well. That's one reason it would be good to know how many of the confirmed regressions were introduced late in the release process, and thus missed coverage in our full test pass. testcases, a lot of those could be automated, e.g. with a simple UI macro, that would enable us to run these test cases with every build. It may sound like a dream but where I come from, we did that every night, and it caught a lot of regression bugs and sideeffects. This begs the question: Is the functionality of the regressions covered by our test cases? Or are they covered but we didn't execute them? Or we executed them but didn't recognize the defect? I don't know (yet). A simple start, if to request that every bug fix, is issued with at least one test case (automated or manual). Often there is, though this information lives in Bugzilla. One thing we did on another (non open source) project is to mark defects in our bugtracking system that should become test cases. Not every bug did that. For example, a defect report to update a mispelling in the UI would not lead to a new test case. But many would. we have the automated test framework that needs some more attention and polishing. And of course the tests have to improved to get satisfying result. We have BVT - build verification test FVT - functional verification test PVT - performance verification test SVT - system verification test But I have to confess that I have limited knowledge about it yet I aware that we ha a limited automated framework, at least thats what I found and played with. but, it is not integrated into our build, or our buildbot. Especially testing in buildbot gives better qa. An manually controlled automated test is not really an ideal solution. +1 and I think it was the intended idea behind this, have it run on a regular basis ideally on the build bots. The work is not finished and have to be done as so many open work items. If thet run more stable
Re: Some thoughts on quality
On Thu, Aug 15, 2013 at 8:29 AM, Jürgen Schmidt jogischm...@gmail.com wrote: On 8/15/13 1:33 PM, Rob Weir wrote: On Thu, Aug 15, 2013 at 6:58 AM, Jürgen Schmidt jogischm...@gmail.com wrote: On 8/15/13 12:19 PM, janI wrote: On Aug 15, 2013 11:14 AM, Jürgen Schmidt jogischm...@gmail.com wrote: On 8/14/13 8:30 PM, Rob Weir wrote: On Wed, Aug 14, 2013 at 1:55 PM, janI j...@apache.org wrote: On 14 August 2013 19:36, Edwin Sharp el...@mail-page.com wrote: Dear Rob The 4.0 release was too ambitious - we should advance in smaller steps. Nothing compares to general public testing - betas and release candidates should not be avoided. TestLink cases should be less comprehesive (in terms of feature coverage) and more stress testing oriented. Regards, Edwin On Wed, Aug 14, 2013, at 19:59, Rob Weir wrote: We're working now on AOO 4.0.1, to fix defects in AOO 4.0.0. The fact that we're doing this, and their are no arguments against it, shows that we value quality. I'd like to take this a step further, and see what we can learn from the defects in AOO 4.0.0 and what we can do going forward to improve. Quality, in the end, is a process, not a state of grace. We improve by working smarter, not working harder. The goal should be to learn and improve, as individuals and as a community. Every regression that made it into 4.0.0 was added there by a programmer. And the defect went undetected by testers. This is not to blame. It just means that we're all human. We know that. We all make mistakes. I make mistakes. A quality process is not about becoming perfect, but about acknowledging that we make mistakes and that certain formal and informal practices are needed to prevent and detect these mistakes. But enough about generalities. I'm hoping you'll join with me in examining the 32 confirmed 4.0.0 regression defects and answering a few questions: 1) What caused the bug? What was the root cause? Note: programmer error is not really a cause. We should ask what caused the error. 2) What can we do to prevent bugs like this from being checked in? 3) Why wasn't the bug found during testing? Was it not covered by any existing test case? Was a test case run but the defect was not recognized? Was the defect introduced into the software after the tests had already been executed? 4) What can we do to ensure that bugs like this are caught during testing? So 2 basic questions -- what went wrong and how can we prevent it in the future, looked at from perspective of programmers and testers. If we can keep these questions in mind, and try to answer them, we may be able to find some patterns that can lead to some process changes for AOO 4.1. You can find the 4.0.0 regressions in Bugzilla here: https://issues.apache.org/ooo/buglist.cgi?cmdtype=doremremaction=runnamedcmd=400_regressionssharer_id=248521list_id=80834 Regards, -Rob I strongly believe that one of the things that went wrong is our limited possibility to retest (due to resources), when I look at our current manual I wonder about that as well. That's one reason it would be good to know how many of the confirmed regressions were introduced late in the release process, and thus missed coverage in our full test pass. testcases, a lot of those could be automated, e.g. with a simple UI macro, that would enable us to run these test cases with every build. It may sound like a dream but where I come from, we did that every night, and it caught a lot of regression bugs and sideeffects. This begs the question: Is the functionality of the regressions covered by our test cases? Or are they covered but we didn't execute them? Or we executed them but didn't recognize the defect? I don't know (yet). A simple start, if to request that every bug fix, is issued with at least one test case (automated or manual). Often there is, though this information lives in Bugzilla. One thing we did on another (non open source) project is to mark defects in our bugtracking system that should become test cases. Not every bug did that. For example, a defect report to update a mispelling in the UI would not lead to a new test case. But many would. we have the automated test framework that needs some more attention and polishing. And of course the tests have to improved to get satisfying result. We have BVT - build verification test FVT - functional verification test PVT - performance verification test SVT - system verification test But I have to confess that I have limited knowledge about it yet I aware that we ha a limited automated framework, at least thats what I found and played with. but, it is not integrated into our build, or our buildbot. Especially testing in buildbot gives better qa. An manually controlled automated test is not really an ideal solution. +1 and I think it was the intended idea behind this, have it run on a regular basis ideally
Some thoughts on quality
We're working now on AOO 4.0.1, to fix defects in AOO 4.0.0. The fact that we're doing this, and their are no arguments against it, shows that we value quality. I'd like to take this a step further, and see what we can learn from the defects in AOO 4.0.0 and what we can do going forward to improve. Quality, in the end, is a process, not a state of grace. We improve by working smarter, not working harder. The goal should be to learn and improve, as individuals and as a community. Every regression that made it into 4.0.0 was added there by a programmer. And the defect went undetected by testers. This is not to blame. It just means that we're all human. We know that. We all make mistakes. I make mistakes. A quality process is not about becoming perfect, but about acknowledging that we make mistakes and that certain formal and informal practices are needed to prevent and detect these mistakes. But enough about generalities. I'm hoping you'll join with me in examining the 32 confirmed 4.0.0 regression defects and answering a few questions: 1) What caused the bug? What was the root cause? Note: programmer error is not really a cause. We should ask what caused the error. 2) What can we do to prevent bugs like this from being checked in? 3) Why wasn't the bug found during testing? Was it not covered by any existing test case? Was a test case run but the defect was not recognized? Was the defect introduced into the software after the tests had already been executed? 4) What can we do to ensure that bugs like this are caught during testing? So 2 basic questions -- what went wrong and how can we prevent it in the future, looked at from perspective of programmers and testers. If we can keep these questions in mind, and try to answer them, we may be able to find some patterns that can lead to some process changes for AOO 4.1. You can find the 4.0.0 regressions in Bugzilla here: https://issues.apache.org/ooo/buglist.cgi?cmdtype=doremremaction=runnamedcmd=400_regressionssharer_id=248521list_id=80834 Regards, -Rob - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Some thoughts on quality
I apologize in advance if my note was note clear. I'm not at all interested in off-the-cuff opinions. We all have our opinions. But I'm only interested in fact-based analysis of the actual regressions reported in BZ. Specifically: what caused the actually defects that ended up in 4.0.0 and what could have been done to prevent it. General recommendations, like more time, not backed by specific analysis, are not very useful. And remember, there will never be enough time to improve quality with a suboptimal process. The goal should be (IMHO) to improve the process, i.e., work smarter, not harder. Regards, -Rob On Wed, Aug 14, 2013 at 12:59 PM, Rob Weir robw...@apache.org wrote: We're working now on AOO 4.0.1, to fix defects in AOO 4.0.0. The fact that we're doing this, and their are no arguments against it, shows that we value quality. I'd like to take this a step further, and see what we can learn from the defects in AOO 4.0.0 and what we can do going forward to improve. Quality, in the end, is a process, not a state of grace. We improve by working smarter, not working harder. The goal should be to learn and improve, as individuals and as a community. Every regression that made it into 4.0.0 was added there by a programmer. And the defect went undetected by testers. This is not to blame. It just means that we're all human. We know that. We all make mistakes. I make mistakes. A quality process is not about becoming perfect, but about acknowledging that we make mistakes and that certain formal and informal practices are needed to prevent and detect these mistakes. But enough about generalities. I'm hoping you'll join with me in examining the 32 confirmed 4.0.0 regression defects and answering a few questions: 1) What caused the bug? What was the root cause? Note: programmer error is not really a cause. We should ask what caused the error. 2) What can we do to prevent bugs like this from being checked in? 3) Why wasn't the bug found during testing? Was it not covered by any existing test case? Was a test case run but the defect was not recognized? Was the defect introduced into the software after the tests had already been executed? 4) What can we do to ensure that bugs like this are caught during testing? So 2 basic questions -- what went wrong and how can we prevent it in the future, looked at from perspective of programmers and testers. If we can keep these questions in mind, and try to answer them, we may be able to find some patterns that can lead to some process changes for AOO 4.1. You can find the 4.0.0 regressions in Bugzilla here: https://issues.apache.org/ooo/buglist.cgi?cmdtype=doremremaction=runnamedcmd=400_regressionssharer_id=248521list_id=80834 Regards, -Rob - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Some thoughts on quality
On Wed, Aug 14, 2013 at 1:55 PM, janI j...@apache.org wrote: On 14 August 2013 19:36, Edwin Sharp el...@mail-page.com wrote: Dear Rob The 4.0 release was too ambitious - we should advance in smaller steps. Nothing compares to general public testing - betas and release candidates should not be avoided. TestLink cases should be less comprehesive (in terms of feature coverage) and more stress testing oriented. Regards, Edwin On Wed, Aug 14, 2013, at 19:59, Rob Weir wrote: We're working now on AOO 4.0.1, to fix defects in AOO 4.0.0. The fact that we're doing this, and their are no arguments against it, shows that we value quality. I'd like to take this a step further, and see what we can learn from the defects in AOO 4.0.0 and what we can do going forward to improve. Quality, in the end, is a process, not a state of grace. We improve by working smarter, not working harder. The goal should be to learn and improve, as individuals and as a community. Every regression that made it into 4.0.0 was added there by a programmer. And the defect went undetected by testers. This is not to blame. It just means that we're all human. We know that. We all make mistakes. I make mistakes. A quality process is not about becoming perfect, but about acknowledging that we make mistakes and that certain formal and informal practices are needed to prevent and detect these mistakes. But enough about generalities. I'm hoping you'll join with me in examining the 32 confirmed 4.0.0 regression defects and answering a few questions: 1) What caused the bug? What was the root cause? Note: programmer error is not really a cause. We should ask what caused the error. 2) What can we do to prevent bugs like this from being checked in? 3) Why wasn't the bug found during testing? Was it not covered by any existing test case? Was a test case run but the defect was not recognized? Was the defect introduced into the software after the tests had already been executed? 4) What can we do to ensure that bugs like this are caught during testing? So 2 basic questions -- what went wrong and how can we prevent it in the future, looked at from perspective of programmers and testers. If we can keep these questions in mind, and try to answer them, we may be able to find some patterns that can lead to some process changes for AOO 4.1. You can find the 4.0.0 regressions in Bugzilla here: https://issues.apache.org/ooo/buglist.cgi?cmdtype=doremremaction=runnamedcmd=400_regressionssharer_id=248521list_id=80834 Regards, -Rob I strongly believe that one of the things that went wrong is our limited possibility to retest (due to resources), when I look at our current manual I wonder about that as well. That's one reason it would be good to know how many of the confirmed regressions were introduced late in the release process, and thus missed coverage in our full test pass. testcases, a lot of those could be automated, e.g. with a simple UI macro, that would enable us to run these test cases with every build. It may sound like a dream but where I come from, we did that every night, and it caught a lot of regression bugs and sideeffects. This begs the question: Is the functionality of the regressions covered by our test cases? Or are they covered but we didn't execute them? Or we executed them but didn't recognize the defect? I don't know (yet). A simple start, if to request that every bug fix, is issued with at least one test case (automated or manual). Often there is, though this information lives in Bugzilla. One thing we did on another (non open source) project is to mark defects in our bugtracking system that should become test cases. Not every bug did that. For example, a defect report to update a mispelling in the UI would not lead to a new test case. But many would. Regards, -Rob rgds jan I. - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Requesting privileges to the QA list
On Tue, Aug 13, 2013 at 5:52 AM, Marco A.G.Pinto marcoagpi...@mail.telepac.pt wrote: Hello! I want to help, give me rights, my e-mail is: marcoagpi...@mail.telepac.pt Done. Thanks! -Rob [10:36] JZA you do need to request priviledges to the qa list [10:36] JZA we have that documented on the introductory modules for QA [10:37] JZA is just saying I want to help, please give me righs, my email is [10:37] JZA u'll get it in a day, and be ready to go. Thanks! Kind regards, Marco A.G.Pinto --- --
Re: COMDEV-76 [GSoC] Test Document Generator/Permutator for Apache OpenOffice
On Tue, Aug 13, 2013 at 11:42 AM, Sony Kovoor sonyckov...@gmail.com wrote:
Hi all,
I am an open source enthusiast and when I heard about ASF Mentoring
program[1] conducted in association with ICFOSS[2] in India by Luciano
Resende[3], i attended it
As a part of the program, we have to take up an idea from 2013 ICFOSS
Programme Project Ideas JIRA[4] and solve it under a formal mentor. I have
submitted my proposal for COMDEV 76[5] [6] and was approved.
Hi Sony,
Welcome to the QA team. I'm looking forward to working with you on
this project.
So before starting the work, i would like to do a brief analysis of the
present strategies and testing systems. So if any one could briefly explain
the present testing system, it would be of great help. Also i would like to
know what you expect from a Test Document Generator/Permutator.
The current formal testing is done using test management system called
TestLink. It lists steps for the tester to attempt, along with the
expected results. A test case, for example, could say to load a
particular document file and verify that it renders correctly. There
are 100's of test cases which we try to run on all of our supported
platforms for each release.
A document generator could help us make more test documents,
especially ones that would be difficult to create by hand.
To understand why it is good to think of what makes a good QA test
case. Suppose you have a program that is a simple 4-function
calculator applications. There are an infinite number of possible
test cases. So you cannot test everything. So what test cases would
you try?
An experienced QA expert would do three main things:
1) Write some test cases for the main stream functionality, e.g., 1+2,
4/2.3, 5*6.2, 0-17.2
2) Test the error handling of the application, e.g., 0/0, 1/0, -+-3//2, etc.
3) Test the limits and the edge cases, e.g, tests with extremely
long expressions, deeply nested parentheses, extremely large and small
numbers, etc.
Everyone knows to test the cases in #1, but the other two are key,
This is what it means to think like a bug. These are the areas
where developers are most likely to make errors. Every competent
programmer will get the mainstream functionality correct. But the
edge cases, these are where the bugs often are.
So what does this mean for an application like OpenOffice? What are
our limits and edge cases?
I think of things like:
1) Extremely long documents
2) Documents with very large number of styles
3) Documents with deeply nested lists
4) Documents that use every color in the color palette
5) Documents that have 100 footnotes on a single page.
6) Documents that use every system font available
Things like that.
It would be wonderful to have a tool that could be used, with very
little programmer required, for testers to generate test documents
like this.
It is even possible to generate mainstream test cases in some cases.
For example, with spreadsheet functions. A trivial example. the OR()
function takes a list of parameters and returns TRUE if any one of
the parameters evaluates to TRUE, otherwise it returns FALSE. So
OR('B''A';0;-1) will return TRUE.
It should be possible, to describe the arguments of a spreadsheet
function formally and then to generate numerous test cases for it,
including edge cases and limits tests.
Regina (cc'ed) might have some ideas here as well regarding
spreadsheet function testing.
Regards,
-Rob
All your valuable suggestions would be of a great help.
Thanking you all,
Regards,
[1] http://community.apache.org/mentoringprogramme-icfoss-pilot.html
[2] http://icfoss.org/
[3] http://people.apache.org/~lresende
[4] https://issues.apache.org/jira/issues/?filter=12324056
[5] https://issues.apache.org/jira/browse/COMDEV-76
[6]
https://cwiki.apache.org/confluence/display/COMDEV/Test+Document+Generator+or+Permutator+for+Apache+OpenOffice
--
Sony Cyriac
Kovoor Puthen Purayil
E Mail : sonyckov...@gmail.com
-
To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org
For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: [QA]
On Sat, Aug 10, 2013 at 8:46 PM, Camelia Brown cambrownapa...@gmail.com wrote: My Bugzilla ID is cambrownapa...@gmail.com. I'm running Windows 7, but I also downloaded the Virtual Box program so I'm capable of testing for other OS. Hello Camelia , I've added you to the qa-team in Bugzilla. You should not have permissions to edit bug reports. Regards, -Rob On Sat, Aug 10, 2013 at 12:48 PM, Alexandro Colorado j...@oooes.org wrote: You might want to check this email 5 days ago from Yuzen --- Currently we have about 45 unconfirmed bugs in 4.0[1], if you have interest in joining the bug confirmation work, could you please let me know your Bugzilla ID and platforms you have, I will assign bugs to you. Thanks very much! [1] https://issues.apache.org/ooo/buglist.cgi?cmdtype=doremremaction=runnamedcmd=Unconfirmed_Defects_on_4.0sharer_id=249089list_id=78518 --- Good Luck On Fri, Aug 9, 2013 at 7:26 PM, Camelia Brown cambrownapa...@gmail.com wrote: I'm requesting to be added to the Bugzilla qa-team group. I would also like to request a small batch of reports to start off with if possible. Thank you. - C.C. -- Alexandro Colorado Apache OpenOffice Contributor http://www.openoffice.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Call for volunteers to confirm 4.0 defects
On Wed, Aug 7, 2013 at 6:47 AM, Yuzhen Fan fanyuz...@gmail.com wrote: Hi Edoardo, Edwin(Thanks!) confirms bug 122818 for you in BZ. Please let us know if any other bugs you want us to confirm for you in BZ, thanks! Rob, could you please help to check Edoardo's permission in BZ, as he can only see unconfirmed and resolved in status combobox. His BZ account is edoa...@aspix.it,Thank you! Edoardo, please try again now. I enhanced your permissions in Bugzilla, adding you to the qa-team group. -Rob Regards, Yu Zhen On Wed, Aug 7, 2013 at 2:52 AM, Edoardo Panfili edoa...@aspix.it wrote: Il 07/08/13 11:27, Edwin Sharp ha scritto: 122818 status can be set to unconfirmed, confirmed, accepted, resolved. Let me know if I can help with these bugs. excuse me, maybe I am doing something wrong! After the box Additional Comments: I can see the status combobox, inside the combo I can see only unconfirmed and resolved can you confirm the bug for me? thank you Edoardo On Wed, Aug 7, 2013, at 12:21, Edoardo Panfili wrote: Il 07/08/13 10:47, Edwin Sharp ha scritto: Bug number? for example 122818 but all the bug assignet to me as qa contact ( 122806, 122807, 122811, 122818, 122839, 122861, 122876, 122951, 122960) thank you Edoardo On Wed, Aug 7, 2013, at 11:22, Edoardo Panfili wrote: I need to confirm a bug but in bugzilla I can set the status only to unconfirmed or to resolved Edoardo - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Updating BZ versions for next releases
I'd like to update BZ to reflect the next release of AOO. Version are tracked in three different fields: Version, which currently allows the values AOO 4.0.0 and AOO410-dev Target Milestone, which currently allows the values AOO 4.0, AOO 4.1 and AOO PleaseHelp Last Confirmation on, which currently allows the values AOO 3.4.0, AOO 3.4.1, and AOO 4.0.0. I'd like to clean this up a little, as follows: 1) It is reasonable for someone to report a bug using 3.4.0, 3.4.1 or 4.0.0. None of these versions are end of life so they should be allowed for new bug reports. 2) I don't see the purpose of AOO PleaseHelp as a milestone version. Are we overloading meaning in this field? If we really need track issues that need help we should define a keyword for this. So I'm inclined to delete this milestone version number. 3) I'd also like to simplify the versions across the board to be just 3.4.1, 4.0.0, etc., without the AOO prefix. 4) For Last Confirmation On, I'd like to hide values except for 4.0. We should not be confirming bugs without testing on the most recent version. Sure, new bugs can set Version to 3.4.0 or 3.4.1, but confirmation should occur on 4.0. 5) I'll add a new Target Milestone of 4.0.1 and Version of 4.0.1-dev since it is likely that we will have a 4.0.1 release to address some of the defects that have been reported on 4.0.0. I'd love to hear your thoughts on this, even if it is just a quick +1. I'll hold off making any of these changes until this time Thursday. Regards, -Rob - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Updating BZ versions for next releases
On Mon, Aug 5, 2013 at 12:06 PM, Andrea Pescetti pesce...@apache.org wrote: On 05/08/2013 Rob Weir wrote: I'd love to hear your thoughts on this, even if it is just a quick +1. Here's my quick +1, with a question: when I report a bug (typically a small regression) that I would like to see fixed in the possible 4.0.1 release, shall I already set the Target to 4.0.1? In ancient times this was left to the developer who had accepted the bug, but we are now less strict in Bugzilla usage. And setting the target to 4.0.1 would help in evaluating if/when we need a 4.0.1. That question probably deserves its own thread. IMHO we need to decide what a 4.0.1 is: 1) We might want to have it contain fixes for only the most urgent bugs. We could include new translations that are available as well. If we make that restriction then the QA impact is less. We don't need to do a complete regression test pass. If we did that then we could use the release blocker field to track these issues. We'd only fix issues in 4.0.1 that have been discussed as release blockers. 2) Or we could open 4.0.1 up to all changes, in which case new bugs can be introduced anywhere, possible translation impact, etc. Personally I think 4.0.1 should be more like #1 -- strictly limited to specific bug fixes. We then use 4.1 (the trunk) for non-urgent fixes. -Rob Regards, Andrea. - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Updating BZ versions for next releases
On Mon, Aug 5, 2013 at 12:42 PM, Marcus (OOo) marcus.m...@wtnet.de wrote: Am 08/05/2013 06:31 PM, schrieb Rob Weir: On Mon, Aug 5, 2013 at 12:07 PM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 08/05/2013 05:47 PM, schrieb janI: On 5 August 2013 17:38, Rob Weirrobw...@apache.org wrote: I'd like to update BZ to reflect the next release of AOO. Version are tracked in three different fields: Version, which currently allows the values AOO 4.0.0 and AOO410-dev Target Milestone, which currently allows the values AOO 4.0, AOO 4.1 and AOO PleaseHelp Last Confirmation on, which currently allows the values AOO 3.4.0, AOO 3.4.1, and AOO 4.0.0. I'd like to clean this up a little, as follows: 1) It is reasonable for someone to report a bug using 3.4.0, 3.4.1 or 4.0.0. None of these versions are end of life so they should be allowed for new bug reports. +1 2) I don't see the purpose of AOO PleaseHelp as a milestone version. Are we overloading meaning in this field? If we really need track issues that need help we should define a keyword for this. So I'm inclined to delete this milestone version number. If it's possible to delete the item without to leave gaps in the issues itself then +1. 3) I'd also like to simplify the versions across the board to be just 3.4.1, 4.0.0, etc., without the AOO prefix. +1 4) For Last Confirmation On, I'd like to hide values except for 4.0. We should not be confirming bugs without testing on the most recent version. Sure, new bugs can set Version to 3.4.0 or 3.4.1, but confirmation should occur on 4.0. Since 3.4.0 and 3.4.1 (I actually thought it was only 3.4.1) are live version, which we support, all bugs reported there must also be tested there. I agree they should also be tested in 4.0, but not only in 4.0. So we would actually need a double confirmation, 3.4.x and 4.0 ? Current field is a single-selection drop down. BZ does allow multiple-selection fields, but I don't see any way to switch the type of a field once it has been used. In any case I'm not inviting debate of the process. I appreciate that You asked for feedback. ;-) I appreciate that some might wish that the QA volunteers spent twice as much time and tested on twice as many versions of AOO. But changing a BZ field obviously doesn't cause that to happen. My intent was merely to I don't wish this. If they do it, they do it on their own. I believe there is also a way sometimes to trust the user or developer when they choose 3.4.1 and 4.0.0 as confirmed versions. update the field to support the purpose the field was added in the first place, to track the most-recent version of AOO the bug was confirmed on. OK, looking at the title of the field then indeed only one version is possible. However, I still think there is a value add to have the confirmation that a bug is occurring in more than just the most recent version. It can be useful in some cases. If you can identify the last version that did not have the defect, and the first version that did have the defect, then you can narrow down the range of commits that could have caused the bug. Unfortunately I don't see an admin-accessible way to change the field type. In theory someone could work with Infra to get direct DB access and create a new multi-value field and then write some SQL to migrate the old values into the multi-value schema. But I'm not sure that would have much more value than noting these facts in a comment field. In terms of workflow, searching for all confirmed bugs that have not been tested with at least 3.4.0 is useful. It gives us a list of bugs that we should re-test. But I'm not sure why I would search for bugs that were confirmed in a specific old version like 3.4.0. -Rob Marcus Right, to recognize a regression faster it should be possible to set the values to 3.4.1 and 4.0.0 (is it possible to enable multiselection for this field?). Then you can see on the first view that the issue is not a new thing in 4.0.0 but was already exisiting also in 3.4.1. 5) I'll add a new Target Milestone of 4.0.1 and Version of 4.0.1-dev since it is likely that we will have a 4.0.1 release to address some of the defects that have been reported on 4.0.0. +1 Then we can separate easily: - fast fixed for 4.0.1 - general new things for 4.1.0 I'd love to hear your thoughts on this, even if it is just a quick +1. I'll hold off making any of these changes until this time Thursday. +1 to all except 4). I agree with Jan. Marcus - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
It is time to update your entry in the Directory of Volunteers
Make sure you are included in our Directory of Volunteers and that the information is as you want it to appear: https://cwiki.apache.org/confluence/display/OOOUSERS/Directory+of+Volunteers This page is linked to (indirectly) from the credits link of the Help/About dialog box in AOO 4.0. It will also be mentioned in release announcements. You can sign up for a wiki account, or send your information directly to me and I will add it for you. Regards, -Rob - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Getting started with OpenOffice Base (tutorial)
I think one of the challenges of testing OpenOffice Base is that not many people use it. We're all familiar with word processors, spreadsheets and presentations, but not everyone uses databases. I look on the wiki for QA Testing Preferences: https://cwiki.apache.org/confluence/display/OOOUSERS/QA+Testing+Preferences And I see that almost no one says they know Base, but many say they are willing to learn. Well Now is the time to learn ;-) I looked around for good tutorials and saw many recomendations for Base Tutorial: From Newbie to Advocate in a one, two... three! by Mariano Casanova: http://forum.openoffice.org/en/forum/viewtopic.php?p=201074#p201074 So maybe we can accomplish two things at once? If a few of us work through the tutorial on AOO 4.0, then we can teach ourselves Base, while testing the functionality described in the tutorial at the same time. What do you think? Who can help? -Rob - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Triage for AOO 4.0.0 Release Blockers
On Fri, Jun 21, 2013 at 11:09 AM, Sub Phil phil40...@gmail.com wrote: Bug policy debate and so on.. Well, just sharing experience from as a past developper and notorious bug fighter. There is no other point in creating a database of bugs and not treating them, than to have an ultra-complicated list of known issues (so complex that users report are duplicated) and frustrated reporters (and testers). It is no a display of disrespect when a certain bug is not fixed. Yes until you have a list of open bugs, which generated itself a list of duplicates... What matters is the evolution ratio closed / confirmed by release (e.g. 3.4.1) and cumulated version (3.4.x). Metrics like this could be useful if we're measuring defects not defect reports. Unfortunately the duplicates, plus the how do I? and other non-defects that users enter , make this difficult to estimate. My impression is that close to half of the Bugzilla reports are invalid. We'd need to do a major clean up of Bugzilla before we even knew how many actual defects are there. I would like to add another one. I am a developer. When I spend time on fixing bugs then I sometimes wish there where a big list of all open bugs that are sorted according to importance. I would go down the list and grab a bug from the top that lies in the area of my expertise (Impress, UI, Slideshow, Sidebar). Without such a list I have to prioritize bugs by myself. And if I do that then I use my own judgement of which bug is important and which is not. To the extent that rated priority is a motivation to volunteers, this is true. But we have all sorts of volunteers. I think some of them have enough stress in their real lives that they don't want to take high priority issues and world rather work on lower priority ones, where there is less urgency. Also, much of this depends on where we are in the release. Once we have completed regression testing we want to avoid introducing additional risk. So it is no longer open season for fixing just any defect. We need to weigh the risks involved. In many cases, for less serious bugs, we fix them in a later release, so they can undergo a full test pass. This further illustrate the fact that in order to handle these list, one has introduced techniques such as priority and vote for bug. My own experience shows, that all these are not good policy for bug treatment, it's a dispair. Prioritization is not despair. It is just acknowledging that changing the code after testing has completed is risky, and that we should only make changes now where absolutely necessary. Despair is what users feel when we don't show such precautions and see a last minute fix introduce a serious bug that is not caught before release. Bug should be assigned in groups regarding a feature with final objective in mind. What do I mean by feature. Take for instance in Calc, the pivot table function. All bug regarding pivot table should be treated together, or most of them. Why concentrating? Because: 1/ It takes time to fix a bug, because one needs to understand or re-understand the implementation. - Fixing a bug usually takes a lot more time and effort than reporting one. Also, often because test case scenario are not narrow enough - see my other post. 2/ By taking all bugs related to a piece of source code, each time you become more familliar and so more efficient. In a sense you proof reading it several times, you get leverage on bug handling. 3/ By reviewing several related bugs, you reduce the risk or regression, as you've been through it several times, each time with a deeper understanding. This is a good practice to follow, before the main test pass completes. After than we intentionally aim to minimize the changes to the code. Otherwise we don't have a good sense of what the quality is we're release. Bugs are bad, but with testing we can at least have a degree of confidence that there are no defects above a certain severity level. If we make unrestrained changes after the test pass then our degree of confidence is reduced or eliminated. The other thing to note is that bug fixes are not risk-free. Studies have shown that 25% of defects in code are side effects of changes. FFmpeg is really a good example for regression, to a point I stopped reporting (first you have to convince it's a bug, then it lays pending to a wish to fix it and then you find older release which works...) I know it can be frustrating as a tester to see defects you reported go unfixed in a release. I've been there. 4/ Having fixed a bulk of related feature bugs, report the fix is implemented to all different reporters. They will(hopefully if done in a reasonable time, not like me who got a mail for a bug I posted 2 years ago...) test their bug and by doing so improve the total quality control and reduce regression risk. What do I mean by assigning by objective. Well, here is for me where the votes should
Re: Triage for AOO 4.0.0 Release Blockers
On Fri, Jun 7, 2013 at 10:34 AM, I. Park ipark...@gmail.com wrote: Hello Rob, O.k., I'm not too sure if your incorrectly marked CONFIRMED topic mentioned below has to do with Bugzilla, but I noticed on couple occasions that when filling out new bugs the CONFIRMED is set by default. I had to go back a few times and change it to UNCONFIRMED. That's fine. When a tester enters a new bug it probably should be marked CONFIRMED. That's because testers know what they are doing and would only enter a bug report for a bug that was real and reproducible. -Rob Just my two-cents. I. Park On Thu, Jun 6, 2013 at 8:33 PM, Rob Weir robw...@apache.org wrote: On Thu, Jun 6, 2013 at 8:47 AM, Jürgen Schmidt jogischm...@gmail.com wrote: On 6/6/13 1:54 PM, Yuzhen Fan wrote: Hi All, Here is the list of identified candidates[1]/[2] which are proposed to be 4.0.0 release blockers. Please indicate your selections for release blockers by giving 1 vote to 1 bug (the vote field is beside the importance field, in a bug form). We hope to get the vote score this week, any bugs you think most critical to you, please bring out and let's discuss. Please wait, I think we have not agreed on this approach. Voting in the issue is not really helpful. I believe many of these issues can be removed from list and are probably not valid at all. I prefer to discuss showstopper issues on the list as we did for AOO 3.4. With 3.4 we proposed each release blocker on the list, in its own thread, right? But it is not going the be much better if we start with 90 new threads. It looks like all the proposed release blockers are marked confirmed. A few of them pre-date AOO 3.4, but most are more recent. But with a further look I see some were incorrectly marked CONFIRMED. I think some volunteers when they first started set that field after trying to confirm a defect, without understanding that this state should only set if the confirmation test was successful. So we need to review the comments on each bug to see which ones are actually reproduced.I'll try to clean up a few tonight while I watch TV. Also, we probably need to prioritize. For example, a shallow crash (a crash in a common. top-level operation) is higher priority than a crash that only occurs with a specific malformed document. -Rob Juergen [1] https://issues.apache.org/ooo/buglist.cgi?cmdtype=doremremaction=runnamedcmd=4.0.0_release_blocker%3Fsharer_id=249289list_id=64740 [2] Also attach the file for the list (AOO4.0.0_release_blocker_candidates.ods) Regards, Yu Zhen - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Reminder: Ask if you need additional permissions in Bugzilla
On Thu, Jun 6, 2013 at 8:49 AM, Davide Piva davide.p...@gmail.com wrote: Hi Rob. I subscribed to the list to inform the team about a number of issues I've noticed of in OO.org. I would like this sofware be improved but, first of all, the big or small problems in it be solved. I have no time to spent for the routine tests (unfortunately), but I would like to partecipate to the release 4. I guess the suite is at a good stage of performance but it still has a number of things to change or add, for example the tables styles management. Please let me know, if you can, to which person/group I have to address my observations. Hello Davide, If you sign up for a Bugzilla account you can enter your issues there: https://issues.apache.org/ooo/ The mailing lists, like this one, are good for discussions, but the information is lost over time. So best is to get specific issues entered into Bugzilla, so we can better track them. Regards, -Rob Thanks. Davide Piva 2013/5/28 Rob Weir robw...@apache.org Default user permissions in Bugzilla permit you to enter issue reports and enter comments on issue reports. But, by default, you cannot change the status of an issue report, e.g., mark an issue as confirmed or resolved. However, if you are a committer and associate your BZ account with your *.apache.org email address, then you automatically get additional permissions. Also, any other volunteer is welcome to request additional permissions. We have a qa-team group in Bugzilla. When added to that group you have permissions to modify issues in BZ. This is highly recommended for anyone active in Dev or QA. If you need these additional permissions, please let me know. If you send me your email address as used in Bugzilla I can add you. Regards, -Rob - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Triage for AOO 4.0.0 Release Blockers
On Thu, Jun 6, 2013 at 8:47 AM, Jürgen Schmidt jogischm...@gmail.com wrote: On 6/6/13 1:54 PM, Yuzhen Fan wrote: Hi All, Here is the list of identified candidates[1]/[2] which are proposed to be 4.0.0 release blockers. Please indicate your selections for release blockers by giving 1 vote to 1 bug (the vote field is beside the importance field, in a bug form). We hope to get the vote score this week, any bugs you think most critical to you, please bring out and let's discuss. Please wait, I think we have not agreed on this approach. Voting in the issue is not really helpful. I believe many of these issues can be removed from list and are probably not valid at all. I prefer to discuss showstopper issues on the list as we did for AOO 3.4. With 3.4 we proposed each release blocker on the list, in its own thread, right? But it is not going the be much better if we start with 90 new threads. It looks like all the proposed release blockers are marked confirmed. A few of them pre-date AOO 3.4, but most are more recent. But with a further look I see some were incorrectly marked CONFIRMED. I think some volunteers when they first started set that field after trying to confirm a defect, without understanding that this state should only set if the confirmation test was successful. So we need to review the comments on each bug to see which ones are actually reproduced.I'll try to clean up a few tonight while I watch TV. Also, we probably need to prioritize. For example, a shallow crash (a crash in a common. top-level operation) is higher priority than a crash that only occurs with a specific malformed document. -Rob Juergen [1] https://issues.apache.org/ooo/buglist.cgi?cmdtype=doremremaction=runnamedcmd=4.0.0_release_blocker%3Fsharer_id=249289list_id=64740 [2] Also attach the file for the list (AOO4.0.0_release_blocker_candidates.ods) Regards, Yu Zhen - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Changes to Defect Resolutions strings
We received some feedback that the resolution status INVALID was seen as being too strong a term. We don't want to discourage bug reports and calling a report Invalid could give the wrong impression. So I've change that string to NOTABUG (Not a Bug) which is softer, but expresses the same idea, namely that the defect report does not actually report a bug. It might be a user confused about how a a feature works, or asking a how to question or something like that. Also, I've added a new resolution category OBSOLETE. This is for cases where we have an old defect report that references functionality that no longer exists. For example, there are many reports about the old Kenai infrastructure at OpenOffice.org. These reports, even if valid at the time, are now obsolete. Regards, -Rob - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Need QA (test) volunteers on Mac
It looks like the QA team is making great progress with testing Apache OpenOffice 4.0 on Windows. But they need more help on Mac. Another few volunteers would make a big difference here. We're looking for people who can spend a few hours over the next week or two to run specific, pre-defined test cases their Mac, and to enter Bugzilla issues for any failed test cases. This is a nice, gentle introduction to formal QA. No previous experience with QA is necessary, though good familiarity with OpenOffice from a user perspective is recommended. If you can help, please send a note to the QA mailing list at: qa@openoffice.apache.org Thanks! -Rob - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Need QA (test) volunteers on Mac
On Fri, May 17, 2013 at 10:44 AM, Kadal Amutham vka...@gmail.com wrote: I think the prerequisite for the volunteers is to have a Mac machine. I do not have a mac machine. Can I volunteer? There are still tests that need to be run on Windows and Linux as well, if you want to help there. But our larges gap currently is on Mac. -Rob With Warm Regards V.Kadal Amutham 919444360480 914422396480 On 17 May 2013 19:52, Rob Weir robw...@apache.org wrote: It looks like the QA team is making great progress with testing Apache OpenOffice 4.0 on Windows. But they need more help on Mac. Another few volunteers would make a big difference here. We're looking for people who can spend a few hours over the next week or two to run specific, pre-defined test cases their Mac, and to enter Bugzilla issues for any failed test cases. This is a nice, gentle introduction to formal QA. No previous experience with QA is necessary, though good familiarity with OpenOffice from a user perspective is recommended. If you can help, please send a note to the QA mailing list at: qa@openoffice.apache.org Thanks! -Rob - To unsubscribe, e-mail: users-unsubscr...@openoffice.apache.org For additional commands, e-mail: users-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Start AOO 4.0 Full Regression Test - missing keyboard navigation and accelerators in test cases
On Tue, May 7, 2013 at 11:46 AM, V Stuart Foote vstuart.fo...@utsa.edu wrote: Shenfeng, Yuzhen, Liuping, Rob Took a moment and browsed through the TestLink test cases for the Full Regression and earlier test plans against the trunk and sidebar branch. Unless I completely missed seeing it, one noticeable omission from the test cases in general is a lack keyboard based navigation and use of accelerators. Would expect that to be a significant component of functional testing. Only testing with mouse and menu based usage is unfortunately a way to miss the framework needed for accessibility and Assistive Technology support and impact all the supported OS builds. Not just the work on the IA2 branch. So what would you recommend? Is this something you can help with, on the test definition or execution side? My naive approach would be, Make sure you can perform all test cases with just the keyboard. Or is there a more targeted way to do this? A regression test (as opposed to a full functional test) tries to be smart about coverage and focuses on the areas that have changed in the most recent version. In other words, it puts the effort where the risk is greatest. So, given what we know about AOO 3.4.1 keyboard support, and knowing what was changed in AOO 4.0, my guess would be the area to focus on would be the sidebar, yes? Translations are another area where I bet there is risk introduced. It is always possible for an accelerator collision to be introduced accidentally during translation. And the translations come in rather late in the process, after most testing. I wonder if we have any automated ways of detecting collisions? Any other areas that would make sense to focus on? Regards, -Rob Stuart San Antonio, Texas From: Shenfeng Liu [liush...@gmail.com] Sent: Tuesday, May 07, 2013 8:28 AM To: qa@openoffice.apache.org; d...@openoffice.apache.org Subject: Start AOO 4.0 Full Regression Test Yu Zhen Liu Ping, Thanks very much for your help to prepare for the test guidance! Now we have the latest dev snapshot build here: https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds#DevelopmentSnapshotBuilds-AOOSnapshotfullsets And we have the AOO 4.0 Full Regression Test test plan created in Testlink: http://aootesting.adfinis-sygroup.org/index.php . And we have test guidance here: https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+Full+Regression+Test+Guidance and here: https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+Defect+Verification+Guidance So I suggest we start the AOO 4.0 Full Regression Test now ! The test focus of this test circle include the following: (1) Basic Function Verification (2) MS Interoperability Test (3) 2nd phase of sidebar testing (4) Defect verification We will add more test cases (e.g. the Upgrade Check) in later circle. We already got some volunteers replied in mail list. Thanks very much! Will assign test cases in Testlink and send mail to you one by one. And looking forward more people to join and help the testing! - Shenfeng (Simon) - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Start AOO 4.0 Full Regression Test - missing keyboard navigation and accelerators in test cases
On Tue, May 7, 2013 at 3:42 PM, janI j...@apache.org wrote: On 7 May 2013 21:31, Rob Weir robw...@apache.org wrote: On Tue, May 7, 2013 at 11:46 AM, V Stuart Foote vstuart.fo...@utsa.edu wrote: Shenfeng, Yuzhen, Liuping, Rob Took a moment and browsed through the TestLink test cases for the Full Regression and earlier test plans against the trunk and sidebar branch. Unless I completely missed seeing it, one noticeable omission from the test cases in general is a lack keyboard based navigation and use of accelerators. Would expect that to be a significant component of functional testing. Only testing with mouse and menu based usage is unfortunately a way to miss the framework needed for accessibility and Assistive Technology support and impact all the supported OS builds. Not just the work on the IA2 branch. So what would you recommend? Is this something you can help with, on the test definition or execution side? My naive approach would be, Make sure you can perform all test cases with just the keyboard. Or is there a more targeted way to do this? A regression test (as opposed to a full functional test) tries to be smart about coverage and focuses on the areas that have changed in the most recent version. In other words, it puts the effort where the risk is greatest. Sounds like a good approach to me just with the keyboard. I hope that for all automated testing we only use full functional test. With human resources involved regression testing is understandable. The regression test is a manual test, not an automated one. Automated tests are smoke tests and have even less coverage than the regression tests. So automation, at least what we have now, is not going to solve this problem. So, given what we know about AOO 3.4.1 keyboard support, and knowing what was changed in AOO 4.0, my guess would be the area to focus on would be the sidebar, yes? Translations are another area where I bet there is risk introduced. It is always possible for an accelerator collision to be introduced accidentally during translation. And the translations come in rather late in the process, after most testing. I wonder if we have any automated ways of detecting collisions? if/when we have keyboard automated testing, it would be an easy job to write a script that maps the keyboard and accellerators to any language. That would allow us to run the same tests in any language. I was hoping for something closer to present capabilities. For example, accelerators are defined in resource files, yes? It should be possible to analyze the resources files directly to see if there is a collision within any menu item. In theory. Based on my experience from international software, menus and accellerators are common translation problems. Yes. Any other areas that would make sense to focus on? Installation with a keyboard only, or automated installation I didn't think the install UI changed in 4.0, did it? When I say focus I'm reasoning like this: 1) No product of the size and complexity of AOO is able to be fully tested, in any formal sense (line coverage, path coverage, etc.) 2) So we rely on a good sample of possible test cases that give good overall coverage, combined with more focused testing on areas where we think there is higher risk because of recent code changes. 3) There are many areas that are important to specific users: performance, running on a server, users with bidirectional writing scripts, users with East Asian writing styles, users on older versions of Windows versus newest versions of Linux, etc., And keyboard use as well. We can't do every test in every combination. (What about Windows 8 Hebrew users without a mouse?) So we need to figure out the best combination of tests that give good overall coverage. 4) To make the problem tractable areas that have not changed in AOO 4.0 will get less test coverage. Not the same as no coverage, since bugs can have strange interactions. But lacking 100% automated test suites with perfect coverage, infinite volunteers or infinite time, we need to figure out where to spend the time to find the most critical bugs. Where are those bugs? I'm thinking they are not in the install UI. But who knows... -Rob rgds Jan I. Regards, -Rob Stuart San Antonio, Texas From: Shenfeng Liu [liush...@gmail.com] Sent: Tuesday, May 07, 2013 8:28 AM To: qa@openoffice.apache.org; d...@openoffice.apache.org Subject: Start AOO 4.0 Full Regression Test Yu Zhen Liu Ping, Thanks very much for your help to prepare for the test guidance! Now we have the latest dev snapshot build here: https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds#DevelopmentSnapshotBuilds-AOOSnapshotfullsets And we have the AOO 4.0 Full Regression Test test plan created in Testlink: http://aootesting.adfinis-sygroup.org
Testing AOO 4.0 Upgrades
What do we need to do to test AOO 4.0 - AOO 4.1 upgrade scenario? Is it possible to put an update XML file on the server so we can trigger update checks, etc., to verify that this is working? As we know, we had some update checking crashes in AOO 3.4.1, so we really should try to get some test coverage of both positive and negative checks. Maybe one locale (English) we say there is an update, and in another locale (German) we say there is no update, so we can exercise both paths? Of course, we would then need to remove the test file from the web server before we ship. -Rob - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Testing AOO 4.0 Upgrades
On Mon, May 6, 2013 at 1:44 PM, Edwin Sharp el...@mail-page.com wrote: -1 4.0 isn't out yet, how can 4.1 be discussed?? Think of it this way: OpenOffice has the ability to receive automatic notifications of new releases. So when 4.1 is ready (some unknown time in the future) then AOO 4.0 users will automatically receive a pop-up message saying that they have an upgrade available. Although the code will not be executed until 4.1 is ready (some unknown time in the future) the update notification code is in AOO 4.0. So we need to find a way to test that code now, before AOO 4.0 ships. This is true even though the code will not trigger until 4.1 is ready. If we wait until 4.1 is ready it will be too late. -Rob On Mon, May 6, 2013, at 20:10, Alexandro Colorado wrote: +1 On Mon, May 6, 2013 at 11:27 AM, Rob Weir robw...@apache.org wrote: What do we need to do to test AOO 4.0 - AOO 4.1 upgrade scenario? Is it possible to put an update XML file on the server so we can trigger update checks, etc., to verify that this is working? As we know, we had some update checking crashes in AOO 3.4.1, so we really should try to get some test coverage of both positive and negative checks. Maybe one locale (English) we say there is an update, and in another locale (German) we say there is no update, so we can exercise both paths? Of course, we would then need to remove the test file from the web server before we ship. -Rob - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org -- Alexandro Colorado Apache OpenOffice Contributor http://es.openoffice.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: QA Volunteer of Apache OpenOffice team.
On Tue, Apr 23, 2013 at 4:11 AM, Alex Katsnelson katsnelso...@gmail.com wrote: Hi. Yi. A am glad to be a part of team! A registered in testlink user name is AlexQA from another mail alex1...@gmail.com ,I first time see testlink, so excuse if I ll ask about it. May I ask you please, to explain for me your organisational structure (how its working) I mean a job here. Hello Alex, and welcome to the Apache OpenOffice project and the QA team! You can learn more about the project from our New Volunteer Orientation Pages here: http://openoffice.apache.org/orientation/index.html Bugzilla I registered from mail katsnelso...@gmail.com, and I have a little experience on it. Good. I am one of the Bugzilla admins, so I just added you to the QA group in Bugzilla. This permits you to modify bug reports, change status, etc. So I ready, but if possible, don't forget - I am new and can you please explain what should I do, for begging job, please. I'd recommend a quick review of the new volunteer pages I linked to above. The Intro to QA, of course, is the key one. And ask questions. There are many other volunteers here to help. -Rob Thanks in advance. Best regards, Alex. 2013/4/23 Yi Xuan Liu liuyixuan@gmail.com Welcome Alex. You could firstly register on Bugzilla https://issues.apache.org/ooo/ and testlink http://aootesting.adfinis-sygroup.org/index.php. These two accounts are necessary for AOO testing. We'll start AOO 4.0 regression test in this Thursday. And I'll send the call-for letter later. Hope you pick up some task in AOO 4.0 regression test. Thanks! On Tue, Apr 23, 2013 at 12:29 AM, Alex Katsnelson katsnelso...@gmail.com wrote: Dear Sirs, My name is Alex Katsnelson. A am from Belarus, I have MA degree in economics, courses advanced software developer C++/C# . And course testing computer programs (QA). I have knowledge in QTP and SQL. I speak Russian, English, Hebrew. I want to begin my QA career, I have small learning experience in training protects and I wold like to learn (and practice) something new in QA, (manual or autom.) and to use my knowledge where it is needed. I am interesting to be part of QA Volunteer of Apache OpenOffice team. Thanks in advance. Best regards, Alex Katsnelson. - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: [QA BUG]
On Thu, Apr 18, 2013 at 5:18 PM, alfredo chable torrez yurggent1@gmail.com wrote: hello team, I would like to know what you think of this bug?, I checked and nothing happens. I don't change anything for the comment of binguo. I think it should be marked as RESOLVED/INVALID. Or RESOLVED/IRREPRODICIBLE. https://issues.apache.org/ooo/show_bug.cgi?id=121441 Regars. Yurggent Alfredo Chable
Re: QA REPORT.
On Thu, Apr 18, 2013 at 11:03 AM, Andrea Pescetti pesce...@apache.orgwrote: On 11/04/2013 Daniel Alvaro wrote: Hello, I'm wathing this bug: https://issues.apache.org/ooo/**show_bug.cgi?id=121325https://issues.apache.org/ooo/show_bug.cgi?id=121325 The user is using win xp and AOO 3.4.1 The problem is open office crashes every time since he updated. How can I help you and how can I close this bug? The comment in that bug is probably just right. You can resolve as irreproducible and say it depends on the Profile related crashes issue (I don't have the number handy, it was opened by orw, Oliver-Rainer Wittman). https://issues.apache.org/ooo/show_bug.cgi?id=121625 Regards, Andrea. --**--**- To unsubscribe, e-mail: qa-unsubscribe@openoffice.**apache.orgqa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Collect BVT Status and Continue Call for BVT volunteer
On Fri, Apr 12, 2013 at 10:25 PM, alfredo chable torrez yurggent1@gmail.com wrote: hi team, i have been solved the error with the jdk, ( http://imagebin.org/253816) thanks. Now I would like to know how to start testing? because i'm use openSuSE and the example in the wiki is for mac. I don't understand if the address is in the parentheses is the test folders. because when I compile appeared two new folders, (testgui and testuno) and inside these folders there another folder called bin, inside another folder called bvt and one more called gui, in this last folder is the class BasicFunctionTest.class (http://imagebin.org/253815) like in the example. mi question, which is the right direction for suse testing? or how can i run this class? The run script should be in the /test directory. Try this command from the test directory: ./run -Dopenoffice.home=/Applications/OpenOffice.org.app/Contents -tp bvt In Linux the current directory is not in the path. This is different than Windows. So with Linux if you want to execute a script in the current directory you put ./ first. -Rob Regars. Yurggent Alfredo. 2013/4/11 Li Feng Wang phoenix.wan...@gmail.com Hi,Claudio Filho From your fail log with Oracle JDK and OpenJDK, it may have no any relation with any JDK. Your env is OK, Just case fail, for BVT case wrote by GUI, not UNO interface. So there may be some case failed. For GUI case, there may have some offset impact test result. first, not do other operation when BVT is running. second, if there are fail case, you need check it manually again. 2013/4/12 Li Feng Wang phoenix.wan...@gmail.com hi, alfredo chable torrez, What JDK version of your env, Is it JDK1.5? If yes, you may need change to JDK1.6 or above. There maybe some code invoke JDK 1.6 API, that cause your compile error with JDK 1.5. 2013/4/12 alfredo chable torrez yurggent1@gmail.com Hello team, i have a new error in the compile because the version of javac is incompatible. http://imagebin.org/253669 can you tell me, Why is that? what can i do? Regars Yurggent Alfredo 2013/4/11 Claudio Filho filh...@gmail.com Hi 2013/4/10 Li Feng Wang phoenix.wan...@gmail.com I just use Oracle JDK to construct BVT automation , not OpenJDK, not sure to support OpenJDK in BVT automation. IMHO, to test BVT with OpenJDK is a good thing. I remember in 2005 (or 2007) when the distros's people (i remember of debian people) that did the compatibility with OpenJDK into source code. If we think to hug the linux universe, is important to maintain this point, including BVT. And what I know, today need a small attention in some details in programming time. Today, Oracle and Open Java are very close. You can send your Oracle JDK error log in your reply to all. I think that the list not support attachs, so I pushed my files in my directory[1]. [1]http://people.apache.org/~filhocf/aoo/bvt/ Bests, Claudio -- Best Wishes, LiFeng Wang -- Best Wishes, LiFeng Wang
Fwd: Call for volunteers for AOO 4.0 sidebar testing on trunk build
Forwarding this note to the dev list as well. This is a task that anyone can help with, not only those who think of themselves as qa. Since the Sidebar is a major new feature in AOO 4.0 we need all the help we can get testing this. -Rob -- Forwarded message -- From: Yi Xuan Liu liuyixuan@gmail.com Date: Thu, Apr 11, 2013 at 10:18 PM Subject: Call for volunteers for AOO 4.0 sidebar testing on trunk build To: qa@openoffice.apache.org Apache OpenOffice (AOO) is the leading open-source office software suite for word processing, spreadsheets, presentations, graphics, databases and more. The latest AOO release version is AOO 3.4.1 which has been downloaded by millions of people. Now we are on the trip of AOO 4.0. Sidebar is a new feature in AOO 4.0 release, which combines idea and code from both Symphony sidebar and OpenOffice Impress task panel. More info about sidebar could be found at sidebar wiki http://wiki.openoffice.org/wiki/Sidebar. Previously some volunteers run sidebar test on sidebar developing build. Thanks for these volunteers. Now, sidebar has been integrated into trunk build, and more sidebar panel are available now. We need more volunteers in sidebar testing on trunk build. This task is easy to follow execute and won't cost your much effort. The Game Rule is: *0. Choose your interesting test field and platform you will run on* I'll assign test cases to your according to your choice. Test Field: 13 sidebar panels will be tested: Text properties panel, Page properties panel, Area properties panel, Line panel, Position and Size panel, Graphic panel, Layouts panel, table design panel, alignment panel, cell appearance panel, number format panel, paragraph panel, wrap panel Platform: We plan to run test cases on 3 platforms: Suse(Redhat)-64bit, Ubuntu-64bit, Win 7 *1. Download AOO 4.0 build and install AOO 4.0:* Builds could be downloaded from AOO buildbots. It provides Linux 64bit(rpm and deb) install packageshttp://ci.apache.org/projects/openoffice/index.html#linux64and Win 7 install packages http://ci.apache.org/projects/openoffice/index.html#win . The install packages names is like this Apache OpenOffice 4.0.0 XXX x86(x86-64) install XXX.XXX *2. Execute test cases in testlink:* (1) Register in testlink: http://aootesting.adfinis-sygroup.org/index.php (2) Log into testlink and change test projects to Apache OpenOffice testproject in the right corner. (3) Found the test cases assigned to you from Test Cases Assigned to Me under Text Execution Panel (4) Execute the test case according to test case description (5) Record test case execution result in test link More testlink guide could be found at http://wiki.openoffice.org/wiki/QA/Testlink A video about how to run case and input result are provided at http://wiki.openoffice.org/wiki/QA/Testlink#Video_Demo *3. Open bugs in Bugzilla* Please open bugs in bugzilla when finding issue during test. (1) Register in bugzilla: https://issues.apache.org/ooo/ (2) Log on bugzilla and open new bugs. You could reference How to file a good issue http://wiki.openoffice.org/wiki/QA/HowToFileIssue *Note: Please add [sidebar] at the beginning of bug summary* Are you ready to take part in? If yes, *please tell me your interesting test field ,platform info from #0 list and testlink id**!*
Re: Collect BVT Status and Continue Call for BVT volunteer
On Tue, Apr 9, 2013 at 3:27 AM, Li Feng Wang phoenix.wan...@gmail.comwrote: Hi, all. Till now, there are tseng chan, alfredo chable torrze, King Duck want to contribute on Automation BVT(Build Verification Test). (1)First, collect contribute volunteers’ current status. I did a test on Windows 7 (32-bit): 400m1 (Build: 9700)(en-US) Revision: 1465696 No errors. 46/46 test cases pass. Some general comment son the BVT instructions on the wiki. First, this is not very hard to do. It took me around 30 minutes to set up the per-requisites on fresh Win7 install. And then maybe 20 minutes to run the actual test. The instructions on the wiki cover most things, but I did run into a few extra steps that I had to do. Maybe we can improve the instructions in the wiki? 1. It is not clear what build to download. The wiki points to: http://ci.apache.org/projects/openoffice/install/But there are a lot of things there, branch builds, etc. I went to the /win directory. 2. The instructions give office.home paths for AOO 3.4.1. But the path is now different in AOO 4.0: C:/Program Files/OpenOffice 4 3. The instructions give the command line for downloading the test source, but TortoiseSVN does not install the command-line SVN tools by default. You need to enable command line tools when installing TortoiseSVN. Or, like I did, just use the GUI. But this requires that someone understand how to use SVN. If I did not know SVN I would be lost at this step. 4. The JUnit link on the wiki is broken. But it looks like this is included by the test automatically? So maybe we can remove that step? 5. I had to do additional configuration steps at command line: a) Add ant directory to path, b) set JAVA_HOME directory. These would be familiar to anyone who understands simple Java programming. So this is all OK, if the tester understands a little bit about Java programming and how to set up the environment. Regards, -Rob If have some problems, please put forward issues that block you. I will help to resolve it. If you have no any problem, please put your result on http://wiki.openoffice.org/wiki/QA/BVT_Report, thx. (2)Second, Welcome other volunteers involve in. BVT Guide http://wiki.openoffice.org/wiki/QA/BVT Below are prerequisites: 1) 1)Environment tool: SVN Client, JDK, Ant 2) 2)Soft Skills: · a.Basic skills about Windows Command line, Linux/Mac Terminal · b.Basic knowledge of Java -- Best Wishes, LiFeng Wang
Re: [CALL for Volunteers] Is there anyone want to do BVT?
On Tue, Apr 9, 2013 at 5:39 PM, alfredo chable torrez yurggent1@gmail.com wrote: Hi rob weir, i'm working in openSuSE, I'm in the step of Run testing and when i write: ant -Dopenoffice.home= opt/openoffice4 compile the terminal say me that: Buildfile: build.xml does not exist! Before you run the ant task, do you see build.xml in your current directory? Did you do the svn co step, to download the test files? What directory are they in? Be sure that you run ant from that same directory. -Rob i don't know why this happens? because i have been installed OpenOffice4. regars Yurggent Alfredo. 2013/4/9 susan waldman swaldman20032...@yahoo.com Hi, I'd like to unsubscribe from this list. Thanks. From: Rob Weir robw...@apache.org To: qa@openoffice.apache.org qa@openoffice.apache.org Sent: Tuesday, April 9, 2013 4:43 PM Subject: Re: [CALL for Volunteers] Is there anyone want to do BVT? On Tue, Apr 9, 2013 at 4:25 PM, alfredo chable torrez yurggent1@gmail.com wrote: hello team, i have an error, when i write: ant -Dopenoffice.home=opt/openoffice4 compile I get the following error: Buildfile: build.xml does not exist! Build failed could you help me with this error? What directory are you in when you do the command? If the test code is in /test directory then you need to be in the /test directory. -Rob 2013/4/7 Li Feng Wang phoenix.wan...@gmail.com About openoffice.home pls reference http://wiki.openoffice.org/wiki/QA/BVT#FAQ. I also add Sample on windows to help bvt execution. http://wiki.openoffice.org/wiki/QA/BVT#Sample_on_Windows 2013/4/7 Li Feng Wang phoenix.wan...@gmail.com firstly, check out code to another directory secondly, your compile parameter openoffice.home is wrong. pls reference FAQ in http://wiki.openoffice.org/wiki/QA/BVT After that, try it again. 2013/4/4 Anders Kvibäck akva1...@gmail.com Hello! Yes, I would like to do some bvt tests. I have been around here for a couple months now mainly participating in the confirmation part of bugs. I have a university diploma in SoftwareEngineering, mainly java. So, I\m trying to perform some BVT tests. On monday,130401, I got it to work. I had some failures and errors that I started to work on. So, then on tuesday, 130402, I started to run the tests again but I got this RuntimeException message, cant find automation server!. Today I reloaded everything from svn but now I cant compile it. I get the message that build failed. Do you have any idea what this is about.I have been deleting the created test folders and downloaded the test scripts from svn again but I can't get it to work. The build failes. Here is what I got: C:\Users\Anders\testant -Dopenoffice.home=C:\Users\Anders\Desktop\OOo-dev 3.5 (en-US) Installation Files compile Buildfile: C:\Users\Anders\test\build.xml testcommon.init: check.junit: prepare.junit: testcommon.compile: testgui.init: testgui.compile: testuno.init: testuno.compile: [javac] Compiling 150 source files to C:\Users\Anders\test\testuno\bin [javac] warning: [options] bootstrap class path not set in conjunction with -source 1.6 [javac] C:\Users\Anders\test\testuno\source\fvt\mix\MixedTest.java:35: error : package com.sun.star.beans does not exist [javac] import com.sun.star.beans.XPropertySet; [javac] ^ [javac] C:\Users\Anders\test\testuno\source\fvt\mix\MixedTest.java:36: error And so on BUILD FAILED C:\Users\Anders\test\build.xml:113: Compile failed; see the compiler error outpu t for details. Total time: 32 seconds Do you have any idea? Have they recently- yesterday- changed anything in the svn? But their is this thing: warning: [options] bootstrap class path not set in conjunction with -source 1.6 Any idea? Anders 2013/4/3 alfredo chable torrez yurggent1@gmail.com thank you Li feng Wang, I can test in Open SUSE. right now i'm in the step of Run Testing Regars. Yurggent Alfredo Chable 2013/4/1 Li Feng Wang phoenix.wan...@gmail.com Till now, there are tseng chan, alfredo chable torrze, King Duck want to contribute on Automation BVT. Firstly, Welcome to AOO QA family. Secondly, Welcome new volunteer to add in BVT
Re: [QA][Weekly Report] Weekly Defect Status by 20130401
On Mon, Apr 1, 2013 at 7:11 AM, Andrea Villa villand...@gmail.com wrote: Mi dovete cancellare mi avete rotto la minchia non mi interessa Nn ce la faccio piu http://openoffice.apache.org/mailing-lists.html#using-mailing-lists Andrea Villa 0039 328 2349334 villand...@gmail.com This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. -Messaggio originale- Da: Andrea Pescetti [mailto:pesce...@apache.org] Inviato: lunedì 1 aprile 2013 12:05 A: qa@openoffice.apache.org Oggetto: Re: [QA][Weekly Report] Weekly Defect Status by 20130401 AOO Volunteer wrote: Just for the record, I think sidebar = vertical ribbon = bad idea. The menu is not going away anyway, so we won't be imposing a new approach. Many people will find the new one more convenient, but those who dislike it can continue using the traditional menu system. Regards, Andrea. - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org - Nessun virus nel messaggio. Controllato da AVG - www.avg.com Versione: 2013.0.2904 / Database dei virus: 2641/6214 - Data di rilascio: 30/03/2013 - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: QA Testing Volunteer
On Tue, Mar 26, 2013 at 9:59 PM, Li Feng Wang phoenix.wan...@gmail.com wrote: Welcome to OpenOffice. You can start with automation BVT(Build Verification Test) http://wiki.openoffice.org/wiki/QA/BVT http://wiki.openoffice.org/wiki/QA/BVT_Report It might help to add some more introduction in the BVT page, like: 1. What is a BVT, how is it used and why it is important 2. What prerequisite are needed to run the BVT? For example, you need a test machine, a good internet connection and command-line skills. 3. What do you do after you run the BVT? How to you categorize the defects in Bugzilla. Remember, a new person posting for the first time on this mailing list doesn't even have a Bugzilla account set up yet. They might not even be subscribed to the mailing list. So just pointing them to the BVT page will probably not work. It will only confuse them.I'd recommend start by asking more questions: What kind of experience do you have with OpenOffice? With quality assurance? With Java programming? What operating systems can you test with? Depending on their skill set and interest the new volunteer might be a good candidate for running the BVT. But I don't think we can assume that this is a good match for everyone. -Rob 2013/3/23 Amit Sarkar amit.sar...@cpit.ac.nz Hi I have joined the QA/Testing and eager to contribute. Regards Amitrajit __ This email has been filtered by SMX. For more information visit http://smxemail.com __ -- Best Wishes, LiFeng Wang - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
What is our best recommendation for 3.4.1 spell checking not working?
Users report that they install 3.4.1 and spell checking is not working. Redd squiggly lines under every word. Currently we point users to an exhaustive and exhausting list of possible remedies for this on the Forum. Very unhelpful, IMHO. I assume that in reality there is one predominate cause and solution to this issue rather than a dozen. So what is the most-likely to work solution? I'd like to point the users to that first, and then the exhaustive list as a back up. Any ideas? -Rob - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Introduction
On Tue, Mar 19, 2013 at 12:10 PM, Minal Joshi mj95...@gmail.com wrote: Hi, I am a software QA Engineer with 13+ years of experience in cross functionality testing of software products. Would like to participate in QA activities available. Hello Minal, Welcome to the Apache OpenOffice project and our QA mailing list! You are not currently subscribed to the mailing list, so your post was delayed by moderation, and you are not receiving posts from others yet. So please subscribe to this mailing list by sending an email to qa-subscr...@openoffice.apache.org. This and other useful facts are covered in our New Volunteer Orientation web site, which gives some good background info on Apache, Apache OpenOffice and the project: http://openoffice.apache.org/orientation/ If you have worked on an open source project before you can probably skim over the initial modules and focus more on the Intro to QA page: http://openoffice.apache.org/orientation/intro-qa.html That will lead you to getting signed up for our mailing list, bug tracking database, etc. When you get that far, let me know and I can add your Bugzilla account to to qa-team group so you have additional privileges in that database. -Rob Thank You, MJ - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: REPORT QA
On Fri, Mar 8, 2013 at 6:51 PM, Daniel Alvaro jdaniel.alv...@gmail.com wrote: Hello I'm checking this bug: 117985 https://issues.apache.org/ooo/show_bug.cgi?id=117985 But the O.S. is in windows NT, and the user wrote this: When converting a loop in edfld.cxx, the assignment of the loop variable got lost. My question is: How can I reproduce this bug? Regards, Good question. I would add a comment asking the original reporter, How can I reproduce the defect? What steps do I need to do? The report is written from the perspective of the code, the internals of the product. It does not describe the external impact of the defect. That's what makes it hard. Note: It is certainly possible for this defect to have no external impact for us to test. If this is true, then we will ask a programmer to verify the fix in the source code. -Rob Daniel Alvaro - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Bug not found
On Thu, Mar 7, 2013 at 11:15 PM, Javier LoRa xavi_da...@hotmail.com wrote: Hello again I was checking this bug but I can't reproduce it. Someone can check it? Because I tried but I don't have anything https://issues.apache.org/ooo/show_bug.cgi?id=119181 Thanks I looked at the attached document from the user and could not reproduce the bug. I used AOO 3.4.1 on Windows 7 64-bit. -Rob - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: The user not respond
On Fri, Mar 8, 2013 at 3:16 AM, Andrea Pescetti pesce...@apache.org wrote: Javier LoRa wrote: https://issues.apache.org/ooo/show_bug.cgi?id=118266 You can resolve it in some way. Probably Resolved - Irreproducible, since OpenOffice 3.3 was working on Windows 7 and this bug report is isolated. Yes. I usually give the user at least two weeks to respond. Sometimes a month. This is where the needmoreinfo keyword is useful. At the start of each month I run a query looking for all issues where; 1) I am the QA Contact 2) Issue is UNCONFIRMED status 3) needmoreinfo keyword is set 4) Issue has not been updated in more than 4 weeks I then close those issues as IRREPRODUCIBLE. It makes me instantly feel productive ;-) -Rob Regards, Andrea. - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Feedback on work
On Wed, Feb 27, 2013 at 3:17 PM, AOO Volunteer el...@mail-page.com wrote: Hi Confirming bugs for quite a time now but don't know if what I do is correct/wrong, useful/useless. Is there a way to get feedback on the work done? I took a look as well. I think you are doing a great job on the technical side of the tasks, trying to figure out what the user is talking about, reproducing the issues, etc. That's the hard part and you are doing great with that. A few tips on the process side, mainly with some fields in Bugzilla that you could use: -- When you successfully confirm a defect, be sure to set the Last Confirmation On field as well. I see you give the version info in your comment, but it is good to set this Last Confirmation On as well. That way we can define search filters for defects that have not been confirmed on a recent release. -- Consider adjusting the issue severity field, adjusting it higher or lower depending on the bug. If it is a crash, it should be higher than normal. If it is a harmless UI issue, maybe it is lower than normal. -- When you ask the user for a file, or need other information from them, be sure to set the needmoreinfo value into the Keywords field. That way we can more easily search for issues where we are waiting for the user. Finally, in this one issue I was confused. You marked it as confirmed, but your comment makes it sound like you did not see what the user reported. Your comment sounds like the data imported corrected: https://issues.apache.org/ooo/show_bug.cgi?id=87885 Oh, one other thing: Could you add your information to this wiki page? https://cwiki.apache.org/confluence/display/OOOUSERS/QA+Testing+Preferences Thanks for your hard work! -Rob Thank you!
