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> <<a href="mailto:earnie@users.sourceforge.net">
earnie@users.sourceforge.net</a>> 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 <<a href="mailto:victorkane@gmail.com">
victorkane@gmail.com</a>>:<br><br>>> Everything ought to go through a test site, of course, but this becomes a<br>>> potential point of failure if urgent work is needed and the test site is<br>>> underused
<br>><br>><br>> The only solution is that someone (usually me where I am) has to serve as<br>> "head cook and bottlewasher" integrator in the test site.<br>><br><br>Scheduling testing is a large complication that should not be avoided
<br>just because a deadline is near or past. Testing must be planned in<br>the schedule.<br><br>> The plot also thickens when customer needs to get content up in parrallel<br>> with old version...<br>><br><br>But manageable none the less.
<br><br>Earnie<br></blockquote></div><br>