Right, the test site exists in our case because we (try at least to) organize our development around a test driven approach.<br><br>Which involves an iterative approach. The test site is there and is tested incrementally with several versions.
<br><br>Victor Kane<br><a href="http://awebfactory.com.ar">http://awebfactory.com.ar</a><br><br><div><span class="gmail_quote">On 8/17/07, <b class="gmail_sendername">Earnie Boyd</b> &lt;<a href="mailto:earnie@users.sourceforge.net">
earnie@users.sourceforge.net</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br><br>Quoting Victor Kane &lt;<a href="mailto:victorkane@gmail.com">
victorkane@gmail.com</a>&gt;:<br><br>&gt;&gt; Everything ought to go through a test site, of course, but this becomes a<br>&gt;&gt; potential point of failure if urgent work is needed and the test site is<br>&gt;&gt; underused
<br>&gt;<br>&gt;<br>&gt; The only solution is that someone (usually me where I am) has to serve as<br>&gt; &quot;head cook and bottlewasher&quot; integrator in the test site.<br>&gt;<br><br>Scheduling testing is a large complication that should not be avoided
<br>just because a deadline is near or past.&nbsp;&nbsp;Testing must be planned in<br>the schedule.<br><br>&gt; The plot also thickens when customer needs to get content up in parrallel<br>&gt; with old version...<br>&gt;<br><br>But manageable none the less.
<br><br>Earnie<br></blockquote></div><br>