Just when you thought it was safe to go near a computer again, there is another project phase. You have a working web site, 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.
Testing Guidelines
This section outlines a few simple guidelines to keep in mind when designing and carrying out your program tests.
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 web site. 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 (PC's or Macs) and different browsers and browser versions. Try changing the resolution of your monitor as well. Take note of how the site looks and make sure it is still usable.
What to Turn in
Write a short document describing your test plan, including a list of testers. Make sure to include details such as whether you used a questionnaire and what was on it, what type of computers and browsers were used in the testing, and so forth. Summarize the testers' comments, criticisms, testimonials, and so forth. Summarize your response to the testers' feedback. Which comments led to design or implementation changes? Which did not? Explain why you chose to heed or ignore specific comments.
The document will, like all documents in this class, be a web page uploaded to your teams' public_html folder. Name it P4_testing.html.
You may wish to use the enclosed sample testing form, or if you prefer, you can utilize one of the team member's results of homework 9. Feel free to use your imagination, but test thoroughly in order to gain insight into the changes that are needed for the final web site.
Be sure to include your client as one of your testers. Choose a variety of people from the audience you have targeted to use your site as well as other CS110 classmates, roommates, and friends.
You can reference the testing document feedback form that we will be using for grading if interested.
Sample Testing documents
As before, don't take these examples as gospel, but they may be helpful to you.
What you don't have to do
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 web site, so you can do this whenever you have time and energy.
Introduction |
Syllabus |
Assignments |
Documentation |
Project
Computer Science 110
Date Created: June 30, 1998
Last Modified: January 2007