Testing a complex website or web-based application can become especially tedious when you don’t have a good sense of when you’re “done”. After working on several projects where I’ve either handled User Acceptance Testing personally or outsourced to a temp, I’ve come up with a baseline boilerplate QA checklist.
If you’re a web designer or project manager, it might provide a nice starting point for QA. If you’re non-tech person looking to evaluate a website, it’s a nice way to make sure all of the bases are covered.
Step 1: New Functionality
Review any specs, work orders, mockups, etc.
- Does the site/application perform the tasks as expected?
- Are emails sent or confirmation/error messages displayed as expected?
- Are records saved and calculations performed correctly?
Step 2: Design/User Interface
- Are dates and times formatted correctly? (Programmers have a tendency to leave unfriendly system-generated dates and times in
- No remaining greeking or “Insert text here” messages
- Is all functional text logically written? (Intro text, field labels, helper text, error messages)
- Are images sized correctly?
- Are images compressed appropriately? Nothing looks too grainy?
- Are all copyrights, trademarks, etc., displayed correctly?
- Do site colors match any style requirements?
- Are hyperlinks underlined or otherwise marked?
- Are titles displayed prominently?
- Is all body text legible?
- Are all page elements aligned correctly?
- Are widths and heights set correctly?
- Cross-browser testing. I usually make sure all pages look good in these browsers:
- Windows Internet Explorer 5, 5.5, 6, and now 7
- Windows and Mac Firefox
- Mac Safari
- Opera (sometimes)
- AOL’s Browser (sometimes)
Step 3: Functionality
- Check every link from every page (there are some free automated solutions for small websites)
- Does the HTML/CSS validate?
- Do all filters and table sorting options work correctly?
- Does the application function appropriately for different user states (logged-out, member, etc.)?
- Does the application handle invalid form input appropriately?
Step 4: Goldilocks
And finally, the grandaddy of of gotchas:
Zero, one, many
The basic idea is to fill every dynamic content block or form field with zero, one, or many items and make sure the system works well with all three
situations. Try too little, too much, and none at all. Oftentimes, we design an interface expecting just the right amount of content or data –
this is the time to look for all those weird edge cases.
That’s it! Let me know if you think of anything I could add to this list.