For those who didn't see Karit's comment on yesterday's post on having a backup browser when testing with a proxy, I wanted to share the tool he mentioned. Karit suggested using FoxyProxy, a Firefox extension which automatically switches an internet connection across one or more proxy servers based on URL patterns.

Looks to be a cool little plug-in. Thanks for the tip Karit. I'll likely end up trying it out next week.

There are many times as testers that we end up using proxy servers. For me, I find I use them a lot when doing performance and security testing, but I've even had the occasion to use them when doing functional testing. This can sometimes create issues:

• sometimes changing the proxy settings makes it impossible for you to use the browser for other tasks (for example, if you're intercepting all the outgoing requests so you can edit them)


• sometimes using the browser for other tasks will mess up what you're testing (for example, if you're recording HTTP traffic for a load test)

A simple way to solve this is to have a backup browser. I almost always test with Firefox, so that means that (depending on my machine) I'll have Internet Explorer or Safari as a backup. This may seem like a really simple tip, but ask yourself this: Is your backup browser setup to do everything you'd need it to do if you couldn't use your main one?

For me, that would include: equivalent toolbars, up to date bookmarks, saved passwords for common sites (like JIRA, SharePoint, etc...), and making sure all updates/patches are in place. I hate it when I have to stop testing to get my backup browser in a place where I can actually use it. So I try to make sure it never gets too far out of sync.

As testers, we get a lot of "FYI" meeting invites. When you find that you're getting invited to meetings and you're not sure why you need to be there, take a second and reply to the person who scheduled the meeting and ask "What's my role in the meeting?" This allows you to better know what's expected, and based on their response it also creates an opportunity for you to express that you might have higher priority work to do or to ask if you can dial-in instead of attending in person.

At last night's IWST on time management, Chris Wingate shared a technique he uses when trying to coordinate performance testing for projects. Chris schedules two 30 minute meetings each week. Instead of constantly following up with people to see where they are and to see if he has everything he needs to proceed, he focuses on his part of the project and lets the project manager get and manage other people's commitments. This allows him to work several projects at the same time, because in each of them he's focusing only on his piece of the work and not trying to duplicate the effort of the PM.

Testers have a plethora of tools which are used in testing and not just the big fancy expensive tools either, but the small and often innovative ones too, such as the "Hoffman Box".

Sometimes though tester's find innovative ways of using test tools in the 'real' world.

One company I know of, had a migration exercise that due to regulatory reasons could not be performed through importing and exporting data. It looked as if they were faced with an enormous manual operation, where operators were going to have to manually input the data into the new system.

Until a test manager suggested that Quick Test Pro be used to automate the exercise.  He suggested creating scripts to simulate the operator and the data entry tasks to be performed. 

When the scripts ran, they had a group of testers on hand in case of failure, but no way was the team as extensive as originally planned.

Perhaps there are test tools are in your toolbox that users and operators would find helpful?