Re: [sidebar] request for defect confirmation
Hi, thanks for the feedback. My own investigation on Ubuntu 11.10 32bit and 64bit reveals the following: - the current snapshot builds show the defect - the linux64 buildbot result (rev. 1479357) from yesterday (2013-05-06) shows the defect - my own build (rev. 1479493) on Ubuntu 11.10 32bit does _not_ show the defect - my own build (rev. 1479493) on Ubuntu 11.10 64bit does _not_ show the defect Thus, I currently have no version which I can debug in order to find the root cause and to fix the issue. [The changes between rev. 1479357 and 1479493 are not fixing the problem from my point of view.] Can somebody support me here? Somebody with AOO developer skills able to reproduce it in her/his Linux environment? Best regards, Oliver. On 06.05.2013 21:47, Hagar Delest wrote: Confirmed on: AOO400m1(Build:9700) 2013-05-03 07:08:08 (Fri, 03 May 2013) - Linux x86_64 Ubuntu 13.04 (64bit) Highlight color is displayed in Draw, Calc and Impress. Hagar Le 06/05/2013 14:17, Oliver-Rainer Wittmann a écrit : Hi, while investigating issue 122047 I figured out that the sidebar panels which contains controls which are hidden/shown/enabled/disabled in certain contexts are not reflecting the context dependency under Linux. These are the Text property panel, the Paragraph property panel and the Position and Size panel. Example working under Windows, but not under Linux in my environments: In the Text property panel the highlight color control should be hidden in Calc, Draw and Impress. This is not the case under Linux - at least in my environments. Can somebody please confirm my observation? Thanks in advance, Oliver. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - 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: [sidebar] request for defect confirmation
Hi, On 07.05.2013 09:44, Oliver-Rainer Wittmann wrote: Hi, thanks for the feedback. My own investigation on Ubuntu 11.10 32bit and 64bit reveals the following: - the current snapshot builds show the defect - the linux64 buildbot result (rev. 1479357) from yesterday (2013-05-06) shows the defect - my own build (rev. 1479493) on Ubuntu 11.10 32bit does _not_ show the defect - my own build (rev. 1479493) on Ubuntu 11.10 64bit does _not_ show the defect When I replace libstdc++.so.6 of the snapshot build installations resp. linux64 buildbot result installation with the one of my own build installation the defect does _not_ occur any more. Best regards, Oliver. Thus, I currently have no version which I can debug in order to find the root cause and to fix the issue. [The changes between rev. 1479357 and 1479493 are not fixing the problem from my point of view.] Can somebody support me here? Somebody with AOO developer skills able to reproduce it in her/his Linux environment? Best regards, Oliver. On 06.05.2013 21:47, Hagar Delest wrote: Confirmed on: AOO400m1(Build:9700) 2013-05-03 07:08:08 (Fri, 03 May 2013) - Linux x86_64 Ubuntu 13.04 (64bit) Highlight color is displayed in Draw, Calc and Impress. Hagar Le 06/05/2013 14:17, Oliver-Rainer Wittmann a écrit : Hi, while investigating issue 122047 I figured out that the sidebar panels which contains controls which are hidden/shown/enabled/disabled in certain contexts are not reflecting the context dependency under Linux. These are the Text property panel, the Paragraph property panel and the Position and Size panel. Example working under Windows, but not under Linux in my environments: In the Text property panel the highlight color control should be hidden in Calc, Draw and Impress. This is not the case under Linux - at least in my environments. Can somebody please confirm my observation? Thanks in advance, Oliver. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - 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: Testing AOO 4.0 Upgrades
Hi, On 07.05.2013 09:30, Shenfeng Liu wrote: 2013/5/7 Rob Weir robw...@apache.org On Mon, May 6, 2013 at 1:58 PM, janI j...@apache.org wrote: On 6 May 2013 19:37, Rob Weir robw...@apache.org wrote: On Mon, May 6, 2013 at 1:25 PM, janI j...@apache.org wrote: On 6 May 2013 18:27, Rob Weir robw...@apache.org wrote: What do we need to do to test AOO 4.0 - AOO 4.1 upgrade scenario? Do we already have documented procedures for the AOO 3.4.1 - AOO 4.0 upgrade ? (searching in wiki for 4.0 upgrade gives no result) If not I would suggest we make the documentation and test plan for the 3.4.1 - 4.0 before thinking about the next upgrade. One thing that really needs to be tested is a 3.4.1 danish (example) installation, upgrade to a 4.0 english installation. At this point in time I foresee a 4.0 release with less languages than 3.4.1 (with language respin). The tests should include fallback scenarios for users who want to stay with their language version. Two different things: 1) The upgrade notifications. This is triggered by an XML file we put on our website that the client checks, by default once a week. For example, here is one of the existing update notification files: http://www.openoffice.org/projects/update38/ProductUpdateService/check.Update ok my mistake, but I still think we should discuss this for 4.0 and not 4.1. Let me be explicit. We need to test AOO 4.0's ability to be correctly process notifications about the existence of AOO 4.1. And we need to do that now, since after AOO 4.0 is installed on user's machines it is too late to fix any client-side bugs in this area. Some may remember, for example, a bug in AOO 3.4.0 where such notifications were disabled by default. And with 3.4.1 we had a bug where in some cases clients crashed when checking for extension updates. The defect we had in AOO 3.4 and AOO 3.4.1 regarding the update functionality - as far as I know - was the following: - If the user had upgraded an OOo 3.3 installation with AOO 3.4 or AOO 3.4.1 the bundled extensions delivered with OOo 3.3 were deleted from the installation, but the extension database still contains the corresponding entries. During automatically triggered update check for the application also an update check for the extensions is triggered. Due to the inconsistent extension database the deleted bundled extensions were tried to access. This causes an C++ exception which was not caught and caused a crash. This is fixed for AOO 4.0. So we do need to worry about AOO 4.1 now, at least to the extent AOO 4.0 needs support in its code to handle notifications about 4.1. Rob, So my understanding for the purpose of this discussion thread is that we need to test the upgrade notice in AOO 4.0, and ensure it can work when future releases (e.g. 4.1, 4.2...) available. Then I totally agree that it is very important and we need to add it to our test plan. While I want to confirm some technical details (and some of my understanding below is from my reading of the URL you provided above): 1. Is the URL unique for each release? And this URL will work for all the platforms and languages packages for this release? The URL to check for application updates is unique for each release. At least this is the case for the former releases and it will be for AOO 4.0. It work for all platforms and languages. The URL for AOO 4.0 will be https://ooo-site.apache.org/projects/update/aoo40/check.Update Have a look at main/instsetoo_native/util/openoffice.lst and search for string UPDATEURL 2. Is the upgrade notice only for release upgrade purpose, but not promotion of extensions or templates? OpenOffice contains two update functions. One for the application update and one for the extensions updates. The update check for the extensions is automatically triggered (if configured) at the same interval as the update check for the applications. Each extension can provide its own URL for the update check, but there is a fallback (URL currently not known to me). 3. For (A) and (B) below, I suppose they are not in AOO 4.0 scope, right? 4. For the testing perspective, can the URL be customized in AOO build ? If yes, we may create a fake URL for development/testing purpose, without impacting external users. Yes, the URL can be changed - even when AOO is running. Search for file version.ini (Windows) resp. versionrc (other platforms) in your installation. It contains an entry starting with string UpdateURL=. You can simply change its value to another URL. You can also use a file:// URL to a file on your local file system. Our wiki page [1] provides detailed information about the application update functionality in OpenOffice. - Shenfeng (Simon) There is a different base URL for each version, pointing to a file like this that lists the available upgrades for that version. Since the update checking code has changed, we should make sure we have good testing on that, on
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) 2013/5/7 Liu Ping doneyours...@gmail.com Simon ,yuzhen and all, You can directly click the Bug Queries link below for Defect verification in Bugzilla , you also can display query in page footer by selecting User Preferences-Save Searches and check the query below in bugzilla https://issues.apache.org/ooo/ AOO_Need_Verify : Numbers 1178 https://issues.apache.org/ooo/buglist.cgi?cmdtype=doremremaction=runnamedcmd=AOO_Need_Verifysharer_id=249289 AOO_Need_Verify_Calc: Numbers 292 https://issues.apache.org/ooo/buglist.cgi?cmdtype=doremremaction=runnamedcmd=AOO_Need_Verify_Calcsharer_id=249289 AOO_Need_Verify_Impress: Numbers 44 https://issues.apache.org/ooo/buglist.cgi?cmdtype=doremremaction=runnamedcmd=AOO_Need_Verify_Impresssharer_id=249289list_id=57850 AOO_Need_Verify_OtherProducts: Numbers 677 https://issues.apache.org/ooo/buglist.cgi?cmdtype=doremremaction=runnamedcmd=AOO_Need_Verify_OtherProductssharer_id=249289 AOO_Need_Verify_Writer : Numbers 165 https://issues.apache.org/ooo/buglist.cgi?cmdtype=doremremaction=runnamedcmd=AOO_Need_Verify_Writersharer_id=249289 Thanks the support of all On Mon, May 6, 2013 at 7:40 PM, Yuzhen Fan fanyuz...@gmail.com wrote: (Added dev in this mail thread ..) Simon and all, Here is the update of the preparation for full regression: - All test cases are populated to test plan AOO 4.0 Full Regression Test in TestLink - Test guidance for Full Regression Test and Defect Verification are ready and have published in wiki https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+Full+Regression+Test+Guidance https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+Defect+Verification+Guidance - Defect verification list are generated per different products with multiple queries Thanks Liu Ping to make defect queries. Thanks Simon for guidance and reviewing all preparation work above. Regards, Yu Zhen On Mon, May 6, 2013 at 7:25 PM, Yuzhen Fan fanyuz...@gmail.com wrote: Simon and all, Here is the update of the preparation for full regression: - All test cases are populated to test plan AOO 4.0 Full Regression Test in TestLink - Test guidance for the Full Regression Test and Defect Verification are ready and have published in wiki https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+Full+Regression+Test+Guidance https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+Defect+Verification+Guidance On Fri, May 3, 2013 at 4:05 PM, Shenfeng Liu liush...@gmail.com wrote: Hi, all, I just want to update on our next plan for AOO 4.0 Testing. Since sidebar FVT already finished, we are currently preparing for a full regression which will cover the following areas: (1) Basic Function Verification (2) MS Interoperability Test (3) 2nd phase of sidebar testing (4) Defect verification So following works are on going: - Yi Xuan and Yu Zhen are inputting test cases in Testlink. - Yu Zhen and I are working on are test guidance for the Full Regression Test, and plan to publish it on our planning wiki for reference. - Then we wait for the next snapshot build from Juergen which contains the most recent fixes. I saw many people joined and volunteered for QA work. I will keep a list and contact you all when the Regression Testing is kicked off. Thanks very much for your supporting to AOO QA work! - Shenfeng (Simon)
RE: Start AOO 4.0 Full Regression Test - missing keyboard navigation and accelerators in test cases
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. 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: 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 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. 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. Based on my experience from international software, menus and accellerators are common translation problems. Any other areas that would make sense to focus on? Installation with a keyboard only, or automated installation 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/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:
Re: Start AOO 4.0 Full Regression Test - missing keyboard navigation and accelerators in test cases
On 7 May 2013 22:00, Rob Weir robw...@apache.org wrote: 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. that is not just theory, I worked on a package earlier that did such an analysis on PO files...actually it is quite easy. The benefit of doing it on PO files is the consistency check (accelletor for a given menu item, e.g. Open is identical in all product parts). 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.) that is a statement...I have worked on bigger packages, where we had next to full coverage (all automated), so the size is not the problem, our restricted resources are, which is why we in the middleterm should focus on automating as much a possible. 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. for now that is the only thing we can do. 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. +1 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
Re: Start AOO 4.0 Full Regression Test - missing keyboard navigation and accelerators in test cases
Rob Weir wrote: On Tue, May 7, 2013 at 3:42 PM, janI wrote: 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? Accelerators are defined algorithmically by OpenOffice when not specified, and the algorithm avoids collisions. So the recommendation for translations is not to specify an accelerator unless you know what you are doing. Accelerators in PO files are marked by ~: F~ormat means that the accelerator is the letter O. We do have an accelerator bug in the latest 4.x snapshot, feel free to post to Bugzilla if confirmed. In Calc, Alt+O opens F~ormat but, within Format, there is no accelerator for the Flip command (and anything below it, apparently) since F, L, I, P are all taken by other commands. This might be one of the cases where we need manual definition (for example, mapping AutoFormat to m; or find and improve the algorithm!). Regards, Andrea. - 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 7 May 2013 23:49, Andrea Pescetti pesce...@apache.org wrote: Rob Weir wrote: On Tue, May 7, 2013 at 3:42 PM, janI wrote: 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? Accelerators are defined algorithmically by OpenOffice when not specified, and the algorithm avoids collisions. So the recommendation for translations is not to specify an accelerator unless you know what you are doing. Accelerators in PO files are marked by ~: F~ormat means that the accelerator is the letter O. I found quite a lot, when I tested genLang, defined in the .src files. I will try to make a grep later. rgds jan I. We do have an accelerator bug in the latest 4.x snapshot, feel free to post to Bugzilla if confirmed. In Calc, Alt+O opens F~ormat but, within Format, there is no accelerator for the Flip command (and anything below it, apparently) since F, L, I, P are all taken by other commands. This might be one of the cases where we need manual definition (for example, mapping AutoFormat to m; or find and improve the algorithm!). 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: Start AOO 4.0 Full Regression Test
2013/5/7 Shenfeng Liu liush...@gmail.com: Now we have the latest dev snapshot build here: https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds#DevelopmentSnapshotBuilds-AOOSnapshotfullsets Good. I go the do download that. * I am trying just do compilation on Debian amd64 * o.O 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 Ok. 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! I also. Albino - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
