 |
|
 |
|
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.
|
|
| |
|
|
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.
|
| |
 |
|
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!]
|
|
| |
 |
|
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.
|
|
| |
 |
|
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.
|
| |
 |
|
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.
|
| |
|
|
|
|
