The Lost Files – The Ultimate Web Design Questionnaire And Checklist (part 7 of 8)

• By The Smashing Editorial
• October 12th, 2011
• The Lost Files
• 0 Comments

← Build (6/8)TOCLaunch (8/8) →

Stage 7: Bug Test, User Test… Just Plain Test

Do you know anyone who enjoys quality assurance (QA)… besides QA people? Unfortunately, it is undervalued in the design and development process.

Bug Testing

Have you budgeted time for testing and fixing bugs? You’ll never get it 100% the first time. Nothing’s worse than developing right up to a deadline, launching in a rush and then seeing the website crumble immediately. Get people to test features as they are completed, and spend at least a few hours at the end making sure everything looks right and works right in every browser.

Is the client involved in testing? We often cringe when clients get involved in testing. They think of changes and new features and don’t understand that the time for that has passed.

They also don’t understand how to record bugs in a way that’s understandable. Have you ever received a bug report like, “When I click on the ‘Submit’ button, it takes me to the wrong place”? Which “Submit” button? Where does it take you? What did you want it to do? What browser are you using? What were you doing before this happened? Run through all of the details you would need in a bug report, and set up a bug-tracking system that makes it easy for them.

They’re getting impatient to launch, but they need to understand that testing leads to less user frustration. Spend a few minutes identifying specific things that you want them to test (in multiple browsers, of course); this will keep them busy.

Has a third party tested the design? Because you designed it and it makes sense to you, you know the user flow perfectly and would not stray from the path. So, if you’re on a small team, swap roles with someone briefly so that you can test the areas you worked on the least.

Have you tested what happens in every scenario? What if I click something and then hit “Back”? What if I click buttons in a random order? You’re an advanced user, but the real users won’t be, so go wild. You don’t need sophisticated test cases for small projects, but you might for bigger ones.

Are you testing browsers in proportion to the user base? You have already agreed on which browsers to support. Designers and developers mostly use new browsers and work hard to make their websites look as beautiful as possible in them. But if 70% of your users use older browsers, then you should spend 70% of your cross-browser testing time in those browsers. Graceful degradation and progressive enhancement are fine, as long as the client has agreed to them.

Quality Assurance Checklist

• Check your spec sheet against the current state of the website. Are the right browsers targeted? Is the target audience represented? Does the layout work at the maximum stipulated font size?
• Try to break the page. Have you covered every possible path that the user could take? Have you tested user paths in all supported browsers?
• Have you checked the quality of your JavaScript syntax against tools such as JSLint?
• Is the website usable without JavaScript or CSS?
• If you’re using tools to track testing, have you explained to all testers how to record an issue?
• Is everyone clear about the difference between what’s required for launch and what is “nice to have”?
• If it will be a big website with a lot of traffic, have you conducted some load tests?

User Testing

Conducting traditional user testing for small websites is usually not cost-effective. For bigger websites, it’s a great way to see whether users do what you expect them to do, before you modify the design. You will be able to test different phrasings, button positions, user paths and more.Even if you don’t have the resources for formal user testing, at least install analytics and some basic tracking on the website. There’s also software that allows you to do simple A/B testing on a live website easily. Don’t use too many, though: the scripts usually slow down websites. When the website is up, conduct a few informal user testing sessions to get solid feedback on the new website. Hearing a live person explain what they like or dislike about the website is much more valuable than trying to glean it from a bounce rate.

Do:

• Set up a bug-tracking system
• Test before launching
• Get others to test the design
• Leave enough time to fix big problems
• Test browsers in proportion to their usage rates
• Get the client involved in testing
• Include print and mobile style sheets
• Install some sort of tracking software
• Avoid installing 10 different tracking programs
• Optimize images and pages for fast loading

Testing Checklist

• Have you chosen which pages to test?
• Have you prepared a list of things you need feedback on?
• Have you chosen a method for capturing data (for example, eye movement, mouse movement, voice recording, etc.)?

• Have you set parameters for the decisions you make based on the data?
• Does the user have enough legitimate data on the test website to work with?
• If you’re updating a website, have you decided whether to test former users, new users or both? Do you have different tasks for each group?
• After testing and making changes, have you retested?

← Build (6/8)TOCLaunch (8/8) →