Sara Ford - Finding and Logging a Bug (Maddog Part 4)

Posted: Feb 07, 2005 at 2:15 PM

By: The Channel 9 Team

(1)

78,653 Views

4 Comments

Video format

Option selected may change based on video formats available and browser capability.

Auto

Use our suggested format for this video.

Smooth Streaming

Adaptive bitrate streaming - little buffering but lower video quality at times of low bandwidth. Silverlight 5 required

Progressive

Traditional buffered video format. Silverlight 5 required

HTML5

For browsers that support H.264 MP4 or WebM video playback such as:
IE9+, Firefox 4+, Chrome 5+, or Safari 4+.

Flash

For browsers that have the Adobe Flash Player plugin installed.

Logging bugs is easy. Logging “QA” quality bugs takes a little more time, energy, and focus. 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

Follow the Discussion

Follow
Oops, something didn't work.

Try again?

Sign In to be begin to follow these comments

What does this mean?
Following an item on Channel 9 allows you to watch for new content and comments that you are interested in. You need to be signed in to Channel 9 to use this feature.

Getting "follow" information

Stop following these comments

Start following these comments

What does this mean?
Following an item on Channel 9 allows you to watch for new content and comments that you are interested in and view them all on your notifications page.

Removing your "follow"

Setting up your "follow"

Did you know you can
sign up for email notifications?
- Subscribe to this comments

ZippyV Fired Up

Feb 07, 2005 at 4:11 PM

Now let's find the guilty programmer and have him fix this bug.
saraford

Feb 08, 2005 at 10:17 AM

This bug has been postponed, which was the resolution i had expected. The bug didn't meet the bar, meaning there were too many other more important bugs to fix for Whidbey. 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. I know I wouldn't want to. =)

Also, i don't think the programmer is the guilty party here, if there even is a guilty party. 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. I think that's what makes me a good tester - i don't interact with UI the same way most people do. So, I can find these scenarios and get triage teams to make the right call, before the users run into them.

Thanks!
-sara
MarkC

Feb 10, 2005 at 1:22 PM

I usually like my tests to all pass. If you get a bug that is postponed do you just live with a failing test, do you remove the scenario for now, or do you "reverse" test it (test for the wrong results until they fix it)? Is this the first time that this test was run?

Mark
saraford

Feb 10, 2005 at 8:12 PM

Hi Mark, good questions. 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. If we know that the bug will be fixed, we continue to let the test case fail until the fix is checked-in. Bugs causing the nighlties to fail need to be fixed as soon as possible.

This test has been running for as long as we've had an editor =)

Thanks!
-sara