Today's tip comes via Tim Koopmans. Tim recently posted on landing page load time and how tools like BrowserMob can help. Based on his post, I went over and took a look at BrowserMob and ran a couple of tests on my personal website. There were a couple of interesting things I found in the free tool they provide:

• They provide test results from four locations: Washington DC, Dublin, San Fransisco, and Dallas.


• They provide historical results across test runs:


• They provide a detailed breakdown of load times by object, by download site:

Based on these detailed results, I was even able to find out that I have a couple of 404's showing up in my current WordPress theme. I rather like the simple interface, and I find tools like this can be quite helpful when taking an initial look at a site's load time and where that time is going.

Eric Jacobson recently posted his excellent analysis of resumes he's been reviewing since his team is hiring. Here's a short snippet:

However, the candidate would have probably gotten an instant interview if they had included any of these:

• My approach to testing is as follows…


• See my software testing blog for my opinions on how to test.


• My favorite testing books and blogs are…


• I enjoy testing because…

I really like the first one. I suspect that for some, it's a challenge to write that in a short format (like what I think you'd see on a resume). But there's no reason you couldn't summarize something in a paragraph on a resume and provide more details in a cover letter (perhaps tailoring your approach a bit for the prospective hiring company).

Does your resume include any of those points? I agree with Eric, it should.

In today's web 2.0 world, interesting behavior happens when windows get small. I often notice odd issues when I have my laptop projecting, and if I'm watching a move and typing in a browser at the same time, forget about it.

Just look at the example of when I was writing this post. I love WordPress. I think it has one of the slickest and most intuitive user interfaces out there, and it doesn't even shrink well. As a general rule, when widgets overlap browsers get confused.

If you're testing a web app, whenever you get a screen of any sort of complexity, shrink it down or make it big and see what happens.

I was recently handed the "gift" of a very aggressive deadline. It happens, you don't set the date - it gets set for you. (Ironically, Johanna Rothman just wrote a short bit on that topic on her blog.)

When aggressive deadlines get set for you, if you're like most managers, you start to ask questions to see how realistic the dates are and you try figure out what exactly you can and can't get done in that time frame. When I do that, I ask my team to help. I often pull people in early, and ask them to start looking into what testing we need to do, what environments we'll need, what data, what... you get the idea.

An important question I ask before I start to pile on more work (because any time I ask a question, I'm likely asking for more work), is what they are currently working on. Sometimes I'm surprised by the answer. I have a fairly self-organizing team, and they juggle a lot between themselves without checking with me first. So by asking first, I can keep myself from becoming my own biggest problem.

Before adding more work, ask what people are working on. Then, if they have too much, work with them to prioritize what needs to be done first, and what can fall off their plate.

Following up on the performance pitch post, here are some tips for helping get your technology team talking in the language of your business team:

• Take the time to define both top-line and bottom-line application business metrics


• Work to prioritize that list of metrics to better understand what’s most important (creating tiers can help)


• Identify what processes and transactions will affect those key metrics

When the team finds a possible performance issue later on, they can then translate what might otherwise be a generic metric (we're X seconds slower on transaction Y) into something that has meaning to the business (given that we're X seconds slower on transaction Y, we expect abandonment to go up Z%).

Defining those metrics, prioritizing them, and tying those to transactions doesn't necessarily need to be complicated. For some applications it will be. But for most applications I've tested, I suspect we could have done this over a couple one-hour workshops using Excel. Don't make it harder than it needs to be.