<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: Software testing</title>
	<atom:link href="http://maas-frensch.com/peter/2006/06/25/testing-procedures/feed/" rel="self" type="application/rss+xml" />
	<link>http://maas-frensch.com/peter/2006/06/25/testing-procedures/</link>
	<description>Peter Maas's Weblog</description>
	<pubDate>Thu, 16 Oct 2008 01:52:13 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.2</generator>
		<item>
		<title>By: Frans Maas</title>
		<link>http://maas-frensch.com/peter/2006/06/25/testing-procedures/#comment-103</link>
		<dc:creator>Frans Maas</dc:creator>
		<pubDate>Wed, 28 Jun 2006 20:10:14 +0000</pubDate>
		<guid isPermaLink="false">http://maas-frensch.com/peter/2006/06/25/testing-procedures/#comment-103</guid>
		<description>A member of a highly respected consultancy organisation presented a story about "operational excellence". 

One of his "best practices" was to test outside office hours with full production load. 

Our experience: We always deploy generic solutions for 100K  users around the world, 7x24 available, very limited maintenance windows. In one particular case we really executed a comprehensive test plan, anonimized data captured from production, home made test drivers, thousands of euros. And guess what: no errors found. We then released into production: continuous stream of incidents, many weeks of instability. Conclusion: don't test anymore, it is not worth the money!

The "best practice" may be fine for a specific business application with clearly defined small user group and predictable transaction load. But not for complex Internet oriented with unknown crowds of users. 

We now work with a staging process, regression test set for reasonable level of functional testing, coexistence of old and new solutions, gradual deployment, small group of known and tolerant users first. And invest in backout procedures, monitoring during and after deployment, good alert mechanism to keep users and help desks informed about system outages, known problems and work arounds.

Very similar to transplanting a heart. You can't test it either!</description>
		<content:encoded><![CDATA[<p>A member of a highly respected consultancy organisation presented a story about &#8220;operational excellence&#8221;. </p>
<p>One of his &#8220;best practices&#8221; was to test outside office hours with full production load. </p>
<p>Our experience: We always deploy generic solutions for 100K  users around the world, 7&#215;24 available, very limited maintenance windows. In one particular case we really executed a comprehensive test plan, anonimized data captured from production, home made test drivers, thousands of euros. And guess what: no errors found. We then released into production: continuous stream of incidents, many weeks of instability. Conclusion: don&#8217;t test anymore, it is not worth the money!</p>
<p>The &#8220;best practice&#8221; may be fine for a specific business application with clearly defined small user group and predictable transaction load. But not for complex Internet oriented with unknown crowds of users. </p>
<p>We now work with a staging process, regression test set for reasonable level of functional testing, coexistence of old and new solutions, gradual deployment, small group of known and tolerant users first. And invest in backout procedures, monitoring during and after deployment, good alert mechanism to keep users and help desks informed about system outages, known problems and work arounds.</p>
<p>Very similar to transplanting a heart. You can&#8217;t test it either!</p>
]]></content:encoded>
	</item>
</channel>
</rss>
