In his talk on screen recording APIs, Jason Horn mentioned he's an avid fan of Sauce Labs and their hosted Selenium solutions. There are a host of features and pricing starts from free (Linux and FireFox, limited to 500 min/month) and goes up to monthly and enterprise pricing. You can try some of the premium services with a free trial if you want to check it out. While I haven't personally used the product, I really like the idea and I'll have to check them out on an upcoming project.
For those of you who do web testing, Support Details is a handy little utility for when you report issues. It automatically pulls down information related to the browser you're using, and it allows you to either download that info (csv, pdf) or email it to someone who can look into the issue. Since I have several computers and each has a couple of browsers (all constantly doing their own automatic updates) this is really nice for when I submit something that I suspect might be browser specific.
In the good old days of the Web 1.0 world, when something didn't go well you'd get the basic 404. On a fancy site, that 404 would perhaps be branded. In today's Web 2.0 world, 404 pages are often smart. They try to figure out what you were doing and suggest places where you might go next. It's a cool feature, and a great way to take what might have been a poor user experience and turn it into something positive.
However, it doesn't always work the way we intended. When sites suggest things to you, they can make mistakes. Therefore, I have a heuristic that I follow which says always go where the software suggests I go. Here's an example...
Last week while playing around with the new mint data website, I was greeted with the "City not found" page several times.
A feature of this page is that it suggests a page for your to visit next. Often, it's a state. However at point point I was able to get the site to suggest I view spending for the entire USA. Using my heuristic, I followed the link and was greeted with an excellent java exception.
Rewarded with this exception, I was able to determine that the site is written using Java (sprint and hibernate), runs on Apache (and the version of Apache). I also have suspicion of what to do next. After seeing this issue I started trying custom URLs and was able to get several different exceptions. Some of which gave me additional insight into the site structure and possible test ideas.
Total Validator provides the following main features:
- A parser that validates the basic construction of your pages
- True HTML validation against the W3C Markup Specifications or ISO/IEC definition using the published DTDs and standards: (2.0, 3.2, 4.0, 4.01, 5, ISO/IEC, XHTML 1.0, 1.1 and 5, XHTML Basic 1.0, 1.1, (X)HTML+RDFa, XHTML-Print)
- An accessibility validator that validates against the W3C Web Accessibility Guidelines (1.0 and 2.0) and US Section 508 Standard
- A broken links validator that checks each page for broken links
- A spelling validator that spell checks the content of your pages (English, French, Italian, Spanish, German)
- Snapshots (screenshots) of your pages in different browsers, on different platforms, at different resolutions
- A desktop tool so you can validate pages before you publish, and pages behind firewalls
Here are results generated after our home page validation.
What is unusual - none of those browsers was actually installed on test machine.
This is a free service by Spoon: you can invoke multiple copies of different versions of different browsers without having them on your machine.
What's currently provided
- Microsoft Internet Explorer (versions 6, 7, 8, 9 Preview)
- Mozilla Firefox (versions 2, 3, 3.5, 3.6, 4 Beta)
- Google Chrome (versions 5, 6 Beta)
- Apple Safari (versions 3, 4, 5)
- Opera (versions 9, 10)
Found a cool tool today called Website Grader. Website Grader by HubSpot is an SEO tool that helps you diagnose how well your website doing in terms of SEO, social media, and traffic.
Some interesting notes from the analysis report:
- The blog scored low due to a low volume of incoming traffic (links, tweets, etc...).
- The readability level is "Primary / Elementary School". That's exactly where we want it.
- We are missing metadata. (I should probably add that...)
- Interior pages are missing descriptions as well. (Who the heck is the admin for this site? Oh wait....)
- I learned something really interesting about domain expiration. (I had no idea.)
All said and done, a very helpful little tool. I ended up running a couple other websites I have as well. Needless to say, the feedback was consistent. I make all the same mistakes with each site. Guess I need to renew some domains and update some metadata this weekend.
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.
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.
Stoyan Stefanov recently posted a fantastic set of slides on pitching better website performance. The slides look at different websites and how performance affected the core business. It's a cool idea. I think material like this is useful for a variety of reasons, but most of all because it provides insights into how I can better transform my technical work into something that talks about business value. Each slide is a mini case study on looking at a company and translating performance into a business driver important to them. As testers, we need to be good at that. The more exposure we get to materials like this, the easier it becomes to recognize similar opportunities in our own organizations.
- Avoid using abbreviation
- Make headlines and opening sentences "scanable" by making them your most informative content
- Make paragraphs smaller
- Check the reading level of the content
- Use active voice
In the article he provides some good links to related content.