Extra! Extra!

Extracting the Essentials of the Web

Archive for the 'Quality Assurance' Category

“QA-ing” Your Analytic and SEO Strategy

Saturday, October 11th, 2008 by Rob W

When developing a new website, most companies (or web development agencies if the project is not being done in-house) go through an exhaustive “Test Plan” or “QA Checklist” before the site is launched. This document tends to focus on checking for broken links, spell checking site copy, testing site features like search or online forms, verifying the presence of 301 redirects (on the old website), making sure the site is free of (CSS, JS, etc) errors, ensuring the navigation is consistent, checking cross browser compatibility and so on goes the list.

When of the areas that I believe that is most often overlooked when “QAing” a website before it is launched is verifying that the sites analytic and search engine strategies are in place.

  • Have you created a new profile and added your analytic code to the new site?
  • Have you setup goals and funnels based on Key Performance Indicators (KPIs) for your website? (If not, how will you be able to prove to your boss the redesign was worth all the time and money the company spent on it?)
  • Has analytic code been added to any 3rd party applications you are using? If not, are you at least tracking the traffic that is clicking over to your 3rd party applications/sites?
  • Have you submitted your XML site map (http://www.sitemapdoc.com/) to Google Webmaster Tools and Yahoo Site Explorer so search engines can more effectively index your website? Have you also submitted your website to free directories like dmoz.org (which Google has a relationship with)?
  • Have you thought through your meta-tag strategy? Search solutions that you use on your website and public search engines like Google evaluate meta tags when returning results and often use the page title tag and sometimes the description in the search engine results pages that your site visitors will need to understand.

So just because your QA team believes the website is free of errors and ready to be launched don’t forget to verify your analytic strategy has been addressed and you’ve taken the necessary steps to make it easy for search engines to find and understand your new website.

Why Section 508 Testing is Important

Thursday, January 3rd, 2008 by DJ Bragg

Section 508 testing is important as it is necessary that a solid interpretation and understanding of the accessibility requirements be utilized to its optimal performance. These requirements need to be the basis for technical solutions, provide the platform for assistive technologies and offer proficient knowledge of how disabled people successfully manage information technology.

Section 508 must be read and understood thoroughly before testing can begin. It’s necessary to evaluate the website completely. Using multiple tools serve to complete the evaluations. In order to comply in full accordance with Section 508 the tester must know the differences in tools.The tester must be familiar with web development techniques and HTML codes. This is so that all errors can be found and fixed manually. Using a minimum of two testing products is adequate but the use of additional testing tools can provide better results. The goal is not only to enable Section 508 compliance but also make sure that that web content standards are maintained at maximum capacity in a regular, expeditious manner.

When testing what to look for:
Web Content Accessibility Standard

  1. Is there a text equivalent (e.g., via “alt”, “longdesc”, or in element
    content) for every non-text element?
  2. For any multimedia presentations, are there equivalent alternatives
    and are they synchronized with the presentation?
  3. Are documents organized so they are readable without requiring an
    associated style sheet?
  4. Are redundant text links provided for each active region of a
    server-side image map?
  5. Are client-side image maps provided, instead of server-side image
    maps (except where the regions cannot be defined with an available
    geometric shape)?
  6. Are row and column headers identified for data tables?
  7. Is markup used to associate data cells and header cells for data
    tables that have two or more logical levels of row or column headers?
  8. Are frames titled with text that facilitates frame identification
    and navigation?
  9. Are pages designed to avoid causing the screen to flicker with a
    frequency greater than 2 Hz and lower than 55 Hz?
  10. Is a text-only page, with equivalent information or functionality,
    provided? (This is to ensure that a web site complies when compliance
    cannot be accomplished in any other way.)
  11. Is the content of the text-only page updated whenever the primary
    page changes?
  12. If the pages use scripting languages to display content, or to
    create interface elements, is the information provided by the script
    identified with functional text? Can the text that can be read by
    assistive technology?
  13. If a web page requires that an applet, plug-in or other application
    be present on the client system to interpret page content, does the page
    provide a link to a plug-in or applet
  14. If electronic forms are designed to be completed on-line, does the
    form allow people using assistive technology to access the information,
    field elements, and functionality required for completion and submission
    of the form, including all directions and cues?
  15. Is a method provided that permits users to skip repetitive
    navigation links?
  16. If a timed response is required, is the user alerted and given
    sufficient time to indicate more time is required?

Value Behind Creating Functional Specifications

Wednesday, December 26th, 2007 by DJ Bragg

Creating a website without a concise plan is a regular, costly
mistake.

There have been countless projects that have failed due to poor planning.
The sites were either never completed, not completed as envisioned, or
over budget/deadline. The largest majority of project failures are a
direct result of miscommunication between site developers, client
and project management.

The functional spec is a continuation of the functional brief and
describes, in non-technical terms, the actions (functionalities) of the
site but not how those actions are to be accomplished. Spec’s outline what
the site does for its visitors for the length of the websites operation.
The value of the creation of Functional Specifications is that there are a
number of ways to ensure that the content is functional
and meets the client’s expectations.

Spec’s allow for the testing team to perform the quality analysis required
to deliver a flawless product/application within the strictest time
frame. This is achieved by:

  • Enumerating the specifications that will be utilize for the life of the
    project.
  • Developing rapid software prototyping capabilities that make it faster
    to develop and communicate user interface designs to everybody.
  • Clarifying all requirements.

Specs greatly improve communication with web development teams, eliminate
time wasted as a result of false assumptions, put the control in the hands
of the client, and are often used in presentations. Ultimately, specs save
time and money, while improving the quality of the final website.