BobF wrote:
> imo, a documented test plan is the way to go. instead of fixing a time on
> the calendar between rc release and release, only go to release after the
> test plan execution is reported as complete.
I fully support this POV.
HOWEVER, there is no test plan nor is there anybody to carry it out.
As it seems, we may be able to attract people for the latter. Thus,
we should try this and learn how to coordinate with them.
Everybody in the TSVN community contributes on an entirely voluntary
basis. Therefore, we have to find a way to formalize our testing efforts
as less disruptive (overhead, (in)efficiency, (in)effectiveness, general
annoyance) as possible and step by step. The final solution (after some
years of experience making) might look entirely different from what
typical corporate processes look like.
> this is not zero-overhead, but it directly addresses the real problem.
IMHO, the primary problem is not coverage (which was to be addressed
by a comprehensive test plan and is currently addressed by sheer mass)
but testing at all: Most developers and most "adventurous" users use the
future, still "unstable" development line (today: 1.4.0). Conservative users
install some older, "stable" version and stick to it for a while.
This has the effect of making the "unstable" line (many testers, quick
response) having *less* bugs in older functionality than the "stable" line
(only few code changes and virtually no testers). Therefore, extra steps
must be taken when releasing bugfixes on the "stable" line.
Process improvement would be easy
if there was no such thing as ROI.
-- Stefan^2
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Tue Jun 20 00:42:55 2006