Just when you thought it was safe to go near a computer again, there is another project phase. You have a working website, but you are not an author yet. First the site must be thoroughly tested. You have been doing this all along right? Early feedback from the end user is the best way to prevent design and implementation flaws. However, now that you have a complete project, it's time to go back to the public for review.
Testing or seeking review can mean several different things — showing the site to one person or to a group of colleagues, sending it out for informal review, or setting up a structured, formal test. It's important that you test; you can go about it any way that works for you.
This section outlines a few simple techniques to keep in mind when designing and carrying out your project testing.
Don't explain to the tester the things you're trying to test. If you want to find out whether users can navigate through your site easily, don't give them verbal instructions beforehand for navigation. Use participants who are similar to the people who will be using your site.
By watching and listening to your tester and reviewers carefully, you can not only uncover mistakes, you'll also probably discover that your tester will offer good ideas that you can add to the site as you refine it.
Listen to what people tell you. If they say the site is confusing, don't argue, say, "Thank you. What in particular is confusing?" The point is to find out how others perceive the site, not to defend your ideas. It's tempting to get defensive and just assume the testers are being dense, but if you've chosen them wisely, they will be representative of the users you designed the site for.
Watch what people do when they try to use your website. See what pitfalls people find, and what solutions they try, without offering your comments. If several users try the same solution, consider providing that capability in your site. If several users misunderstand an aspect of your site, redesign it.
Be sure to test your site using different platforms (Mac's, PC's, mobile phones and tablets) and different browsers. Try changing the resolution of your monitor as well, or view the site from a tablet or mobile phone. Take note of how the site looks and make sure it is still usable. (See the notes about Responsive Design, if you're interested on how to fix some problems that come from fixed layouts.
The advice in this page was written in early 2000 (with small updates), and at that time testing was done by observing users. Nowadays, students create a Google Form and send it to as many people as possible to get feedback. While this allows for gathering plenty of feedback, it is not a substitute for the "real observation" of someone using your website. Thus, either during the lab session or in some other College setting, try to get a small number of users to do a live testing of your website, while you are present to observe them. This will give you invaluable insight on how people are navigating and interacting with your website.
Write an HTML document with the following structure and information:
Name your document P4_testing.html
and upload it on your Documents
folder, with the other project documents. Make sure to submit it by the deadline.
You don't have to actually change your site. Many of you will decide to do so, either because your client wants it, or out of a sense of personal responsibility, which is admirable. However, your CS110 advisor won't be grading the revised website, so you can do this whenever you have time and energy.
The lateness policy is that you may turn it in up to 24 hours late, with a 10% penalty.
Your document P4_testing.html
should include all components described above.
Points will be awarded for:
Points will be deducted for:
Here is an example of a P4_testing document from the project Nan Nan Art Studio, which is featured in our Hall of Fame.