Software Testing Methods

Part:   1  2  3  4  5  6   7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25  26  27  28 

(Continued from previous part...)

Task-Oriented Functional Test

The task-oriented functional test (TOFT) consists of positive test cases that are designed to verify program features by checking the task that each feature performs against specifications, user guides, requirements, and design documents. Usually, features are organized into list or test matrix format. Each feature is tested for:

• The validity of the task it performs with supported data conditions under supported operating conditions.
• The integrity od the task's end result
• The feature's integrity when used in conjunction with related features

Forced-Error Test

The forced-error test (FET) consists of negative test cases that are designed to force a program into error conditions. A list of all error messages thatthe program issues should be generated. The list is used as a baseline for developing test cases. An attempt is made to generate each error message in the list. Obviously, test to validate error-handling schemes cannot be performed until all the handling and error message have been coded. However, FETs should be thought through as early as possible. Sometimes, the error messages are not available. The error cases can still be considered by walking through the program and deciding how the program might fail in a given user interface such as a dialog or in the course of executing a given task or printing a given report. Test cases should be created for each condition to determine what error message is generated.

Real-world User-level Test

These tests simulate the actions customers may take with a program. Real-World user-level testing often detects errors that are otherwise missed by formal test types.

Exploratory Test

Exploratory Tests do not involve a test plan, checklist, or assigned tasks. The strategy here is to use past testing experience to make educated guesses about places and functionality that may be problematic. Testing is then focused on those areas. Exploratory testing can be scheduled. It can also be reserved for unforeseen downtime that presents itself during the testing process.

Compatibility and Configuration Testing

Compatibility and configuration testng is performanced to check that an application functions properly across various hardware and software environments. Often, the stragegy is to run the functional acceptance simple tests or a subset of the task-oriented functional tests on a range of software and hardware configurations. Sometimes, another strategy is to create a specific test that takes into account the error risks associated with configuration differences. For example, you might design an extensive series of tests to check for browser compatibility issues. Software compatibility configurations include variances in OS versions, input/output (I/O) devices, extension, network software, concurrent applications, online services and firewalls. Hardwere configurations include variances in manufacturers, CPU types, RAM, graphic display cards, video capture cards, sound cards, monitors, network cards, and connection types(e.g. T1, DSL, modem, etc..).

Documentation

Testing of reference guides and user guises check that all features are reasonably documented. Every page of documentation should be keystroke-tested for the following errors:

• Accuracy of every statement of fact
• Accuracy of every screen shot, figure and illustation
• Accuracy of placement of figures and illustation
• Accuracy of every tutorial, tip, and instruction
• Accuracy of marketing collateral (claims, system requirements,and screen shots)
• Accuracy of downloadable documentation(PDFs, HTML, or test files)

(Continued on next part...)

Part:   1  2  3  4  5  6   7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25  26  27  28