<?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"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Test environment</title>
	<atom:link href="http://itknowledgeexchange.techtarget.com/itanswers/test-environment-2/feed/" rel="self" type="application/rss+xml" />
	<link>http://itknowledgeexchange.techtarget.com/itanswers/test-environment-2/</link>
	<description></description>
	<lastBuildDate>Wed, 19 Jun 2013 19:19:38 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	
	<item>
		<title>By: sunsetrider</title>
		<link>http://itknowledgeexchange.techtarget.com/itanswers/test-environment-2/#comment-101464</link>
		<dc:creator>sunsetrider</dc:creator>
		<pubDate>Tue, 10 Jan 2012 16:02:37 +0000</pubDate>
		<guid isPermaLink="false">#comment-101464</guid>
		<description><![CDATA[I would recommend that you create a &#039;standard&#039; test system for each environment (this will probably create some overlap), but you can use this test system for future changes. Also, you will not need to retain &#039;experts&#039; for this system, since your test cases and resullts should be the same each time.  You can always develop new test cases when new functionality is added.

When you are ready to test changes; load your current test system, compare the results with the previous test system (they should be the same, since no changes were introduced); implement your current set of changes; run the test system (adding additional test cases for new functionality) and compare with previous test system output. This is a relatively simple process to ensure only those functions that were modified have been changed.

I prefer this technique, rather than copying every db 10th record and turning this into our &#039;test&#039; system. Using the above example, I have a high confidence level that the changes implement will be adequately tested, and we will not have screwed up something else.]]></description>
		<content:encoded><![CDATA[<p>I would recommend that you create a &#8216;standard&#8217; test system for each environment (this will probably create some overlap), but you can use this test system for future changes. Also, you will not need to retain &#8216;experts&#8217; for this system, since your test cases and resullts should be the same each time.  You can always develop new test cases when new functionality is added.</p>
<p>When you are ready to test changes; load your current test system, compare the results with the previous test system (they should be the same, since no changes were introduced); implement your current set of changes; run the test system (adding additional test cases for new functionality) and compare with previous test system output. This is a relatively simple process to ensure only those functions that were modified have been changed.</p>
<p>I prefer this technique, rather than copying every db 10th record and turning this into our &#8216;test&#8217; system. Using the above example, I have a high confidence level that the changes implement will be adequately tested, and we will not have screwed up something else.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Performance optimized by W3 Total Cache. Learn more: http://www.w3-edge.com/wordpress-plugins/

Page Caching using memcached
Database Caching 3/10 queries in 0.121 seconds using memcached
Object Caching 267/273 objects using memcached

Served from: itknowledgeexchange.techtarget.com @ 2013-06-19 21:12:36 -->