<?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: Do you make these 7 test planning mistakes?</title>
	<atom:link href="http://www.guerrillaprojectmanagement.com/do-you-make-these-7-test-planning-mistakes/feed" rel="self" type="application/rss+xml" />
	<link>http://www.guerrillaprojectmanagement.com/do-you-make-these-7-test-planning-mistakes</link>
	<description></description>
	<lastBuildDate>Wed, 08 Sep 2010 09:30:28 -0400</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: samad_aidane</title>
		<link>http://www.guerrillaprojectmanagement.com/do-you-make-these-7-test-planning-mistakes/comment-page-1#comment-351</link>
		<dc:creator>samad_aidane</dc:creator>
		<pubDate>Tue, 16 Mar 2010 06:30:33 +0000</pubDate>
		<guid isPermaLink="false">http://www.guerrillaprojectmanagement.com/?p=198#comment-351</guid>
		<description>Shim, Thank you for stopping by and commenting. 

I agree. I think testing does not get the attention it deserves. Also, I feel bad for how test teams get treated on some projects as second class citizens. I always take care of my test team because they end up saving my projects from all the blind spots that surround them. 

I see the absence of establishing the right process for managing test effort as one of the big sources for scope creep. I worked on projects where we spend all the time making sure the requirements are tights but we kept the test scope wide open. In the middle of one my projects, the organization hired a zealous QA Manager who saw themselves above any budget or schedule constrains and kept prolonging the test phase and would never agree to a Go Live date. I learned a big lesson on that project and I vowed to never get burned that way again.  Now I spend a lot of time with my test team on the test plan and acceptance criteria for each test case. I want to make sure we know what will be tested, where (environment), when, by whom and for how long. I also now have 3 categories of bugs. 1-showstopper, 2-can be fixed after the Go live, and 3-can be fixed sometime in the future after the go live. this way we only focus on the showstoppers as we get closer the Go Live date and not let this date be held hostage by the customer or QA team.

Thank you again.</description>
		<content:encoded><![CDATA[<p>Shim, Thank you for stopping by and commenting. </p>
<p>I agree. I think testing does not get the attention it deserves. Also, I feel bad for how test teams get treated on some projects as second class citizens. I always take care of my test team because they end up saving my projects from all the blind spots that surround them. </p>
<p>I see the absence of establishing the right process for managing test effort as one of the big sources for scope creep. I worked on projects where we spend all the time making sure the requirements are tights but we kept the test scope wide open. In the middle of one my projects, the organization hired a zealous QA Manager who saw themselves above any budget or schedule constrains and kept prolonging the test phase and would never agree to a Go Live date. I learned a big lesson on that project and I vowed to never get burned that way again.  Now I spend a lot of time with my test team on the test plan and acceptance criteria for each test case. I want to make sure we know what will be tested, where (environment), when, by whom and for how long. I also now have 3 categories of bugs. 1-showstopper, 2-can be fixed after the Go live, and 3-can be fixed sometime in the future after the go live. this way we only focus on the showstoppers as we get closer the Go Live date and not let this date be held hostage by the customer or QA team.</p>
<p>Thank you again.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Shim Marom</title>
		<link>http://www.guerrillaprojectmanagement.com/do-you-make-these-7-test-planning-mistakes/comment-page-1#comment-337</link>
		<dc:creator>Shim Marom</dc:creator>
		<pubDate>Sat, 13 Mar 2010 22:55:25 +0000</pubDate>
		<guid isPermaLink="false">http://www.guerrillaprojectmanagement.com/?p=198#comment-337</guid>
		<description>Hi Samad, just read your post and it is spot on. Just about the sort of issues we would face if we did not establish the right process for managing our testing effort from start to end.

Cheers, Shim
www.quantmleap.com</description>
		<content:encoded><![CDATA[<p>Hi Samad, just read your post and it is spot on. Just about the sort of issues we would face if we did not establish the right process for managing our testing effort from start to end.</p>
<p>Cheers, Shim<br />
<a href="http://www.quantmleap.com" rel="nofollow">http://www.quantmleap.com</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: samad_aidane</title>
		<link>http://www.guerrillaprojectmanagement.com/do-you-make-these-7-test-planning-mistakes/comment-page-1#comment-248</link>
		<dc:creator>samad_aidane</dc:creator>
		<pubDate>Tue, 23 Feb 2010 21:12:16 +0000</pubDate>
		<guid isPermaLink="false">http://www.guerrillaprojectmanagement.com/?p=198#comment-248</guid>
		<description>Don, thank you so much for taking the time to read the post and comment. Unfortunately, testing gets shortchanged and is the first to be cut when deadlines and/or budgets become priority. I think as project managers we need to support our test teams and make sure that we follow the principles as those promoted by the V model. Thank  you again. I will be checking you website www.pmotogo.com</description>
		<content:encoded><![CDATA[<p>Don, thank you so much for taking the time to read the post and comment. Unfortunately, testing gets shortchanged and is the first to be cut when deadlines and/or budgets become priority. I think as project managers we need to support our test teams and make sure that we follow the principles as those promoted by the V model. Thank  you again. I will be checking you website <a href="http://www.pmotogo.com" rel="nofollow">http://www.pmotogo.com</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Don R. James</title>
		<link>http://www.guerrillaprojectmanagement.com/do-you-make-these-7-test-planning-mistakes/comment-page-1#comment-243</link>
		<dc:creator>Don R. James</dc:creator>
		<pubDate>Sun, 21 Feb 2010 20:55:30 +0000</pubDate>
		<guid isPermaLink="false">http://www.guerrillaprojectmanagement.com/?p=198#comment-243</guid>
		<description>Excellent!
The &#039;V&#039; Model gives us the locations for testing and the locations where test plans should be developed.
Too many times, we forget that a comprehensive review of the baselined requirements v. the test plans (and scripts, and scenarios) is a System Test.
Think about it.
DR J</description>
		<content:encoded><![CDATA[<p>Excellent!<br />
The &#8216;V&#8217; Model gives us the locations for testing and the locations where test plans should be developed.<br />
Too many times, we forget that a comprehensive review of the baselined requirements v. the test plans (and scripts, and scenarios) is a System Test.<br />
Think about it.<br />
DR J</p>
]]></content:encoded>
	</item>
</channel>
</rss>
