Difference between revisions of "QAAutomationIRCMeetings-8"
From Apache OpenOffice Wiki
| Line 1: | Line 1: | ||
| − | + | <pre> | |
| − | wolframg I think we have only one point on our discussion list for today. | + | |
| − | wolframg Mechthildes question:When should we do the Features Test? How should we do it (automatical and non-automatical)? | + | wolframg I think we have only one point on our discussion list for today. |
| − | msc_sun ping MechtiIde | + | wolframg Mechthildes question:When should we do the Features Test? How should we do it (automatical and non-automatical)? |
| − | MechtiIde msc_sun, pong | + | msc_sun ping MechtiIde |
| − | MechtiIde thanks for the reminder | + | MechtiIde msc_sun, pong |
| − | wolframg Any answers to Mechtildes question? | + | MechtiIde thanks for the reminder |
| − | MechtiIde IIn my mind testing all things in the RCs is to late | + | wolframg Any answers to Mechtildes question? |
| − | MechtiIde I think we need a mechanism to test earlier maybe we have a official beta version or similar | + | MechtiIde IIn my mind testing all things in the RCs is to late |
| − | wolframg Normally new features are already tested manually and automatically in the CWS. | + | MechtiIde I think we need a mechanism to test earlier maybe we have a official beta version or similar |
| − | MechtiIde from the Sun QA? | + | wolframg Normally new features are already tested manually and automatically in the CWS. |
| − | MechtiIde the problem I see is that they know how it had to do | + | MechtiIde from the Sun QA? |
| − | msc_sun MechtiIde: Yes from the sun QA. | + | MechtiIde the problem I see is that they know how it had to do |
| − | MechtiIde do they test all funktions every time or only the nes ones? | + | msc_sun MechtiIde: Yes from the sun QA. |
| − | wolframg It depends upon how large the effect of newly integrated features can be. | + | MechtiIde do they test all funktions every time or only the nes ones? |
| − | fha MechtiIde: Usually we should go over everything in a CWS, but due to lack of time, we have to restrict ourselves to the code-parts the changes might have "touched". | + | wolframg It depends upon how large the effect of newly integrated features can be. |
| − | MechtiIde My idea is to find the problems earlier e.g we find in the RC of the 2.3.0 | + | fha MechtiIde: Usually we should go over everything in a CWS, but due to lack of time, we have to restrict ourselves to the code-parts the changes might have "touched". |
| − | MechtiIde fha, that is the problem I see. My quwstion is, how to do it better | + | MechtiIde My idea is to find the problems earlier e.g we find in the RC of the 2.3.0 |
| − | * cgu_sun (i=cg103521@nat/sun/x-2cf0794886c3f98f) has joined #qa.openoffice.org | + | MechtiIde fha, that is the problem I see. My quwstion is, how to do it better |
| − | msc_sun With problems are found in the RC phase during automatic testing? | + | * cgu_sun (i=cg103521@nat/sun/x-2cf0794886c3f98f) has joined #qa.openoffice.org |
| − | msc_sun s/with/which | + | msc_sun With problems are found in the RC phase during automatic testing? |
| − | * stefan_b (i=Stefan@nat/sun/x-613ae2af9b1b81da) has joined #qa.openoffice.org | + | msc_sun s/with/which |
| − | MechtiIde msc_sun, if you only mean automatically tests no | + | * stefan_b (i=Stefan@nat/sun/x-613ae2af9b1b81da) has joined #qa.openoffice.org |
| − | MechtiIde I think it's a problem of QA | + | MechtiIde msc_sun, if you only mean automatically tests no |
| − | msc_sun MechtiIde: Yes I only mean automatic testing, because we are in the QAAutomationIRCMeeting. | + | MechtiIde I think it's a problem of QA |
| − | MechtiIde then sorry for my question | + | msc_sun MechtiIde: Yes I only mean automatic testing, because we are in the QAAutomationIRCMeeting. |
| − | wolframg MechtiIde, No need for sorry! | + | MechtiIde then sorry for my question |
| − | fha MechtiIde: Whatever suggestion you might have considering improving the automatic testing of the RC, is of course valuable. | + | wolframg MechtiIde, No need for sorry! |
| − | fha MechtiIde: (as every other suggestion btw) | + | fha MechtiIde: Whatever suggestion you might have considering improving the automatic testing of the RC, is of course valuable. |
| − | wolframg Has anybody another question to discuss? | + | fha MechtiIde: (as every other suggestion btw) |
| − | MechtiIde IMO many problems can only be found by manual test (because of mistakes of the user) | + | wolframg Has anybody another question to discuss? |
| − | msc_sun MechtiIde: ;-) no problem. | + | MechtiIde IMO many problems can only be found by manual test (because of mistakes of the user) |
| − | wolframg MechtiIde, You mean problems are only recovered because of somebody treating the software in another way then it was meant to? | + | msc_sun MechtiIde: ;-) no problem. |
| − | fha MechtiIde: yes, that's the problem with making and following a testcasespecification: your testing will only be as good / effective as the specification. (so you have to make yourself very clever when thinking about how to cover as much as possible with it, and keep it uptodate with new stuff) | + | wolframg MechtiIde, You mean problems are only recovered because of somebody treating the software in another way then it was meant to? |
| − | fha MechtiIde: Other problems are easily missed by manual testing, but directly found by automatic tests. Therefore both ways are used. | + | fha MechtiIde: yes, that's the problem with making and following a testcasespecification: your testing will only be as good / effective as the specification. (so you have to make yourself very clever when thinking about how to cover as much as possible with it, and keep it uptodate with new stuff) |
| − | MechtiIde so my question is: Is there a "best time" to do both test structurally | + | fha MechtiIde: Other problems are easily missed by manual testing, but directly found by automatic tests. Therefore both ways are used. |
| − | msc_sun MechtiIde: The "best time" is "every time" | + | MechtiIde so my question is: Is there a "best time" to do both test structurally |
| − | msc_sun :-) | + | msc_sun MechtiIde: The "best time" is "every time" |
| − | MechtiIde therefore there are less downloads of the dev versions | + | msc_sun :-) |
| − | msc_sun I think a regular testing is the best way to avoid regressions / found regressions. | + | MechtiIde therefore there are less downloads of the dev versions |
| − | MechtiIde That is not a good way to mobilize testers | + | msc_sun I think a regular testing is the best way to avoid regressions / found regressions. |
| − | * skotti has quit (Remote closed the connection) | + | MechtiIde That is not a good way to mobilize testers |
| − | * skotti (i=js104017@nat/sun/x-c03db964afc56b92) has joined #qa.openoffice.org | + | * skotti has quit (Remote closed the connection) |
| − | wolframg I think this is leading a bit off the track now. How to mobilize testers is not an issue we can solve here and now. | + | * skotti (i=js104017@nat/sun/x-c03db964afc56b92) has joined #qa.openoffice.org |
| − | wolframg Has anybody another question to discuss (last call) ? | + | wolframg I think this is leading a bit off the track now. How to mobilize testers is not an issue we can solve here and now. |
| − | wolframg Ok, next meeting : 2007-11-12 11 a.m. MESZ | + | wolframg Has anybody another question to discuss (last call) ? |
| + | wolframg Ok, next meeting : 2007-11-12 11 a.m. MESZ | ||
| + | wolframg Ok. No other points. The meeting is closed. Thanks for joining & Good Bye till next time. | ||
| + | |||
| + | </pre> | ||
| + | |||
| + | the overviewe of all meetings can be found here [[QAAutomationIRCMeetings]] | ||
Revision as of 09:40, 15 October 2007
wolframg I think we have only one point on our discussion list for today. wolframg Mechthildes question:When should we do the Features Test? How should we do it (automatical and non-automatical)? msc_sun ping MechtiIde MechtiIde msc_sun, pong MechtiIde thanks for the reminder wolframg Any answers to Mechtildes question? MechtiIde IIn my mind testing all things in the RCs is to late MechtiIde I think we need a mechanism to test earlier maybe we have a official beta version or similar wolframg Normally new features are already tested manually and automatically in the CWS. MechtiIde from the Sun QA? MechtiIde the problem I see is that they know how it had to do msc_sun MechtiIde: Yes from the sun QA. MechtiIde do they test all funktions every time or only the nes ones? wolframg It depends upon how large the effect of newly integrated features can be. fha MechtiIde: Usually we should go over everything in a CWS, but due to lack of time, we have to restrict ourselves to the code-parts the changes might have "touched". MechtiIde My idea is to find the problems earlier e.g we find in the RC of the 2.3.0 MechtiIde fha, that is the problem I see. My quwstion is, how to do it better * cgu_sun (i=cg103521@nat/sun/x-2cf0794886c3f98f) has joined #qa.openoffice.org msc_sun With problems are found in the RC phase during automatic testing? msc_sun s/with/which * stefan_b (i=Stefan@nat/sun/x-613ae2af9b1b81da) has joined #qa.openoffice.org MechtiIde msc_sun, if you only mean automatically tests no MechtiIde I think it's a problem of QA msc_sun MechtiIde: Yes I only mean automatic testing, because we are in the QAAutomationIRCMeeting. MechtiIde then sorry for my question wolframg MechtiIde, No need for sorry! fha MechtiIde: Whatever suggestion you might have considering improving the automatic testing of the RC, is of course valuable. fha MechtiIde: (as every other suggestion btw) wolframg Has anybody another question to discuss? MechtiIde IMO many problems can only be found by manual test (because of mistakes of the user) msc_sun MechtiIde: ;-) no problem. wolframg MechtiIde, You mean problems are only recovered because of somebody treating the software in another way then it was meant to? fha MechtiIde: yes, that's the problem with making and following a testcasespecification: your testing will only be as good / effective as the specification. (so you have to make yourself very clever when thinking about how to cover as much as possible with it, and keep it uptodate with new stuff) fha MechtiIde: Other problems are easily missed by manual testing, but directly found by automatic tests. Therefore both ways are used. MechtiIde so my question is: Is there a "best time" to do both test structurally msc_sun MechtiIde: The "best time" is "every time" msc_sun :-) MechtiIde therefore there are less downloads of the dev versions msc_sun I think a regular testing is the best way to avoid regressions / found regressions. MechtiIde That is not a good way to mobilize testers * skotti has quit (Remote closed the connection) * skotti (i=js104017@nat/sun/x-c03db964afc56b92) has joined #qa.openoffice.org wolframg I think this is leading a bit off the track now. How to mobilize testers is not an issue we can solve here and now. wolframg Has anybody another question to discuss (last call) ? wolframg Ok, next meeting : 2007-11-12 11 a.m. MESZ wolframg Ok. No other points. The meeting is closed. Thanks for joining & Good Bye till next time.
the overviewe of all meetings can be found here QAAutomationIRCMeetings
