Install and uninstallation Testing Tips

Web system often requires both client-side and server-side installs. Testing of the installer checks that installed features function properly–including icons, support documentation, the README file, and registry keys. The test verifies that the correct directories are created and that the correct system files are copied to the appropriate directories. The test also confirms that various error conditions are detected and handled gracefully.
Testing of the uninstaller checks that the installed directories and files are appropriately removed, that configuration and system-related files are also appropriately removed or modified, and that the operating environment is recovered in its original state.

Compatibility and Configuration Testing

Perform to check that an application functions properly across various hardware and software environments by using Compatibility and configuration testing. Often, the strategy 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. Hardware 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.)

Exploratory Testing

Exploratory Testing 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

Real world User level Testing

Missed errors by formal test cases are found by using this method of testing. These tests simulate the actions customers may take with a program

Forced Error Testing

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 that the 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 interfaces 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.

Task Oriented Functional Testing

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 do the task’s end result
• The feature’s integrity when used in conjunction with related features

Deployment Acceptance Testing

The configuration on which the Web system will be deployed will often be much different from develop-and-test configurations. Testing efforts must consider this in the preparation and writing of test cases for installation time acceptance tests. This type of test usually includes the full installation of the applications to the targeted environments or configurations

Functional Acceptance Simple Test

The functional acceptance simple test (FAST) is run on each development release to check that key features of the program are appropriately accessible and functioning properly on the at least one test configuration (preferable the minimum or common configuration).This test suite consists of simple test cases that check the lowest level of functionality for each command- to ensure that task-oriented functional tests (TOFTs) can be performed on the program. The objective is to decompose the functionality of a program down to the command level and then apply test cases to check that each command works as intended. No attention is paid to the combination of these basic commands, the context of the feature that is formed by these combined commands, or the end result of the overall feature. For example, FAST for a File/Save As menu command checks that the Save As dialog box displays. However, it does not validate that the overall file-saving feature works nor does it validate the integrity of save files.

Release Acceptance Test

The release acceptance test (RAT), also referred to as a build acceptance or smoke test, is run on each development release to check that each build is stable enough for further testing. Typically, this test suite consists of entrance and exit test cases plus test cases that check mainstream functions of the program with mainstream data. Copies of the RAT can be distributed to developers so that they can run the tests before submitting builds to the testing group. If a build does not pass a RAT test, it is reasonable to do the following:

• Suspend testing on the new build and resume testing on the prior build until another build is received
• Report the failing criteria to the development team
• Request a new build

Types of Testing Comes Under Testing Levels

1. Unit Testing

• Unit Testing is primarily carried out by the developers themselves
• Deals functional correctness and the completeness of individual program units
• White box testing methods are employed

2. Integration Testing

• Integration Testing: Deals with testing when several program units are integrated
• Regression testing: Change of behavior due to modification or addition is called ‘Regression’. Used to bring changes from worst to least
• Incremental Integration Testing: Checks out for bugs which encounter when a module has been integrated to the existing
• Smoke Testing: It is the battery of test which checks the basic functionality of program. If fails then the program is not sent for further testing

3. System Testing

• System Testing : Deals with testing the whole program system for its intended purpose
• Recovery testing: System is forced to fail and is checked out how well the system recovers the failure
• Security Testing: Checks the capability of system to defend itself from hostile attack on programs and data
• Load & Stress Testing: The system is tested for max load and extreme stress points are figured out
• Performance Testing: Used to determine the processing speed
• Installation Testing: Installation & uninstallation is checked out in the target platform

4. Acceptance Testing

• UAT: ensures that the project satisfies the customer requirements
• Alpha Testing : It is the test done by the client at the developer’s site
• Beta Testing : This is the test done by the end-users at the client’s site
• Long Term Testing : Checks out for faults occurrence in a long term usage of the product
• Compatibility Testing : Determines how well the product is substantial to product transition

Which Type of Testing using in your Organization ? Post your answers as comment or to our Tangler Post a Comment