FoxyProxy
Looks to be a cool little plug-in. Thanks for the tip Karit. I'll likely end up trying it out next week.
Keep a backup browser handy
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.
Dealing with too many meetings
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.
Let the PM manage getting commitments for you
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.
Test Tools don’t have to be just for testing
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?
Simple status dashboard
For the last year or so I've been using a simple status dashboard to coordinate testing for releases. I find an easy way to share the dashboard is to use a spreadsheet Google doc. Using a Google doc makes it easy for everyone to make updates and see updates as they happen.
Here are the columns I'm currently tracking:
- Client
- Release Number
- Code Complete Date
- First Pass Test Complete Date
- CM Review Date
- Regression Test Complete Date
- UAT Date
- Production Date
- Development Status
- Test Status
- Testing Lead
- Deployment Ticket Number
- Scope Summary
It looks like a lot, but it all fits on one screen (no scrolling needed) and each row in the spreadsheet represents a separate release. If a date is in the past, the cell is colored red. If it's today, it's colored yellow. And if it's done, it's colored green. With one quick glance, you get a high-level view of all the releases and their current statuses.
Make sure exception notifier is on
Today's tip comes from a talk Dave Christianen gave last night at a local Ruby group meetup. When testing a Ruby on Rails application (or really almost any time), make sure you have Exception Notifier turned on. If you test Rails apps, and haven't seen Exception Notifier, check it out.
Browser testing – views, stats, and tips
Today's tip comes from Chris Wallace. In his post on The last browser testing advice you'll ever need he talks about his coding and testing process, lays out the a-grade list of browsers (from the Yahoo! UI Library), and if you take the time to read the comments you'll see several tips from readers of the site (including this link to the multiple IE installer).
Worth the time, read it if you can.
