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.
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.
Explain the need for GUI testing and its complexity?
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 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