<?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: How do we speed up software testing? Write better requirements!</title>
	<atom:link href="http://www.b2ttraining.com/2006/08/07/how-do-we-speed-up-software-testing-write-better-requirements/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.b2ttraining.com/2006/08/07/how-do-we-speed-up-software-testing-write-better-requirements/</link>
	<description>Connecting Business Requirements to Technology</description>
	<lastBuildDate>Wed, 28 Jul 2010 20:41:26 -0500</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.5</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Prem</title>
		<link>http://www.b2ttraining.com/2006/08/07/how-do-we-speed-up-software-testing-write-better-requirements/comment-page-1/#comment-3716</link>
		<dc:creator>Prem</dc:creator>
		<pubDate>Wed, 24 Jun 2009 10:25:09 +0000</pubDate>
		<guid isPermaLink="false">http://www.b2ttraining.com/2006/08/07/how-do-we-speed-up-software-testing-write-better-requirements/#comment-3716</guid>
		<description>Very good article, i really like it.  I am doing a bit on research about Software Testing and i found also macrotesting www.macrotesting.com to be very good source for software testing.

Thanks for your article

Regards,
Prem</description>
		<content:encoded><![CDATA[<p>Very good article, i really like it.  I am doing a bit on research about Software Testing and i found also macrotesting <a href="http://www.macrotesting.com" rel="nofollow">http://www.macrotesting.com</a> to be very good source for software testing.</p>
<p>Thanks for your article</p>
<p>Regards,<br />
Prem</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: manesh</title>
		<link>http://www.b2ttraining.com/2006/08/07/how-do-we-speed-up-software-testing-write-better-requirements/comment-page-1/#comment-28</link>
		<dc:creator>manesh</dc:creator>
		<pubDate>Wed, 13 Sep 2006 03:13:56 +0000</pubDate>
		<guid isPermaLink="false">http://www.b2ttraining.com/2006/08/07/how-do-we-speed-up-software-testing-write-better-requirements/#comment-28</guid>
		<description>My aporoach - 1) req specs &#38; detailed design from the development is matched. 2) prepare a high level test strategy and send the same out to business/solutions and development 3) sign off process on requirements &#38; detailed design docs 4) send out scenarios on the project to business/solutions and development for review and sign off. This is a tested and really a practical approach. Thanks manesh</description>
		<content:encoded><![CDATA[<p>My aporoach &#8211; 1) req specs &#38;#38; detailed design from the development is matched. 2) prepare a high level test strategy and send the same out to business/solutions and development 3) sign off process on requirements &#38;#38; detailed design docs 4) send out scenarios on the project to business/solutions and development for review and sign off. This is a tested and really a practical approach. Thanks manesh</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Frederica</title>
		<link>http://www.b2ttraining.com/2006/08/07/how-do-we-speed-up-software-testing-write-better-requirements/comment-page-1/#comment-27</link>
		<dc:creator>Frederica</dc:creator>
		<pubDate>Sun, 10 Sep 2006 13:07:10 +0000</pubDate>
		<guid isPermaLink="false">http://www.b2ttraining.com/2006/08/07/how-do-we-speed-up-software-testing-write-better-requirements/#comment-27</guid>
		<description>Great practical ideas by Raaj. I sometimes force the business to create their own UAT plan which the BA and development team then approve. This ensures that the expectations in UAT match the requirements laid out during the analysis phase. I find almost all project issues found in testing or UAT can be traced back to the analysis/requirements gathering phase. Which always brings us back to the question of responsibility. Typically the BA is a single person. It is his responsibility to guide the business through what&nbsp;it really wants and what&nbsp;it might be leaving out. The BA might not be completely capable of doing that, though, especially early in a customer relationship - they may not have full expertise in the system or strong enough knowledge of how the customer thinks. A full process including change request forms and budget/scheduling impacts help lead the business into better thinking in the future. Meanwhile it is important that the entire team - development &#38; QA included - understands that ultimately the project is being done for a customer. Development &#38; QA must be encouraged to push back on requirements that are unclear or sound like a bad idea. Ultimately it all comes back to requirements, and ultimately the BA must lead all components of the team to recognize their own responsibility and input into requirements. This improves the testing experience and the overall project delivery.</description>
		<content:encoded><![CDATA[<p>Great practical ideas by Raaj. I sometimes force the business to create their own UAT plan which the BA and development team then approve. This ensures that the expectations in UAT match the requirements laid out during the analysis phase. I find almost all project issues found in testing or UAT can be traced back to the analysis/requirements gathering phase. Which always brings us back to the question of responsibility. Typically the BA is a single person. It is his responsibility to guide the business through what&#38;nbsp;it really wants and what&#38;nbsp;it might be leaving out. The BA might not be completely capable of doing that, though, especially early in a customer relationship &#8211; they may not have full expertise in the system or strong enough knowledge of how the customer thinks. A full process including change request forms and budget/scheduling impacts help lead the business into better thinking in the future. Meanwhile it is important that the entire team &#8211; development &#38;#38; QA included &#8211; understands that ultimately the project is being done for a customer. Development &#38;#38; QA must be encouraged to push back on requirements that are unclear or sound like a bad idea. Ultimately it all comes back to requirements, and ultimately the BA must lead all components of the team to recognize their own responsibility and input into requirements. This improves the testing experience and the overall project delivery.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: raaj</title>
		<link>http://www.b2ttraining.com/2006/08/07/how-do-we-speed-up-software-testing-write-better-requirements/comment-page-1/#comment-26</link>
		<dc:creator>raaj</dc:creator>
		<pubDate>Thu, 07 Sep 2006 17:37:02 +0000</pubDate>
		<guid isPermaLink="false">http://www.b2ttraining.com/2006/08/07/how-do-we-speed-up-software-testing-write-better-requirements/#comment-26</guid>
		<description>What I try to do is the following- 1. Have the test plan approved by major stakeholders. 2. Schedule testing-time - gather users/testers for a while, lock them up in a room:) and try to get as many steps as possible. 3. Send a daily update and provide a deadline. 4. Hope for the best!</description>
		<content:encoded><![CDATA[<p>What I try to do is the following- 1. Have the test plan approved by major stakeholders. 2. Schedule testing-time &#8211; gather users/testers for a while, lock them up in a room:) and try to get as many steps as possible. 3. Send a daily update and provide a deadline. 4. Hope for the best!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Alexandra B.</title>
		<link>http://www.b2ttraining.com/2006/08/07/how-do-we-speed-up-software-testing-write-better-requirements/comment-page-1/#comment-25</link>
		<dc:creator>Alexandra B.</dc:creator>
		<pubDate>Tue, 29 Aug 2006 18:25:48 +0000</pubDate>
		<guid isPermaLink="false">http://www.b2ttraining.com/2006/08/07/how-do-we-speed-up-software-testing-write-better-requirements/#comment-25</guid>
		<description>I found that the business owners either partially communicate the business problem or due to lack of business process, they don&#039;t identify the problem well. Of course bad requirements delay the project all together. But software testing can never be 100% satisfactory, so business needs to understand it and establish acceptance testing. It could be 90% -99% whatever is acceptable to the business. Also, test scripts can cover most often used scenarios or path; other tests can be done ad-hoc. I would also highly recommend a use of a testing tool where testing can be monitored and measured. With that said BSA really plays a vital role on a project especially software implementation.</description>
		<content:encoded><![CDATA[<p>I found that the business owners either partially communicate the business problem or due to lack of business process, they don&#8217;t identify the problem well. Of course bad requirements delay the project all together. But software testing can never be 100% satisfactory, so business needs to understand it and establish acceptance testing. It could be 90% -99% whatever is acceptable to the business. Also, test scripts can cover most often used scenarios or path; other tests can be done ad-hoc. I would also highly recommend a use of a testing tool where testing can be monitored and measured. With that said BSA really plays a vital role on a project especially software implementation.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ronny De Winter</title>
		<link>http://www.b2ttraining.com/2006/08/07/how-do-we-speed-up-software-testing-write-better-requirements/comment-page-1/#comment-24</link>
		<dc:creator>Ronny De Winter</dc:creator>
		<pubDate>Wed, 09 Aug 2006 21:11:53 +0000</pubDate>
		<guid isPermaLink="false">http://www.b2ttraining.com/2006/08/07/how-do-we-speed-up-software-testing-write-better-requirements/#comment-24</guid>
		<description>CMMI does handle requirements! In the staged model you already encounter it in the first step towards maturity level 2: the Requirements Management process area. I agree requirements engineering is a far more effective process than any kind of test process to develop high quality software products. In my blog&nbsp;I frequently write on requirements management and other process improvement techniques: and - Most useful requirements processes - Handling late requirements - Use Test Cases to Clarify Requirements (yes, as a tester you also can help in the requirements defintion, see also agile practices like test-driven development) Enjoy, Ronny http://software-quality.blogspot.com The Software Quality Weblog</description>
		<content:encoded><![CDATA[<p>CMMI does handle requirements! In the staged model you already encounter it in the first step towards maturity level 2: the Requirements Management process area. I agree requirements engineering is a far more effective process than any kind of test process to develop high quality software products. In my blog&#38;nbsp;I frequently write on requirements management and other process improvement techniques: and &#8211; Most useful requirements processes &#8211; Handling late requirements &#8211; Use Test Cases to Clarify Requirements (yes, as a tester you also can help in the requirements defintion, see also agile practices like test-driven development) Enjoy, Ronny <a href="http://software-quality.blogspot.com" rel="nofollow">http://software-quality.blogspot.com</a> The Software Quality Weblog</p>
]]></content:encoded>
	</item>
</channel>
</rss>
