Testing for Specialized Environments part two

Testing of Client/Server Architectures

Client/server architectures represent a significant challenge for software testers. The distributed nature of client/server environments, the performance issues associated with transaction processing, the potential presence of a number of different hardware platforms, the complexities of network communication, the need to service multiple clients from a centralized (or in some cases, distributed) database, and the coordination requirements imposed on the server all combine to make testing of C/S architectures and the software that reside within them considerably more difficult than testing standalone applications.

In fact, recent industry studies indicate a significant increase in testing time and cost when C/S environments are developed.

Testing documentation and Help facilities

Errors in documentation can be as devastating to the acceptance of the program as errors in data or source e code. You must have seen the difference between following the user guide and getting results or behaviors that do not coincide with those predicted by the document. For this reason, documentation testing should be a meaningful part of every software test plan.

Documentation testing can be approached in two phases. The first phase, formal technical review, examines the document for editorial clarity. The second phase, live test, users the documentation in conjunction with the use of the actual program.

Some of the guidelines are here:

• Does the documentation accurately describe how to accomplish each mode of use?

• Is the description of each interaction sequence accurate?

• Are examples accurate and context based?

• Are terminology, menu descriptions, and system responses consistent with the actual program?

• Is it relatively easy to locate guidance within the documentation?

• Can troubleshooting be accomplished easily with the documentation?

• Are the document table of contents and index accurate and complete?

• Is the design of the document (layout, typefaces, indentation, graphics) conducive to understanding and quick assimilation of information?

• Are all error messages displayed for the user described in more detail in the document?

• If hypertext links are used, are they accurate and complete?

The only viable way to answer these questions is to have an independent third party to test the documentation in the context of program usage. All discrepancies are noted, and areas of document ambiguity or weakness are defined for potential rewrite.

Questions

1. Explain the need for GUI testing and its complexity?

2. List the guidelines required for a typical tester during GUI testing?

Select your own GUI based software system and test the GUI related functions by using the listed guidelines.


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