<?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: QA as Customer Representatives within the R&amp;D</title>
	<atom:link href="http://qablog.practitest.com/2008/10/qa-as-customer-representatives-within-the-rd/feed/" rel="self" type="application/rss+xml" />
	<link>http://qablog.practitest.com/2008/10/qa-as-customer-representatives-within-the-rd/</link>
	<description>Testing Tools &#38; Methodologies for the Practical QA Tester</description>
	<lastBuildDate>Tue, 09 Mar 2010 16:25:10 -0700</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.3</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Joel Montvelisky</title>
		<link>http://qablog.practitest.com/2008/10/qa-as-customer-representatives-within-the-rd/comment-page-1/#comment-31</link>
		<dc:creator>Joel Montvelisky</dc:creator>
		<pubDate>Wed, 15 Oct 2008 16:04:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.practitest.com/qablog/2008/10/qa-as-customer-representatives-within-the-rd/#comment-31</guid>
		<description>Hi Ido,&lt;br/&gt;&lt;br/&gt;It&#039;s obvious that no approach will fit every Organization, but I seem to disagree with a couple of your points.&lt;br/&gt;&lt;br/&gt;You wrote that QA Engineers don&#039;t have programming skills and may not be aware of the technical difficulties of their apps.  I think that was true 5 or 10 years ago; today most QA Engineers are trained in Development, and are able to understand the intricacies of the system under test.  &lt;br/&gt;They are not the developers of their applications, but more and more I am seeing all over the Industry  Engineers (manual tester and not only automation) who can enter the code, understand it and use it as part of their white or grey box testing approach.&lt;br/&gt;&lt;br/&gt;&lt;br/&gt;Regarding the task of the Product Managers, you are right and they should be the first players in direct contact with users, but not the only ones.  The more QA and Developers are in direct contact with users, the better the application will answer their REAL Needs.&lt;br/&gt;&lt;br/&gt;Having a QA department that does not understand its end-users is like having a color-blind painter.  He will get it right part of the time and with a limited spectrum of color but it will never be the same thing.&lt;br/&gt;&lt;br/&gt;&lt;br/&gt;Again, there is no approach that fits all Organizations, but I believe (and my experience tells me) that all organizations should strive to have their QA (and Dev) Engineers in some sort of contact with their users.&lt;br/&gt;&lt;br/&gt;My 2 cents (no obligation to take them :) )</description>
		<content:encoded><![CDATA[<p>Hi Ido,</p>
<p>It&#8217;s obvious that no approach will fit every Organization, but I seem to disagree with a couple of your points.</p>
<p>You wrote that QA Engineers don&#8217;t have programming skills and may not be aware of the technical difficulties of their apps.  I think that was true 5 or 10 years ago; today most QA Engineers are trained in Development, and are able to understand the intricacies of the system under test.  <br />They are not the developers of their applications, but more and more I am seeing all over the Industry  Engineers (manual tester and not only automation) who can enter the code, understand it and use it as part of their white or grey box testing approach.</p>
<p>Regarding the task of the Product Managers, you are right and they should be the first players in direct contact with users, but not the only ones.  The more QA and Developers are in direct contact with users, the better the application will answer their REAL Needs.</p>
<p>Having a QA department that does not understand its end-users is like having a color-blind painter.  He will get it right part of the time and with a limited spectrum of color but it will never be the same thing.</p>
<p>Again, there is no approach that fits all Organizations, but I believe (and my experience tells me) that all organizations should strive to have their QA (and Dev) Engineers in some sort of contact with their users.</p>
<p>My 2 cents (no obligation to take them <img src='http://qablog.practitest.com/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' />  )</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ido Schacham</title>
		<link>http://qablog.practitest.com/2008/10/qa-as-customer-representatives-within-the-rd/comment-page-1/#comment-30</link>
		<dc:creator>Ido Schacham</dc:creator>
		<pubDate>Wed, 15 Oct 2008 12:12:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.practitest.com/qablog/2008/10/qa-as-customer-representatives-within-the-rd/#comment-30</guid>
		<description>Generally I agree that these are good suggestions how to get developers closer to their customers.&lt;br/&gt;&lt;br/&gt;However, there is one major problem with what you said. Most developers are very attached to their code and think too much like developers. Few have an all encompassing awareness that can take the customer perspective in mind.&lt;br/&gt;&lt;br/&gt;QA are not attached to the code. They may get attached to how the product currently works and get mind blocked, but that&#039;s a different story. So considering things they have, relatively, an external perspective as opposed to developers. They aren&#039;t aware of technical difficulties, most of them don&#039;t know how to program, even those that do usually aren&#039;t acquainted with the code, and they do possess much better all around knowledge and a bigger picture of the product than most developers who are busy implementing tiny bits of it.&lt;br/&gt;&lt;br/&gt;So yes, QA aren&#039;t the actual users, but they are much closer to the user perspective than the developers. It&#039;s probably best to run usability tests with actual customers to get the real users&#039; take on things, but sometimes even the users don&#039;t know what they want :) Isn&#039;t that what product managers are for?</description>
		<content:encoded><![CDATA[<p>Generally I agree that these are good suggestions how to get developers closer to their customers.</p>
<p>However, there is one major problem with what you said. Most developers are very attached to their code and think too much like developers. Few have an all encompassing awareness that can take the customer perspective in mind.</p>
<p>QA are not attached to the code. They may get attached to how the product currently works and get mind blocked, but that&#8217;s a different story. So considering things they have, relatively, an external perspective as opposed to developers. They aren&#8217;t aware of technical difficulties, most of them don&#8217;t know how to program, even those that do usually aren&#8217;t acquainted with the code, and they do possess much better all around knowledge and a bigger picture of the product than most developers who are busy implementing tiny bits of it.</p>
<p>So yes, QA aren&#8217;t the actual users, but they are much closer to the user perspective than the developers. It&#8217;s probably best to run usability tests with actual customers to get the real users&#8217; take on things, but sometimes even the users don&#8217;t know what they want <img src='http://qablog.practitest.com/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' />  Isn&#8217;t that what product managers are for?</p>
]]></content:encoded>
	</item>
</channel>
</rss>
