Application-Help Systems - Web Service Testing

Application-help systems reside within and support software applications. They commonly support users in operating applications by offering context-sensitive assistance. Context-sensitive help gives users instruction that is relevant to the activities they are actively engaged in. An example of context-sensitive help includes clicking a Help button while a credit card billing information form is displayed.

Clicking the Help button in this context generates help content that explains the controls and functionality associated with the billing form. Sometimes, you also get explanations of the intent of the form and the place of the form in a long transaction chain—that is, sometimes, you get help that explains the application, not just its buttons.

Reference-Help Systems
Reference-help systems offer in-depth information about specific subjects, such as building a Web site or digital photography basics. They do not act as how-to guides for specific applications. Web-based reference systems are organized around the subject matter they present in a way that is similar to how printed reference books are organized into chapters. Unlike printed books, however, online reference systems include cross-referenced hyperlinks between related topics. Although they are generally c ntext sensitive, they can often be read linearly like a book, if required.

Tutorial-Help Systems
Tutorial-help systems walk users through specific how-to lessons in an effort to train them in a given subject matter. Occasionally, such systems are used in tandem with books (possibly in a school setting). Tutorial-help systems are often interactive, encouraging user input and offering feedback. This type of help system generally lacks context sensitivity.

Sales and Marketing–Help Systems
Sales and marketing tools convey product benefits to potential customers. The goal of sales and marketing–help systems is to get users to buy certain products or take an action of some kind, such as filling out a Web-based questionnaire or requesting information from a manufacturer via an online form. These systems may include live demonstrations and interactivity. The products being presented may or may not be software applications. This type of help system generally lacks context sensitivity.Evaluating the Target User

There are four primary skill types that should be tracked when evaluating target users: (1) computer experience, (2) Web experience, (3) subject matter experience, and (4) application experience. ("User Interface Tests," for detailed explanations of target-user skill types.) Considering your application, English skill or grade level may also need to be evaluated. A help system should be evaluated by how closely its characteristics match the experience and skills of its intended users. Discrepancies in experience level between target user and system indicate the potential for error conditions and poor usability. The key question is whether the help system communicates the information that the reader needs, in a way that the reader can understand.

Evaluating the Design Approach
Web-based help system design entails the same testing challenges that are involved in UI testing. Look and feel, consistency, and usability tests all come into play. Means of navigation, UI controls, and visual design (colors, fonts, placement of elements, etc.) should be intuitive and consistent from screen to screen. "User Interface Tests," for detailed information regarding design approach, consistency testing, and usability testing. However, the mission is different. Here, the entire point of the application is to present content in a way that is easy to find and easy to understand, but with a slick display.

Evaluating the Technologies
Some of the authoring technologies used for Web-based help systems are:

Standard HTML (W3 Standard)

Standard HyperText Markup Language (HTML) page technology can be used to build help systems that combine framesets, multiple windows, and hyperlinks. As with any HTML-based system, hyperlinks must be tested for accuracy.

Context sensitivity presents complications in HTML-based systems. The correct help page ID must be passed whenever the Help button is clicked. However, HTML does not allow for the same hierarchical architecture that Windows-based applications are built upon. Thus, users may advance to other screens while viewing help content that is no longer applicable, the help browser window might become hidden by the application window, or the wrong page ID might be passed, resulting in incorrect help content.

Some applications, such as eHelp's (formerly Blue Sky Software) WebHelp, support the authoring of Web-based help systems that have Windows-styled help features such as full-text browsing and pop-up windows. WebHelp uses Dynamic HTML and supports both Internet Explorer and Netscape Navigator.

Java-based help systems can be run from servers while UI is displayed through Web browsers. Sun Microsystem's JavaHelp combines HTML and XML with 100 percent Pure Java. JavaHelp is a platform-independent authoring environment that enables developers to create online help in Web-based applications and Java applets.

Netscape NetHelp
NetHelp is a HTML-based, cross-platform, online help-authoring environment. It is based on technology that is built into the Netscape Communicator suite. It is compatible only with Navigator. Figure shows an example of Netscape's NetHelp help system.

RoboHelp's HTML-based WebHelp

RoboHelp's HTML-based WebHelp

ActiveX Controls
Microsoft's HTML Help ActiveX control allows for the creation of Web-based help systems that have tables of contents, cross-referencing links, indices, and a splash window that accompanies the HTML Help Viewer. It is compatible only with Internet Explorer.

Help Elements
Web-based help systems are commonly made up of the following elements. Help systems created with authoring programs such as WebHelp have many design elements that mimic the features of Windows-based help systems. Such elements include the book-and-page metaphor for help topic organization.
Elements to test include:

Contents tab (optional)

  1. Book links
  2. Page links
  3. Topic page names
  4. Topic displayed in main window
  5. Topic displayed in secondary window

Index tab

  1. Single-level
    • With sublist
    • Without sublist
  2. Multilevel
    • With sublist
    • Without sublist

Find tab (optional)

  • Full-text search
  • Associative links

Other custom tabs (optional)

  • Favorites


  • Self-defining terms
  • Browse sequences

JavaHelp Java-based help system

JavaHelp Java-based help system

Netscape NetHelp help system

Netscape NetHelp help system

Rich topics

  • Video
  • Sound
  • Links
  • Text
  • Graphics

Dynamic content

  • Scripting
  • ActiveX controls
  • ActiveX-based Microsoft HTML Help

    ActiveX-based Microsoft HTML Help

  • XML
  • Java applets

Context-sensitive help

Pop-up windows (self-sizing)

Secondary windows (self-sizing)


Expanding text (DHTML)

Pull-down text (DHTML)

Approaching Help Testing
Once the technological particulars of the system have been identified, you can begin the testing process.

Testing the Sample Application
The help system of the sample application is built with standard HTML. It can be accessed from ny screen in the application by clicking the Help button, so it is an application-help system. An example is shown in Figure.

Sample application's standard HTML help system

Sample application's standard HTML help system

Looking at the design approach of the help system, you see that the system is context sensitive; clicking the Help button at any time while using the application links users directly to help content that supports the current activities and on-screen options. Each help screen includes a table of contents hyperlink. Users click this link to access the system's table of contents, from which they can access related content and, if they wish, read the entire system's contents from start to finish like a reference book. Also, hyperlinked keywords within the text link users to related content.

Though client-side users (end users and administrators) have access to differing privileges and UI controls in the sample application, both user types are referred to the same help system. This approach has positive and negative implications. End users may be exposed to administrator-level content that they do not expect or understand.

Two-Tiered Testing
The testing phase is a two-tiered process that includes testing the help system as a stand-alone system and testing the help system's interaction with the application.

Stand-Alone Testing
Web-based help systems are subject to the same compatibility and functionality issues as are all applications. They need to be evaluated as stand-alone applications in accordance with the technologies that created them—Java-based systems, for example, should be tested in the same way that any stand-alone Java application would be tested. ActiveX-based systems, like all ActiveX components, should be evaluated for compatibility issues (they should support all the relevant versions of browsers).

Interaction between the Application and the Help System The help system must be tested in combination with the application to ensure that all context-sensitive IDs are passed and that correct help content is displayed throughout all states of the application. Issues to consider include the map file:

  • Names of help files
  • Topic IDs for Help buttons on dialog boxes
  • Accessing help through F1, shortcut keys, buttons, and so on

Types of Help Errors
Following are a number of help-related testing issues and error examples.


  • Functional testing of a help system checks whether everything is operating as intended. Each link should be operational and lead users to their intended destination. All graphics should load properly.
  • Web systems are vulnerable to environmental conditions surrounding platform compatibility, display resolutions, and browser types.
  • As with all Web content, help systems should operate consistently across multiple screen resolutions, color palette modes, and font size settings. This is a particularly important issue for help because these types of legibility errors are common. For information regarding testing of display settings and fonts, see Appendix G "Display Compatibility Test Matrix." This matrix shows lists of display settings to use during your help testing. It is good practice to change your display settings regularly during the course of your testing, and it is particularly important during help testing as help probably uses different technology to be displayed; formatting and readability issues are key to a useful help system.


  • Help system implementation should be consistent throughout; otherwise, user confusion may result.

Consistency issues to test for include:

  • Organization. Is the system structured in a way that makes sense? Are available options clearly laid out for users? Is the system easy to navigate?
  • Design approach. Applications are often designed around familiar structures and patterns to enhance their usability. Many help systems are organized hierarchically; some are context sensitive. Is the metaphor used by your system consistent from screen to screen?
  • Do methods of searching and navigation remain consistent?
  • Terminology. Is there consistency of language throughout the system? A command or term referred to in one context should be referred to in the same way in all other contexts.
  • See the section entitled "Testing for Consistency" "User Interface Tests," for a list of synonymous commands that are often mistakenly interchanged.
  • Fonts and colors. Are font sizes and styles used consistently throughout the system? Are links, lettering, backgrounds, and buttons presented consistently?
  • Format. Text should be formatted consistently.


  • Usability concerns how well a help system supports its users. Usability issues are often subjective. Ideally, users should be able to easily navigate through a help system and quickly get to the information they need.
  • Does context-sensitive assistance adequately support users from screen to screen?
  • Is the system appropriately designed for the skill levels of the target user?
  • What about user perception—will users consider the system to be useful, accurate, and easy to navigate?
  • How many clicks does it take users to get to the information they are looking for?
  • "User Interface Tests," for more information on consistency and usability testing.


  • A help system is only as valuable as the information it conveys. Inaccuracies in procedural instruction lead to confusion. In some instances, technical inaccuracies in help systems can lead to serious data loss.
  • Every fact and line of instruction detailed in a help system should be tested for accuracy.
  • Content should be tested for correct use of grammar and spelling.
  • Has important information been omitted?


  • Functional testing of a help system ensures that everything is operating as intended. Each link should be operational and lead the user to the intended destination. All graphics should load properly. The table of contents links should be working.
  • Help elements to be tested for proper functionality include:
  • Jumps
  • Pop-ups
  • Macros
  • Keyword consistency
  • Buttons
  • Navigation
  • Context-sensitive links
  • Frames/no frames


  • Compatibility
  • Performance
  • Look for and research errors that are common to each technology type, then design test cases that look for those errors.
  • Visit online technical support and issue databases that are specific to each technology type. Such sites list bugs that users have dealt with in the past. They are a great place to begin research for test-case design.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd Protection Status

Web Service Testing Topics