<?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: Services to the Organization</title>
	<atom:link href="http://www.jrothman.com/blog/mpd/2007/05/services-to-the-organization.html/feed" rel="self" type="application/rss+xml" />
	<link>http://www.jrothman.com/blog/mpd/2007/05/services-to-the-organization.html</link>
	<description>Management, especially good management, is hard to do. This blog is for people who want to think about how they manage people, projects, and risk.</description>
	<lastBuildDate>Fri, 18 May 2012 15:02:36 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.2</generator>
	<item>
		<title>By: Michael Henk</title>
		<link>http://www.jrothman.com/blog/mpd/2007/05/services-to-the-organization.html/comment-page-1#comment-571</link>
		<dc:creator>Michael Henk</dc:creator>
		<pubDate>Mon, 21 May 2007 05:24:57 +0000</pubDate>
		<guid isPermaLink="false">http://jrothman.com/blog/mpd/?p=7971#comment-571</guid>
		<description>Hey Johanna
Product design testing is a requirement of ISO in verification and validation.  Testing is verifying and validating the outputs or deliverables of the design.
However, testing is also done throughout a company outside of product development.  There is testing to validate product improvements, process changes, and perhaps trying to duplicate a performance issue that a customer identified.  In these ways, it can be viewed as a common service for manufacturing, marketing, and design.
I guess I see it as both.</description>
		<content:encoded><![CDATA[<p>Hey Johanna<br />
Product design testing is a requirement of ISO in verification and validation.  Testing is verifying and validating the outputs or deliverables of the design.<br />
However, testing is also done throughout a company outside of product development.  There is testing to validate product improvements, process changes, and perhaps trying to duplicate a performance issue that a customer identified.  In these ways, it can be viewed as a common service for manufacturing, marketing, and design.<br />
I guess I see it as both.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Frank Schophuizen</title>
		<link>http://www.jrothman.com/blog/mpd/2007/05/services-to-the-organization.html/comment-page-1#comment-570</link>
		<dc:creator>Frank Schophuizen</dc:creator>
		<pubDate>Sat, 19 May 2007 10:59:09 +0000</pubDate>
		<guid isPermaLink="false">http://jrothman.com/blog/mpd/?p=7971#comment-570</guid>
		<description>Testing is a major component of the righthand side of the V-model. It comprises of verification and validation - I assume reader know the difference.
Although the activity of doing tests is part of development - and therefore part of the project - the act of doing tests may be specialistic and require special resources (e.g. skills, equipment, security area access). It may be efficient for an organization to have a specialized &quot;testing department&quot; to provide the &quot;service of testing&quot; to the project.
This way testing is both a service and an activity of the project.</description>
		<content:encoded><![CDATA[<p>Testing is a major component of the righthand side of the V-model. It comprises of verification and validation &#8211; I assume reader know the difference.<br />
Although the activity of doing tests is part of development &#8211; and therefore part of the project &#8211; the act of doing tests may be specialistic and require special resources (e.g. skills, equipment, security area access). It may be efficient for an organization to have a specialized &#8220;testing department&#8221; to provide the &#8220;service of testing&#8221; to the project.<br />
This way testing is both a service and an activity of the project.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Herbjeet Bal</title>
		<link>http://www.jrothman.com/blog/mpd/2007/05/services-to-the-organization.html/comment-page-1#comment-569</link>
		<dc:creator>Herbjeet Bal</dc:creator>
		<pubDate>Thu, 17 May 2007 21:54:26 +0000</pubDate>
		<guid isPermaLink="false">http://jrothman.com/blog/mpd/?p=7971#comment-569</guid>
		<description>While I agree that testing should be an integrated process in the development of a product, I think the argument you are making is just semantics. You are actually arguing that testing should be integrated in the development process and not just
tacked on to the end - which I am in total agreement with.
However, you can call testing a &quot;service&quot; to the organization AND it can be integrated from the start (or it may not be). Or, you can just call it part of development AND it can be integrated from the start (or it may not be). I don&#039;t think calling it a service to the organization is wrong or incorrect.
If it suits your needs to call it a service to the organization, then that&#039;s fine.
If it suits your needs to call it a part of the development process (or a service to the product or the development team), then that&#039;s fine.
Either way is fine, so long as testing starts with the start of development. Isn&#039;t that what you are trying to say?
Your assumption that a service (to the organization) cannot be an integral part of a project isn&#039;t correct, but I don&#039;t think that was the point you were trying to make.</description>
		<content:encoded><![CDATA[<p>While I agree that testing should be an integrated process in the development of a product, I think the argument you are making is just semantics. You are actually arguing that testing should be integrated in the development process and not just<br />
tacked on to the end &#8211; which I am in total agreement with.<br />
However, you can call testing a &#8220;service&#8221; to the organization AND it can be integrated from the start (or it may not be). Or, you can just call it part of development AND it can be integrated from the start (or it may not be). I don&#8217;t think calling it a service to the organization is wrong or incorrect.<br />
If it suits your needs to call it a service to the organization, then that&#8217;s fine.<br />
If it suits your needs to call it a part of the development process (or a service to the product or the development team), then that&#8217;s fine.<br />
Either way is fine, so long as testing starts with the start of development. Isn&#8217;t that what you are trying to say?<br />
Your assumption that a service (to the organization) cannot be an integral part of a project isn&#8217;t correct, but I don&#8217;t think that was the point you were trying to make.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dave Liebreich</title>
		<link>http://www.jrothman.com/blog/mpd/2007/05/services-to-the-organization.html/comment-page-1#comment-568</link>
		<dc:creator>Dave Liebreich</dc:creator>
		<pubDate>Thu, 17 May 2007 21:12:14 +0000</pubDate>
		<guid isPermaLink="false">http://jrothman.com/blog/mpd/?p=7971#comment-568</guid>
		<description>Hi Johanna,
You scooped my next question :-)
I&#039;m sure we could quibble about details, but now I&#039;m comfortable agreeing with your written .
I like to think about testing as delivering information to various stakeholders.  If the stakeholders then act upon this information, I call it feedback.
As a tester, being integrated with the stakeholders helps me tune the information so that it is more likely to be acted upon.
Another thing that helps me deliver better information is to realise that the stakeholders have different needs.  Coders require different types of information than documenters, and documenters need different types of information than project managers.  And so on with end-users, customers, sponsors, managers, auditors, the testers themselves, etc.</description>
		<content:encoded><![CDATA[<p>Hi Johanna,<br />
You scooped my next question :-)<br />
I&#8217;m sure we could quibble about details, but now I&#8217;m comfortable agreeing with your written .<br />
I like to think about testing as delivering information to various stakeholders.  If the stakeholders then act upon this information, I call it feedback.<br />
As a tester, being integrated with the stakeholders helps me tune the information so that it is more likely to be acted upon.<br />
Another thing that helps me deliver better information is to realise that the stakeholders have different needs.  Coders require different types of information than documenters, and documenters need different types of information than project managers.  And so on with end-users, customers, sponsors, managers, auditors, the testers themselves, etc.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

