<?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/"
	xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Comments on: Quality Assurance</title>
	<atom:link href="http://jamesdixon.wordpress.com/the-bees-and-the-trees-part-ii/quality-assurance/feed/" rel="self" type="application/rss+xml" />
	<link>http://jamesdixon.wordpress.com</link>
	<description>James Dixon's thoughts on commercial open source and open source business intelligence</description>
	<lastBuildDate>Fri, 19 Oct 2012 09:38:34 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.com/</generator>
	<item>
		<title>By: &#8220;Who&#8217;s on first&#8230;&#8221; &#124; Shizen008&#039;s Blog</title>
		<link>http://jamesdixon.wordpress.com/the-bees-and-the-trees-part-ii/quality-assurance/#comment-4828</link>
		<dc:creator><![CDATA[&#8220;Who&#8217;s on first&#8230;&#8221; &#124; Shizen008&#039;s Blog]]></dc:creator>
		<pubDate>Sun, 25 Dec 2011 23:44:40 +0000</pubDate>
		<guid isPermaLink="false">http://jamesdixon.wordpress.com/?page_id=344#comment-4828</guid>
		<description><![CDATA[[...] Designers, Developers, and QA aren&#8217;t the only stake holders.Â  In the end, it&#8217;s also the end users and how effective the product becomes.Â  When they are able to speak up in the beginning, the product I believe tends to be in a better quality state.Â  I am not the only one thinking this way, see James Dixon&#8217;s blog about open source quality assurance. [...]]]></description>
		<content:encoded><![CDATA[<p>[...] Designers, Developers, and QA aren&#8217;t the only stake holders.Â  In the end, it&#8217;s also the end users and how effective the product becomes.Â  When they are able to speak up in the beginning, the product I believe tends to be in a better quality state.Â  I am not the only one thinking this way, see James Dixon&#8217;s blog about open source quality assurance. [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Luther Sarkodie</title>
		<link>http://jamesdixon.wordpress.com/the-bees-and-the-trees-part-ii/quality-assurance/#comment-546</link>
		<dc:creator><![CDATA[Luther Sarkodie]]></dc:creator>
		<pubDate>Mon, 22 Feb 2010 21:09:45 +0000</pubDate>
		<guid isPermaLink="false">http://jamesdixon.wordpress.com/?page_id=344#comment-546</guid>
		<description><![CDATA[]]></description>
		<content:encoded><![CDATA[<p>Most testers find themselves outnumbered by devs. In my instance it’s almost 10 to 1. (The wanted proportion is a spent discussion I’d like to stave off in this post.) Instead, I would like to bitch about a problem I’ve found as I amass more projects to test. Assuming my ten devs are distributed between five projects (or app modules), each dev must attend to merely the Feature Review/Design group meetings for the project they are answerable for. Nevertheless, the tester must pay heed all five. Do you see a problem here? Let’s do the mathematics for a 40 hour work workweek. If each project’s Feature Review/Design meetings eat up eight hours per week, every dev will own 32 hours left to write code. Each tester is left with ZERO hours to run code! The preceding scenario is not that much of an exaggeration for my team. The tester has no choice but to cut some of these meetings just to wedge in a little testing. The tester is required to &#8220;stay in the know&#8221; about all projects (and how those projects integrate with each other), while the dev can often focus on a lone project. I think the foregoing problem is an oversight of many managers. I doubt it gets acknowledged because the testers&#8217; time is being nickel and dimed away. Yet most testers and managers will tell you, “It’s a no-brainer! The tester should attend to all design inspections and feature walkthroughs…testing should initiate as early as possible”. I concur. But it is an irrational anticipation if you staff your team like this.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
