Project   Testing Phase


Testing Guidelines

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.

How to Test

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.

Note

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.

What to submit

Write an HTML document with the following structure and information:

  1. Header: A title, the author names, and date.
  2. Administrative Details: The name of your client, and his or her position in the organization (or company), if applicable.
  3. Testing Document: A brief summary of the questionnaire you send out to testers, as well as the link to the Google Form you used. Don't forget to ask your client to test the website.
  4. Tester Audience: A description of your efforts to reach testers that are similar to the website's intended audience and how successful you were (give the percentages of your tester audience once you aggregate their answers, e.g., 23% college students, 46% school administrators, etc.) If you are collecting age-ranges you can do the same. If you were able to do live testing with a few users, describe that as well.
  5. Testing Platforms: A summary of the different platforms (devices and browsers) that your testers used.
  6. Feedback Summary: A summary of the feedback you received organized by question type (design, navigation, content, usability, etc.). Hightlight both positive comments and thoughtful criticism, your client's testimonal, etc.
  7. Your Response: Provide your response to the feedback. Concretelly, describe what you could do (once the class is over) to address this feedback with changes in your design or implementation. You can also address why some of the raised issues or suggestions for improvements are difficult or impossible to tackle.
  8. Self-reflection: Step back and reflect on the whole project experience and what you learned from it. Are there general lessons that you learned, beyond the nuts-and-bolts of HTML, CSS and JavaScript. We would like you to take this seriously and be thoughtful about your comments, but there is no right or wrong answer here, so don't feel that you have to flatter us or try to divine what we want to hear.

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.

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 website, so you can do this whenever you have time and energy.

Late Policy

The lateness policy is that you may turn it in up to 24 hours late, with a 10% penalty.

Grading

Your document P4_testing.htmlshould include all components described above. Points will be awarded for:

  • Efforts to find testers from the intended audience or to do live testing.
  • Use of a variety of devices and browser platforms.
  • Concise and well-structured summary of the received feedback.
  • Thoughtful and detailed response to the received feedback.

Points will be deducted for:

  • Missing self-reflection section.
  • Poor writing and lack of document structure.
  • Invalid HTML and CSS code. (Use the validation icons and check their results)

Example

Here is an example of a P4_testing document from the project Nan Nan Art Studio, which is featured in our Hall of Fame.