Accessibility
 
Home / Resources / Techniques
Icon or Spacer Macromedia Website Production Management Techniques Phase 5: Build and Test
Testing

Now that you've built your site, whether static or dynamic, it's important to make sure it works.

Testing your site means conducting Quality Assurance, or QA. Oftentimes there is little time between building and launch to conduct any QA testing. More and more companies engage in actual formal testing with a trained QA staff or testing facility.

During the building process, the team has been testing the site against browsers and platforms to ensure the HTML code is working and not breaking or displaying incorrectly. This is a great start, but should not substitute for actual QA testing, even at a very informal level.

If you are developing a government or educational site, it is legally required to be accessible to users with disabilities by June 21, 2001, and ideally you will have a percentage of your overall budget allocated for formal QA testing.

Web Accessibility Standards

New standards are in place to ensure that individuals with physical or technical handicaps can access the Web.

For government and educational sites accessibility it is not only an important issue, it is a new standard they must comply with. Section 508 of the 1998 Rehabilitation Act requires all government systems to be accessible to users with disabilities by June 21, 2001. Web sites should comply with the W3C accessibility guidelines too.

 

 

Macromedia Dreamweaver and Dreamweaver UltraDev Accessibility

There is an outstanding free Accessibility extension for Dreamweaver and UltraDev available on the Macromedia Exchange for Dreamweaver.

It is the 508 Accessibility Suite Extension from UsableNet, an automated tool that tests your Dreamweaver site for compliance with the accessibility requirements of section 508 and W3C, and it includes detailed information about how and why to change your code to improve its accessibility.

The other is the Macromedia Dreamweaver Check Page for Accessibility extension, which alerts developers to accessibility problems and their location in source code, and refers them to relevant W3C guidelines.

 
Macromedia Flash Accessibility

Macromedia Flash is everywhere. With a 96% penetration rate for the latest plug-in, most browsers are ready to view vector-based animations on the Web.

Macromedia Flash technology enables the creation of rich user interfaces, animation, sound and graphics in a small file size, but it does pose challenges to professional Web teams. Some Macromedia Flash sites are not properly designed to take full advantage of the low-bandwidth capabilities of Macromedia Flash, and thus can become quite heavy and require high bandwidth. Visually impaired users cannot currently read the content or text of Macromedia Flash movies with text-to-speech translators or non-graphics-enabled browsers, a fact that requires appropriate alternatives. One final issue is that without careful design, it is not possible to create bookmarks inside Macromedia Flash movies.

Solutions?
1) Provide an HTML alternative site, for lower bandwidth and text readers.
2) Provide ALT text alternatives for smaller animation pieces & graphic text.
3) Visit the Macromedia Flash Accessibility site —a valuable resource offering helpful guidelines, free example code and extensions to make your Macromedia Flash site accessible to users with disabilities.
4) Check out the Flash Accessibility Extensions available through the Macromedia Exchange for Flash.

 

 
Readdressing QA Test Plan

At the beginning of the project, a QA plan was addressed—at least as something that was planned and budgeted for. Sometimes it is as simple as having a line item in the plan that reads: Quality Assurance = 20 hours. Readdress the assumptions made in the plan, including what browsers you will be testing and what kind of connection speed and screen resolution you designed for. Determine what online tools you will be using.

Conducting QA should involve at the very least two complete run-throughs of the site, first to catch bugs and create a list on multiple browsers and platforms, and second to fix and test one final time before launch. Your plan will vary according to time, budget and the expectations set forth at the beginning of the project.

HTML Validation Resources

Here are some online resources to help with HTML validation—to check for broken links, bad data and other errors which are difficult to catch through traditional QA methods. Some are free, others are available for a small fee.

UsableNet—Web Site Testing Systems
NetMechanic—Web Power Tools
Scrub The Web—make your site search-engine friendly
HTML Tidy—clean up your Web pages

 
Conducting QA Testing

Formal testing consists of hiring an outside company or a very experienced internal team to conduct testing on your site. It will include a formal plan, a test bed (rows of computers according to client specifications), several regression tests and a final acceptance run-through using a very formal tracking system to confirm that the proposed product meets the requirements as originally specified in the Define Phase of the project.

Informal testing is conducted with a small team (usually you, the client and the production coders) checking the site as thoroughly as possible in the days and hours before launch for broken links, spelling errors, cross-browser and cross-platform issues and more.

Most sites fall slightly between these two extremes, depending on the formality of the process and the specific requirements outlined when starting the project.

A semiformal QA Core Plan might look something like this:

· Summary of overall goals for QA—methodology, timing and resources
· List of specific browsers, platforms and operating systems being tested
· List of desired connection speeds being tested
· List of any specific paths or functions that need to be tested
· A plan for bug tracking, whether a Web based program or a spreadsheet
· A plan for confirming that fixes have been made prior to launch
· Any stated assumptions and known risks to protect the team if all fixes cannot be caught prior to launch. This should be part of the contract or signed off prior to the final site being delivered or launched.
· A plan for fixing any "showstoppers" (items that have to be fixed before a site can go live) as well as bugs that cannot be resolved prior to launch. Decide who is to handle these, how any additional costs will be identified, and so on.
 
Be sure to check the logs for errors after testing the primary functional paths and running a link analysis tool (see HTML Validation Resources above). Oftentimes something that doesn't appear to break on the front end can still generate a great number of errors in the logs.
 

QA and Servers

Prior to a site going live, the production team should test once on the staging/development server, and then again when the site is moved over to the server environment where it will eventually be live. When the site is moved over, the testing environment needs to be exactly the same as the live environment. This means that the folders, file structure and server-side scripting are correctly in place, or many of the scripts and CGI elements may not work properly. [Good luck!]

 
Tracking/Fixing Bugs

Finding a bug is easy. Reporting and recreating the bug is a little trickier.

There are many methods of bug reporting (from printing the page out and circling the problem to using a full-blown bug tracking system). There are also online bug tracking resources, which are usually Web-based programs that will allow a user to track and monitor bugs online during the QA process. A good standby is a spreadsheet, which works well if one person is monitoring and updating the document, but isn't as useful for multiple teams conducting QA tests remotely.

Once you track the bugs, you will need to prioritize and determine what can be easily fixed before launch, which are showstoppers, and what can be put on a list to fix after launch.

Be prepared for schedule slips if you have a tight or inadequate testing schedule and testing uncovers any showstoppers. Allowing enough time for testing will mitigate the occurrence of schedule slips.

 

Bug Tracking Resources

Set up a system to track bugs (even if it's a very basic one, like Bugzilla—free off the Web) this will ensure that no issues fall off the map and all problems are resolved or at least documented by launch. Here are some online tools and resources for tracking bugs:

All about GNATS, the GNU bug tracking system
JitterBug—a Web-based bug tracking system
Mozilla.org—bug info and Bugzilla bug-tracking database

 
Outsourcing QA

Your team should conduct internal testing and confirm that all systems are functioning on primary OS/browser targets (e.g. Win98/IE4.01 and 5.x).

For extended testing, a good option is to outsource to a company that already has a comprehensive test bed (set of computers, browsers, platforms and varying connection speeds) and testing resources, including a trained QA staff. You can save costs with outsourced testing by providing the firm with your own test plans/test cases and paying only for the testing itself. As in all contractual situations, make sure you are paying for what you need—not just a duplication of services. Make sure a signed contract is in place.

 
Testing Usability

An optional step at the end of the production process, as you are going through QA, is to test your site for verification of usability prior to launch. This is often valuable for catching areas that can be quickly improved before going live, as well as confirming that the user is able to navigate through the site.

Even testing informally with local test subjects (they can be friends or coworkers) will enable you to confirm that the site will work in an actual-use environment. Some companies find it extremely valuable to conduct formal testing at this stage, as it is too risky to launch a faulty site and lose potential customers.

 
Summary

The build phase is one of the most complex, drawing from various levels of expertise and execution.

If you have built HTML pages, you have a completed site ready to be launched. If you are building a dynamic site, you have been working with your back-end development team to hand off templates and integrate content and functionality with the front end, and you are ready to launch.

Whether large or small, you have completed the bulk of the project. Congratulations! Now it is ready to prepare for launch… and beyond.

 
 Discover
Overview
Analyzing Your Industry
Understanding Your Audience
 Define
Overview
Goals and Objectives
Creating a Project Plan
Establishing Requirements
Housekeeping
 Structure
Overview
Content
Site View
Screen View
User View
Design and Prototype
 Build and Test
Overview
Pre-Production
Building
Testing
Launch
Evaluate and Maintain
Resources
Online Forums