QAAutomationIRCMeetings-8
From Apache OpenOffice Wiki
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
