<?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>Test and Automation Engineering</title>
	<atom:link href="http://digalogsystems.com/dsi-blog/?feed=rss2" rel="self" type="application/rss+xml" />
	<link>http://digalogsystems.com/dsi-blog</link>
	<description>Hopefully Helpful Ideas and Thoughts About Testing</description>
	<lastBuildDate>Wed, 26 May 2010 14:40:14 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>How to Determine if That Test is Good</title>
		<link>http://digalogsystems.com/dsi-blog/?p=7</link>
		<comments>http://digalogsystems.com/dsi-blog/?p=7#comments</comments>
		<pubDate>Wed, 26 May 2010 14:35:36 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[Testing Electronics]]></category>

		<guid isPermaLink="false">http://digalogsystems.com/dsi-blog/?p=7</guid>
		<description><![CDATA[Good has many meanings . The web site http://www.dictionary.com has over 50 definitions for the word. The definition used in this post is number 5, well behaved. A good, or well behaved test is one that passes the parameter being measured when it is within limits and fails when the measurement is outside of the [...]]]></description>
			<content:encoded><![CDATA[<p>Good has many meanings . The web site <a href="http://www.dictionary.com/">http://www.dictionary.com</a> has over 50 definitions for the word. The definition used in this post is number 5, well behaved. A good, or well behaved test is one that passes the parameter being measured when it is within limits and fails when the measurement is outside of the limits, all of the time.</p>
<p>Since it not possible to evaluate a test for the &#8220;all of the time&#8221; criteria it is necessary to turn to statistics to provide a measurement for the goodness of a test. And, since test is a process a good statistic to use is the capability index  (Cp) and the centering capability index (Cpk). A good explanation of the definitions of Cp and Cpk can be found at the QIMacros website, <a href="http://www.qimacros.com/qiwizard/process-capability.html">http://www.qimacros.com/qiwizard/process-capability.html</a></p>
<p>For an complete evaluation of the test it would be necessary to test a number of different boards on different test systems. However, executing the test on even one Unit Under Test on one tester will reveal a good amount of information about the test. For instance, is the Cpk less than 1? In that case there will definitely be problems. Typical industry demands are for a  Cpk  of 2 or over.</p>
<p>No matter what, if the tests are not evaluated and the results recorded trouble looms ahead. Having the evaluation proves that at least one moment in time the test was well behaved.</p>
<p>- Rick Wagner</p>
]]></content:encoded>
			<wfw:commentRss>http://digalogsystems.com/dsi-blog/?feed=rss2&amp;p=7</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Black Box Testing?</title>
		<link>http://digalogsystems.com/dsi-blog/?p=4</link>
		<comments>http://digalogsystems.com/dsi-blog/?p=4#comments</comments>
		<pubDate>Tue, 04 May 2010 20:57:00 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[Testing Electronics]]></category>
		<category><![CDATA[Testing in General]]></category>

		<guid isPermaLink="false">http://digalogsystems.com/dsi-blog/?p=4</guid>
		<description><![CDATA[Test specifications come from many sources. One source that can be used is Black Box test techniques. Black box testing  uses the inputs, outputs, and performance specification of the Unit Under Test to develop the test specifications. The term &#8220;Black Box&#8221; comes from the idea that the UUT is in a black box and its [...]]]></description>
			<content:encoded><![CDATA[<p>Test specifications come from many sources. One source that can be used is Black Box test techniques. Black box testing  uses the inputs, outputs, and performance specification of the Unit Under Test to develop the test specifications. The term &#8220;Black Box&#8221; comes from the idea that the UUT is in a black box and its inner design and workings are obfuscated.</p>
<p> The beginning of the test specification would then list all of the inputs and outputs on a document and apply the performance specification. Each time an input and output is referenced, the document is updated with the reference number of the performance specification. When the performance specification is exhausted, the engineer should be able to see any inputs or outputs that were not referenced. Typically the types inputs or outputs that are missed are those that use parallel pins on a connector, or in the case of software, excess information.</p>
<p> Other sources of test specifications include requirements that are not explicitly  part of the performance specification of the UUT, but need to be included in the test. An example of this type of requirement may be safety or regulatory requirements.</p>
<p>-Rick Wagner</p>
]]></content:encoded>
			<wfw:commentRss>http://digalogsystems.com/dsi-blog/?feed=rss2&amp;p=4</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
