<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	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/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>//TODO: Create Blog Title &#187; Testing</title>
	<atom:link href="http://DontForgetYourTODOs.com/category/testing/feed/" rel="self" type="application/rss+xml" />
	<link>http://DontForgetYourTODOs.com</link>
	<description></description>
	<lastBuildDate>Mon, 26 Jul 2010 03:20:06 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0</generator>
		<item>
		<title>Are You Writing Baby Proof Software?</title>
		<link>http://DontForgetYourTODOs.com/2009/07/are-you-writing-baby-proof-software/</link>
		<comments>http://DontForgetYourTODOs.com/2009/07/are-you-writing-baby-proof-software/#comments</comments>
		<pubDate>Mon, 27 Jul 2009 17:00:00 +0000</pubDate>
		<dc:creator>Josh</dc:creator>
				<category><![CDATA[Testing]]></category>

		<guid isPermaLink="false">http://DontForgetYourTODOs.com/?p=318</guid>
		<description><![CDATA[The other day while eating lunch the topic of newborns came up. We discussed that when parents prepared for a newborn to enter their home, they gave their best effort to ensure that the home was “baby proof”. Outlets were covered, stairway gates were in place, and cabinets locked to stop the little one from [...]]]></description>
			<content:encoded><![CDATA[<p>The other day while eating lunch the topic of newborns came up. We discussed that when parents prepared for a newborn to enter their home, they gave their best effort to ensure that the home was “baby proof”. Outlets were covered, stairway gates were in place, and cabinets locked to stop the little one from getting into trouble with anything in reach. Now they look back as their children become mobile, and say a whole new can of worms is opened. Cabinets are not locked to protect what is inside. They are locked to prevent them being turned into steps to get other items originally out of reach.</p>
<p><a href="http://www.flickr.com/photos/kohlerfolk/3144861603/"><img style="border-right-width: 0px; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px" class="aligncenter" border="0" alt="christmas-tree" src="http://dontforgetyourtodos.com/wp-content/uploads/2009/07/christmas-tree.jpg" width="274" height="364" /></a></p>
<p>Baby proofing your home serves as a solid analogy to writing software. As much as we wish it were not true, we unintentionally write buggy software. If you are lucky, the bugs are never found once the software goes out the door. Try as much as you wish to hide the errors and gracefully recover, there is always some way to work around the system. Users are just like babies in that they just putter around in the application trying different things until they find what works. They may not be expect to find these issues, but once they find them, watch out because they&#8217;ll remember how to get back and exploit what you hoped was &quot;safe software&quot;. The <a href="http://en.wikipedia.org/wiki/Twilight_hack">Twilight Hack</a> for example allowed Wii users to exploit a buffer overflow just by changing the name of the character’s horse.</p>
<p>It is very difficult to try and prevent this seeing how you cannot really tell exactly what you are looking for. Keep in mind though that software development is a lot more forgiving than raising a child. You cannot run usability tests in your house to see how safe it is. The only solution that I have to getting around this is to draw from past experiences. Focus on thorough testing and make sure past issues are no longer a problem.</p>
<p>Below is a refresher on the types of software testing that most products should undergo:</p>
<ul>
<li><a href="http://en.wikipedia.org/wiki/Unit_testing">Unit Testing</a> &#8211; validate that individual units of your code work for a given input and expected output. Never rely on external factors to write your unit tests (e.g. Database Engine having correct data and up to date) </li>
<li><a href="http://www.testinggeek.com/index.php/testing-types/life-cycle/54-integration-testing">Integration Testing</a> &#8211; ensure that you are clear of your expectations and what you expect when working in multiple distributed environments or systems </li>
<li><a href="http://en.wikipedia.org/wiki/Software_performance_testing">Performance/Load Testing</a> &#8211; you will want to try and avoid being surprised when you get a call on Cyber Monday telling you that your site is offline due to heavy load </li>
<li><a href="http://en.wikipedia.org/wiki/Usability_testing">Usability Testing</a> &#8211; before you go live, do some testing on your application to make sure that you see how well subjects can perform tasks and respond to errors </li>
<li><a href="http://en.wikipedia.org/wiki/Regression_testing">Regression Testing</a> &#8211; remember that feature that you added in last month&#8217;s release? Yeah well now the user cannot update their profile ever since then. Regression test to ensure that updates you make do not cause existing functionality to break. </li>
<li><a href="http://en.wikipedia.org/wiki/Security_testing">Security Testing</a> &#8211; is your software capable of SQL Injection? Do you follow correct authorization rules for your users and does your data retain its integrity? </li>
</ul>
]]></content:encoded>
			<wfw:commentRss>http://DontForgetYourTODOs.com/2009/07/are-you-writing-baby-proof-software/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

