Testing for Specialized Environments


The need for specialized testing approaches is becoming mandatory as computer software has become more complex. The White-box and black box testing methods are applicable across all environments, architectures and applications, but unique guidelines and approaches to testing are sometime important. We address the testing guidelines for specialized environments, architectures, and applications that are commonly encountered by software engineers.

Testing GUIs

The growth of Graphical User Interfaces (GUIs) in various applications has become a challenge for test engineers. Because of reusable components provided as part of GUI development environments, the creation of the user interface has become less time consuming and more precise. GUI is becoming mandatory for any application as users are used to it. Sometime, the user interface may be treated as a different layer and easily separated from the traditional functional or business layer.

The design and development of user interface layer requires separate design and development methodology. Here the main problem is to understand the user psychology during the development time. Due to complexity of GUIs, testing and generating test cases has become more complex and tedious. Because of modern GUIs standards (same look and feel), common tests can be derived.

What are the guidelines to be followed which helps for creating a series of generic tests for GUIs?

Guidelines can be categorized into many operations. Some of them are discussed below:

For windows:

  • Will the window open properly based on related typed or menu-based commands?

  • Can the window be resized, moved, scrolled?

  • Does the window properly regenerate when it is overwritten and then recalled?

  • Are all functions that relate to the window available when needed?

  • Are all functions that relate to the window available when needed?

  • Are all functions that relate to the window operational?

  • Are all relevant pull-down menus, tool bars, scroll bars, dialog boxes, and buttons, icons, and other controls available and properly represented?

  • Is the active window properly highlighted?

  • If multiple or incorrect mouse picks within the window cause unexpected side effects?

  • Are audio and/or color prompts within the window or as a consequence of window operations presented according to specification?

  • Does the window properly close?

For pull-down menus and mouse operations:

  • Is the appropriate menu bar displayed in the appropriate context?

  • Does the application menu bar display system related features (e.g. a clock display)

  • Do pull-down operations work properly?

  • Do breakaway; menus, palettes, and tool bars work properly?

  • Are all menu functions and pull-down sub functions properly listed?

  • Are all menu functions and pull-down sub functions properly listed?

  • Are all menu functions properly addressable by the mouse?

  • Are text typeface, size, and format correct?

  • Is it possible to invoke each menu function using its alternative text-based command?

  • Are menu functions highlighted (or grayed-out) based on the context of current operations within a window?

  • Does each menu function perform as advertised?

  • Are the names of menu functions self-explanatory?

  • Is help available for each menu item, and is it context sensitive?

  • Are mouse operations properly recognized throughout the interactive context?

  • If multiple clicks are required, are they properly recognized in context?

  • If the mouse has multiple buttons, are they properly recognized in context?

  • Do the cursor, processing indicator (e.g. an hour glass or clock), and pointer properly change as different operations are invoked?

Data entry:

  • Is alphanumeric data entry properly echoed and input to the system?

  • Do graphical modes of data entry (e.g., a slide bar) work properly?

  • Is invalid data properly recognized?

  • Are data input messages intelligible?

  • Are basic standard validation on each data is considered during the data entry itself?

  • Once the data is entered completely and if a correction is to be done for a specific data, does the system requires entering the entire data again?

  • Does the mouse clicks are properly used?

  • Does the help buttons are available during data entry?

In addition to the above guidelines, finite state modeling graphs may be used to derive a series of tests that address specific data and program objects that are relevant to the GUI.

related post


INTEGRATION TESTING PART ONE

INTEGRATION TESTING PART TWO

INTEGRATION TESTING PART THREE

INTEGRATION TESTING PART FOUR

INTEGRATION TESTING PART FIVE

INTEGRATION TEST STANDARDS

INTEGRATION TEST STANDARDS PART TWO

QUALITY TESTING

QUALITY ASSURANCE

QUALITY ASSURANCE PART TWO

QUALITY ASSURANCE SQA

QUALITY OF DESIGN OF TEST CASE

QUALITY MANAGEMENT IN SOFTWARE TESTING

TOOLS FOR QUALITY MANAGEMENT

STATICAL QUALITY ASSURANCE

ISO APPROACH TO QUALITY TESTING

No comments:

Post a Comment