August 2009 Archives

We could use help testing AMO 5.0.9; if you want a lightweight way of helping out, please run any of the tests in our Litmus repository.

If you know enough to file a bug, please do; otherwise, just leave a comment when/if you mark something as failed or unclear.

Additionally, come find the Mozilla Web QA test team on IRC, at #mozwebqa on


- Stephen

In my last blog post, I covered only a few of the page elements at the top of the Mozilla Creative Collective site; here, I'll finish up that page.

Header navigation:

* Does it use JavaScript to replace the image on hover, or CSS?
** If JavaScript, try disabling it, and see what happens
* Ensure that links go to their intended destinations

Post Your Design:

* Does it have a hover effect? If so, see above
* Make sure the post-design page honors logged in status (and encourages you to log in, otherwise)

Latest Design Challenge:
* We should consider whether this is programmed content (and if so, we should test the admin interface to verify we can change it) or whether this is a time-based module (runs a certain promo based on dates)
* What are the expected ALT/TITLE attributes on the tags?

Rotating content block:
* Verify that clicking on each section below the image replaces the content
* Verify that long content is either ellipsized (...) or discouraged from the admin interface
* What are the expected ALT/TITLE attributes on the tags?

Hot Designs:
* This could run off an algorithm (and if so, we should test that when we manipulate the test data, the algorithm adjusts accordingly) or it could be programmable content
** How many likes/favorites does it take for a design to be "hot"?
** Is this block cached in any way? On a cron job? Immediate?
* What are the expected ALT/TITLE attributes on the tags?

Designers you Like:
* Verify that only favorited designers are displayed
** Try favoriting one and come back; does it appear?
** Similarly, un-favorite one and return; does it disappear?
* What are the expected ALT/TITLE attributes on the tags?

Staff News:
* RSS feed displays staff in the same order as they appear on the homepage
* Author name links to their blog/page
* Title links directly to their post
** Try long titles -- do they wrap?

* Copyright date
* Logo links to homepage/page top
* Links work and take you to their intended destination

Of course, the above list isn't comprehensive, but it's a good start; feel free to add comments to the blog entries for anything I've missed or gotten wrong.

Also, if you're interested in helping the Mozilla Web QA team test, please check out out Volunteer page.


I've often wanted to write a blog post or a wiki page explaining the process by which I look at a site (or in this case, a single-page mockup), and start to break down the functionality/elements that I'll be testing.

Let's look at the Creative Collective example, below:

First things first: the first thing I notice is that the site stores and recognizes usernames (or email addresses, depending on how it authenticates its users). I'd immediately expect that the "Join Us" link leads us to an account creation/registration page, wherein users fill in a combination of their real name, username, and/or email address. (Other fields like a short bio, etc. might exist too.)

On an account-creation page, the usual test candidates are:

* username/password length
** Does it accept more than the stated length limitation?
** How about something like 250 characters?
** How about "special characters", such as ":/?#[]@!$&'()*+,;=.<>"?
** Does it accept empty or only-space-character usernames?
* unique username (try to register two that are identical)
* empty password

Of course, those are just the individual fields; we also need to ensure that users enter all the required information upfront, and if they don't, that we don't lose what they'd typed, and even more than helpfully pointing a user to the field with the problem, we should tell them how they can correct it and move on.

And, that's just registration -- we want to be equally helpful to the user on login: which fields are required, what their minimum lengths are, etc. To test, I would:

* try valid username or email address (whichever the site uses) but invalid password
* try valid username/email address without a password
* try invalid username/email address but valid password (etc.)
* test the forgotten-password feature

Login and account-creation pages also should be served through HTTPS, so ensure that the links start and stay on https:// -- we don't want to send users' data "over the wire" in plain text -- that could potentially be read by others. Additionally, we should test that the fields properly escape data (encode it so that invalid/evil input is made safe); we should also test for XSS (cheat sheet here).

After testing this, I'd move on to search functionality. In the mockup above, we have "Search for" (images) * [search textfield]. Let's break it down: we know from "images" that one datatype will be images, but not how our search terms might match that category; because it's a selector, we can also assume there will be other datatypes -- maybe one for "text", and/or "images and text". For text, are we searching on perhaps tags, titles, or authors (each of which could be in the selector)? And whenever we think of search, there are a bunch of use-cases to consider:

* when you click on the pre-filled "search" text, does it disappear, to be replaced by your entered text?
* what should the empty (i.e. default) search experience be? (Should the user be able to search without entering something? Typically, yes.)
* what about substrings? e.g. "paint" in "painting" -- would it match "painting"?
* do misspelled words trigger a helpful "did you mean?" suggestion (a la Google)
* when you change the "Search for" pulldown, does the textfield clear?
* do your criteria get reset when reloading the page?
* try pasting something huge like the text of the U.S. Constitution -- does the server have to process it in its entirety, and take forever? Does it balk? Throw up an error page, with, perhaps, any internal server-config values/messages? Are there layout issues on the search-results page from such huge a string?
* again, also try XSS here
* try, of course, regular searches :-)

So far, I've really only touched on four components of this site--nay, this page--so you can quickly see how complex (and fun) website testing is.

I'll come back to finish this page towards the end of this week or early next week, so stay tuned!

Feedback/questions welcome at

As always, Mozilla's Web QA team can be found at

About this Archive

This page is an archive of entries from August 2009 listed from newest to oldest.

July 2009 is the previous archive.

September 2009 is the next archive.

Find recent content on the main index or look in the archives to find all content.


Powered by Movable Type 5.12