From Apache OpenOffice Wiki
Jump to: navigation, search

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
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
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
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

Personal tools