Found an interesting post on a tool for testing small screen rendering in FireFox. The tool is Small Screen Rendering XPI by Disruptive Innovations. It's an extension to the Mozilla Application Suite which allows you to check if a web site renders well on mobile devices.

Many times, when testing websites, we forget about the static content of the site. Here is a simple tool that applies some simple heuristics to help gauge the effectiveness of the content on your site. Even if you don't end up using it, as you read through it you can get some ideas for how to make content more accessible.

I do a lot of web testing, so it's easy for me to remember to test in multiple browsers. I know each browser renders content in it's own way. I also often remember to test using different screen sizes, because I know sometimes content gets truncated or smashed together on lower resolutions. However, sometimes you might even want to try testing with different displays. Sometimes you'll notice contrast differences between brands or types (CRT, LCD) of monitors, or even devices (think mobile applications). Depending on what you're testing, this distinction might be important. For example, if your developing the UI for an ATM system, knowing how you render on CRT machines vs. LCD machines might really be important.

While I wouldn't normally consider this a "quick testing tip," on some teams testers also help with initial defect investigation to help identify root cause. If that's the case, and you're one of the testers who works with a production support team to isolate and more clearly define (and fix) production bugs, then this tip is for you.

Before you pull a bug off the top of the stack for investigation, do a quick search to make sure there aren't similar issues in the backlog that should be investigated at the same time. I've found that if you're looking for three similar issues when trying to recreate a similar set of problems, that you can make headway (on some of them) faster than others. It's also possible that simply by looking at how the bugs are clustering, you might gain better insight into what you'll need to do to recreate or isolate them.

After a grueling round of reviewing some long architecture documents for a new project, I've noticed that I have some required tools and habits I've developed for a first review:

• Different colored pens and highlighters (where different colors indicate different things like follow-up, possible issue, quality criteria, testing feature, etc...)


• Post-It tabs are a requirement for any document over 20 pages (where different colors again indicate different things to follow up on)


• A fresh notebook for the project for notes, ad-hoc drawings, and questions


• Google - to research abbreviations, terms, and technologies I don't know


• A photocopier for diagrams that I want to have handy (but don't want to remove from the document without replacing with a copy)

Once completed with an initial review, I'll try to follow up on some of the research tasks (learning new tools, technologies, etc...) right away while it's fresh in my head. Then I'll draft emails full of questions off to various people in the project - sometimes sharing some of my sketches to make sure I understood things correctly.