<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" media="screen" href="/styles/xslt/rss.xslt"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:media="http://search.yahoo.com/mrss/" xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd" xmlns:c9="http://channel9.msdn.com">
<channel>
	<title>Comment Feed for Channel 9 - Sara Ford - Finding and Logging a Bug (Maddog Part 4)</title>
	<atom:link rel="self" type="application/rss+xml" href="http://channel9.msdn.com/Blogs/TheChannel9Team/Sara-Ford-Finding-and-Logging-a-Bug-Maddog-Part-4/RSS"></atom:link>
	<image>
		<url>http://ecn.channel9.msdn.com/o9/previewImages/100/38889_100x75.jpg</url>
		<title>Channel 9 - Sara Ford - Finding and Logging a Bug (Maddog Part 4)</title>
		<link></link>
	</image>
	<description>Logging bugs is easy.&amp;nbsp; Logging “QA” quality bugs takes a little more time, energy, and focus.&amp;nbsp; Logging a bug requires a well-written title and the fewest number of steps to reproduce the bug.


In this clip, SaraF “raids” a product bug found while investigating a test case failure, demo’ing how to minimize the number of repro steps and how to write an effective bug title.


For more information on writing a good bug report check out 
this post from the Product Feedback Center blog. 

For more Devdiv updates check out our C9 site: 
http://channel9.msdn.com/devdiv 
- josh</description>
	<link></link>
	<language>en</language>
	<pubDate>Thu, 20 Jun 2013 03:00:44 GMT</pubDate>
	<lastBuildDate>Thu, 20 Jun 2013 03:00:44 GMT</lastBuildDate>
	<generator>Rev9</generator>
	<item>
		<title>Re: Sara Ford - Finding and Logging a Bug (Maddog Part 4)</title>
		<description>
			<![CDATA[Now let's find the guilty programmer and have him fix this bug.<p>posted by ZippyV</p>]]>
		</description>
		<link>http://channel9.msdn.com/Blogs/TheChannel9Team/Sara-Ford-Finding-and-Logging-a-Bug-Maddog-Part-4#c632434182910000000</link>
		<pubDate>Tue, 08 Feb 2005 00:11:31 GMT</pubDate>
		<guid isPermaLink="true">http://channel9.msdn.com/Blogs/TheChannel9Team/Sara-Ford-Finding-and-Logging-a-Bug-Maddog-Part-4#c632434182910000000</guid>
		<dc:creator>ZippyV</dc:creator>
	</item>
	<item>
		<title>Re: Sara Ford - Finding and Logging a Bug (Maddog Part 4)</title>
		<description>
			<![CDATA[This bug has been postponed, which was the resolution i had expected.&nbsp; The bug didn't meet the bar, meaning there were too many other more important bugs to fix for Whidbey.&nbsp; And, as i said in the video, i don't think you would want me to delay the Whidbey
 ship date because of this bug.&nbsp; I know I wouldn't want to.&nbsp; =)<br>
<br>
Also, i don't think the programmer is the guilty party here, if there even is a guilty party.&nbsp; The triage team said that this was how the data tip was designed, and from their usability studies, no one had run into this issue before.&nbsp; I think that's what makes
 me&nbsp;a good tester - i don't interact with UI the same way most people do.&nbsp; So, I can find these&nbsp;scenarios and get triage teams to make the right call, before the users run into them.<br>
<br>
Thanks!<br>
-sara<p>posted by saraford</p>]]>
		</description>
		<link>http://channel9.msdn.com/Blogs/TheChannel9Team/Sara-Ford-Finding-and-Logging-a-Bug-Maddog-Part-4#c632434834520000000</link>
		<pubDate>Tue, 08 Feb 2005 18:17:32 GMT</pubDate>
		<guid isPermaLink="true">http://channel9.msdn.com/Blogs/TheChannel9Team/Sara-Ford-Finding-and-Logging-a-Bug-Maddog-Part-4#c632434834520000000</guid>
		<dc:creator>saraford</dc:creator>
	</item>
	<item>
		<title>Re: Sara Ford - Finding and Logging a Bug (Maddog Part 4)</title>
		<description>
			<![CDATA[
<p>I usually like my tests to all&nbsp;pass. If you get a bug that&nbsp;is postponed do you just live with a failing test, do you remove the scenario for now, or do you &quot;reverse&quot; test it (test for the wrong results until they fix it)? Is this the first time that this
 test was run?<br>
<br>
<br>
Mark</p>
<p>posted by MarkC</p>]]>
		</description>
		<link>http://channel9.msdn.com/Blogs/TheChannel9Team/Sara-Ford-Finding-and-Logging-a-Bug-Maddog-Part-4#c632436673660000000</link>
		<pubDate>Thu, 10 Feb 2005 21:22:46 GMT</pubDate>
		<guid isPermaLink="true">http://channel9.msdn.com/Blogs/TheChannel9Team/Sara-Ford-Finding-and-Logging-a-Bug-Maddog-Part-4#c632436673660000000</guid>
		<dc:creator>MarkC</dc:creator>
	</item>
	<item>
		<title>Re: Sara Ford - Finding and Logging a Bug (Maddog Part 4)</title>
		<description>
			<![CDATA[Hi Mark, good questions.&nbsp; We want all tests to pass, so if a bug isn't going to be fixed, we have to either find a workaround or change the verification.&nbsp; If we know that the bug will be fixed, we continue to let the test case fail until the fix is checked-in.&nbsp;
 Bugs causing the nighlties to fail need to be fixed as soon as possible.<br>
<br>
This test has been running for as long as we've had an editor =)<br>
<br>
Thanks!<br>
-sara<p>posted by saraford</p>]]>
		</description>
		<link>http://channel9.msdn.com/Blogs/TheChannel9Team/Sara-Ford-Finding-and-Logging-a-Bug-Maddog-Part-4#c632436919210000000</link>
		<pubDate>Fri, 11 Feb 2005 04:12:01 GMT</pubDate>
		<guid isPermaLink="true">http://channel9.msdn.com/Blogs/TheChannel9Team/Sara-Ford-Finding-and-Logging-a-Bug-Maddog-Part-4#c632436919210000000</guid>
		<dc:creator>saraford</dc:creator>
	</item>
</channel>
</rss>