Site24×7
I started using Site24x7 a couple of weeks ago, and this morning I purchased an annual subscription (for about $15). Site24x7 offers easy and fast (and it really is easy and fast) web monitoring services. I'm using them to get alerted when a couple of web apps I'm hosting go down. They send email and text messages. They also provide very nice up-time reports (ad hoc and emailed weekly). I'm sure there are free services/tools out there for this, but this was soooo... easy. I had it up and monitoring in less than three minutes. And the alerts have been timely and effective.
If you have a small buisness montioring need, they might be worth checking out. The price is right, and they offer a wide range of monitoring services. And I just noticed they have a web version for the iPhone. I'm going to have to check it out.
Quick tests for landing pages
Mary Flaherty wrote an article recently titled Are Your Landing Pages Driving Clients Away? In the article, she provides some great tips, that I think also make great test ideas. Here's a quick summary:
- Does the landing page have a clear call to action? In her words, "Where's the doorbell?" Test ideas around this might include asking users if they know what they're suppose to do next once they hit the landing page. Or watching where they go and seeing if there's convergence or not.
- Does the landing page present all the options in a manageable way? That is, can you quickly see what the options are, and find what you might need? In her words, "Which door is which?" Test ideas around this might include asking users to find specific information and seeing how long it takes for them to find it from landing - again looking for convergence. I might also ask users to write down what they think the site contains without navigating past the landing, and time how long it takes them to do it.
- If you collect visitor information, only ask for what's absolutely necessary. Test ideas include looking at the business process being served by collecting the information and evaluating how it would change if something wasn't collected. Is that ok? Less might be more at this early stage...
- How is information laid out and what's the quality of the copy editing. She identifies this as the risk of "TMI." Test ideas include making sure the site has copy guidelines (and they are followed), ensuring the writing is appropriate for the audience (jargon, concepts, structure, etc...), and making sure the layout is visually appealing. Mary also talks about dumping unneeded animations, choosing relevant images, and keeping information up to date and relavent. All of these are possible tests and/or heuristics for possible problems with the site.
Check out the full article for more ideas.
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.
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.
Try XSS to break out of a rut
I'm again stealing a tip from David Christiansen (he's on a roll lately). Checkout his post on using cross-site scripting to get out of a testing rut. From the post:
<script>alert("f")</script>Paste it in every field.
If an alert pops up OR the field gets saved and then gets rendered without the script tags, you’ve found a cross-site scripting vulnerability.
As a side note, in a very funny turn of events, when I originally wrote this blog post I was rewarded with the following...
Drop the ’s’ from HTTPS
Many websites have the requirement that transactions be SSL encrypted. When this is the case, you see HTTPS instead of HTTP in the address bar, and down at the bottom of your browser, you likely see a little padlock icon that you can click to pull up information on the security certificate being used. However, for whatever reason, sometimes websites choose to implement both secure and non-secure versions of their site. Other times, the web server can be misconfigured allowing HTTP transport when it should all be HTTPS.
A quick test you can do to see if both are available is to just try dropping the 's' from HTTPS in your address bar. For an example, check out https://www.getafreelancer.com/ - the site works under both HTTP and HTTPS. (I assume that's by design, but I'm using it as an example because there aren't many sites that support HTTPS and also support HTTP at the same time.) If you can access both HTTP and HTTPS, you might want to double check your security requirements for the site and/or your web server configurations. Also, some sites have portions of the site that are HTTP while others are HTTPS. In those cases you might want to come up with some listings of what should be only HTTPS and just check those areas of the site.
Small Screen Rendering XPI
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.
Reading effectiveness tool
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.
Testing web services
When I'm working on projects where we're testing web services, it often means comparing XML files to determine if our tests passed or failed. I've found that working with that much XML means you're going to have to get good at:
- writing XSLTs to transform your actual response to mask out values you don't care about (server dates for example);
- writing Xpath queries to check for specific values in an XML document;
- learning all the command line options on your favorite diff-tool;
- and ensuring you have at least one person on the team that knows the schema inside and out and can see the entire mapping document in their head when they look at the response files.
