The Power of the Mute Button

A big challenge any remote presenter faces is that it's too darned easy for an audience participant to tune out. You're already sitting in front of your computer, watching a demo, and then an important email shows up. Or an IM pops in. Or someone drops by your cube and wants to chat. So you start typing, or chatting, and if you haven't muted your phone line, that background noise is going to come through.

This is frustrating for the person presenting. Imagine if this scenario played out in a conference room. There, the presenter would politely ask to table the side discussion to later, or see if it was something he could help with. If it wasn't related to the item being presented, the people could step out of the room and not distract anyone. But when you're demoing remotely, this isn't an option. In that situation, you need to be able to mute the person remotely. If you can't, you're never going to get your message across.

Case in point:
A few months back, I attended a webinar that Microsoft was putting on about Visual Studio 2010. The presenter had to stop several times to ask people to mute their lines. Now here's the thing - if you're the person who's stopped paying attention to the call and is now typing, chatting, or playing video games, you're not going to notice the presenter asking people to mute. So he had to contend with a metric-crap ton of background noise. As an audience member, it was extremely frustrating to try and filter out the noise from the presenter's message, and to be honest, I can't remember much of what he talked about.

When I give remote demos, I have the ability to mute people remotely when stuff like this happens. The program I use (GoToMeeting) also has a chat window. So if there's a lot of background noise coming from a particular participant, I'll say "Ok, folks, it sounds like -insertPersonNameHere- has a really sensitive microphone that's picking up a lot of background noise. I'm going to mute them, but if they have questions, they'll be able to let me know via the chat window, and I'll unmute them."

So make sure you have the ability to mute people remotely. It will only make your presentations run smoother both for yourself, and for your audience.

Learning Regular Expressions

During the course of your automated test efforts, you'll come across regular expressions. Regular expressions are an extremely powerful tool, but they're daunting when you're first learning them. I mean, really, can you just look at this line of code and tell me what it does?

re = /^((4\d{3})|(5[1-5]\d{2}))[ -]?(\d{4}[ -]?){3}$|^(3[4,7]\d{2})[ -]?\d{6}[ -]?\d{5}$/;

The above regular expression is used to verify that a credit card number is valid. (This is also a great example of why you should comment your code.) Such an expression is very useful, but how the heck do you write these things?

Fortunately the good folks over at Regular-Expressions.info have put together a great tutorial that explains regular expressions in detail. You'll learn what regular expressions are good for and how to write them. This is an extremely useful skill for an automator. You can perform more robust verifications with your tests, and you can use them to do other tasks like pull particular strings out of log files, or ensure email addresses are properly formatted.

It's also handy to have a tool that you can use to verify your expressions are working properly. For that, I recommend Roy Osherove's Regulator. It's free, and allows you to test your regular expression against a variety of inputs, allowing you to make sure you'll correctly match the patterns you're expecting.

Happy Automating!

Test Workflows, Not Features

So you've got a shiny new feature in your application. Maybe it's a new button, or a new context menu item. You get your new build, load it up, and click the button. It works - Huzzah! Test passed, move on to the next feature!

Whoa, slow down there, chief. You've verified that the feature works in isolation, but how will your end users be using this button? Will they be clicking this button all by itself every time? Chances are there's a whole workflow that this button will be involved with, and you need to make sure you understand what that workflow is. So figure out what your users are going to do with this feature, and how they're going to do it. What other steps will they be performing before using this feature? What options could they set that would impact how this feature behaves?

Only when you have a good grasp on how the new feature will actually be used can you say whether or not it's working properly. Design your test cases to reflect real world behavior, and your application will be much more solid when it ships.

Forcing a BSOD

The Blue Screen of Death is one of the most unpleasant events a person can face. It ranks right up there with doing your income taxes, the unexpected visit from your least favorite relative, and hemmorhodial flare ups. However, there are times when you actually want to have a BSOD event happen. Maybe you're doing some extreme failover testing, or maybe you want to show how your software can recover from a disastrous situation.

If that's the case, then you need a consistent way to force a BSOD. The steps below show you how to do it:

1. Go to Start>Run, and launch the Registry Editor (Regedit.exe).
2. Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters.
3. Go to Edit, select New | DWORD Value and name the new value CrashOnCtrlScroll.
4. Double-click the CrashOnCtrlScroll DWORD Value, type 1 in the Value Data textbox, and click OK.
5. Close the Registry Editor and restart your system.

When you want to force a BSOD, press and hold the [Ctrl] key on the right side of your keyboard, and then press the [ScrollLock] key twice. The BSOD will appear.

Note: If your system reboots instead of displaying the BSOD, you'll have to disable the Automatically Restart setting in the System Properties dialog box. To do so, follow these steps:

1. Press [Windows]-Break.
2. Select the Advanced tab.
3. Click the Settings button in the Startup And Recovery panel.
4. Clear the Automatically Restart check box in the System Failure panel.
5. Click OK twice.