@GreyCloud We've uploaded my 101 Tips cheat sheet to this post. See above. The A/V equipment was optimized to record powerpoint slides at 20pt, and there was no way i could crank up the Environment Font that high (and much less do 101 demos). So, I debated
(even up to the last second) what resolution to use, but finally i decided to optimize for the in-house audience so that they could all get a copy of the book.
Hi all, Sorry for the delay in me responding. i've been speaking at TechEd Australia all week. Just getting a chance now.
1. if you see abandoned projects, contact me directly with the URLs. We scan for abandoned projects once a month. Maybe they are still relatively new projects or we're missing them. We're always looking for suggestions to tweak our abandonment criteria.
2. I'd love to hear ideas how to improve the ratings feature. Rating the individual releases seems to be the best approach i've come across.
3. If you like WoW, you're going to love Rawr and Tweetcraft. If you are an AJAX developer, you'll want to check out the AJAX Control Toolkit. What i'm discovering from my "codeplex" search in TweetDeck is that there's a popular project for each niche. I
see that Nic has left you with a list that i provided him before i jumped on the plane for #auteched.
1. We recently implemented new features to improve the Issue Tracker to receive notifications via email. Back in April, we added the ability for an user to get an email whenever an issue they were tracking was updated or had a new comment. Just last month,
we added the ability for a project owner or any other user to subscribe at the project-level to get an email notification for new Issues, new comments, and status changes. I'm hoping these new features will help project owners respond to issues in a timely
2. I like the idea of related bugs. Could be interesting.
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 =)
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.
Record and playback is definitely one way to automate tests. Our primary method is to use a combination of MSAA and Win32 api calls, like sending messages to a control as you describe above. We drive the UI (meaning we use the mouse and/or keyboard to
click on menus, buttons, etc) as much as possible to simulate an actual user, and it does a really good job.
We have a very strong focus on accessibility in our Visual Studio 2005 release. In addition, we have been working and testing with both JAWS, the screen reader Kenneth mentions in the video, produced by Freedom Scientific, and Window Eyes, a screen reader
produced by GW Micro. If anyone has any feedback regarding accessibility of either Visual Studio .NET 2003 or Visual Studio 2005, please feel free to contact me via my blog at
Almost always, devs are very appreciative of finding bugs in their code. It's during those buddy tests (ie, doing ad-hoc testing before the developer checks-in) where you find 8 unique crashes in 30 minutes that you find yourself being asked to go away,
but in a polite way of course. =)
I think the "us versus them" feeling comes from the nature of the work we do. Our job is to break the dev's code. In my mind, the dev can never write code that I can't find issues with; otherwise, i'm not doing my job. Many times, i've sat looking at a piece
of UI or a piece of code thinking, "what am i missing? what am i not testing?" when i stop finding bugs.
I definitely wouldn't say that i'm in conflict with my dev. A tester must be able to work effectively with his/her developer in order to be successful testing the feature. Chris, the dev for window management (the feature i currently own testing), laughed
when I showed him this video. he said, "Yep, i can definitely see you saying that." =)
In retrospect, maybe having placed a microphone next to one of the speakers (provided there wasn't any feedback) would have allowed people to hear a screen reader navigating the Start - Run Dialog. I wouldn't make for a very good screen reader. =)
If you're running Windows XP and you're curious what a basic screen reader sounds like, Windows XP comes with a basic screen reader called Narrator. Just go to Accessories - Accessibility - Narrator.
I mentioned two other screen readers, JAWS and Window-Eyes. Both have demo versions available on their websites.