Do you know anyone who enjoys quality assurance (QA)… besides QA people? Unfortunately, it is undervalued in the design and development process.
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.
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.
Yay! You've decided to leave a comment. That's fantastic! Please keep in mind that comments are moderated and
rel="nofollow" is in use. So, please do not use a spammy keyword or a domain as your name, or it will be deleted. Let's have a personal and meaningful conversation instead. Thanks for dropping by!