TEST PLANNING: The testing process can be divided into three phases [Hetzel]: planning, acquisition and execution

& evaluation. The planning phase provides an opportunity for the tester to determine what to test and how to test it. The acquisition phase is the time during which the required testing software is manufactured, data sets are defined and collected, and detailed test scripts are written. During the execution and evaluation phase the test scripts are executed and the results of that execution are evaluated to determine whether the product passed the test.

Advantages of test plan

Serves as a guide to testing throughout the development. We only need to define test points during the testing phase. Serves as a valuable record of what testing was done. The entire test plan can be reused if regression testing is done later on. The test plan itself could have defects just like software!

In software testing, a test plan gives detailed testing information regarding an upcoming testing effort, including

Scope of testing Schedule Test Deliverables Release Criteria Risks and Contingencies

TEST PLAN

The test plan keeps track of possible tests that will be run on the system after coding. The test plan is a document that develops as the project is being developed. Record tests as they come up Test error prone parts of software development. The initial test plan is abstract and the final test plan is concrete. The initial test plan contains high level ideas about testing the system without getting into the details of exact test cases. The most important test cases come from the requirements of the system. When the system is in the design stage, the initial tests can be refined a little. During the detailed design or coding phase, exact test cases start to materialize.

Purpose of Software Test Plan:

After coding, the test points are all identified and the entire test plan is exercised on the software.

To achieve 100% CORRECT code. Ensure all Functional and Design Requirements are implemented as specified in the documentation. To provide a procedure for Unit and System Testing. To identify the documentation process for Unit and System Testing. To identify the test methods for Unit and System Testing.

Test Execution:
The following activities are involved in performance test execution:

Validate the test environment Validate tests Run tests Baseline and benchmark Archive tests

The following sections discuss each of these activities in detail.

Validate the Test Environment

The goal is for the test environment to mirror your production environment as closely as possible. Typically, any differences between the test and production environments are noted and accounted for while designing tests. Before running your tests, it is important to validate that the test environment matches the configuration that you were expecting and/or designed your test for. If the test environment is even slightly different from the environment you designed your tests to be run against, there is a high probability that your tests might not work at all, or worse, that they will work but will provide misleading data. The following activities frequently prove valuable when validating a test environment:

Ensure that the test environment is correctly configured for metrics collection. Turn off any active virus-scanning on load-generating machines during testing, to minimize the likelihood of unintentionally skewing results data as a side-effect of resource consumption by the antivirus/anti-spyware software. Consider simulating background activity, when necessary. For example, many servers run batch processing during predetermined time periods, while servicing users requests. Not accounting for such activities in those periods may result in overly optimistic performance results. Run simple usage scenarios to validate the Web server layer first if possible, separately from other layers. Run your scripts without think times. Try to run a scenario that does not include database activity. Inability to utilize 100 percent of the Web servers processor can indicate a network problem or that the load generator clients have reached their maximum output capacity.

Validate Tests
Poor load simulations can render all previous work useless. To understand the data collected from a test run, the load simulation must accurately reflect the test design. When the simulation does not reflect the test design, the results are prone to misinterpretation. think about test validation in terms of the following four categories:

Test design implementation Concurrency. After you have validated that your test conforms to the test design when run with a single user, run the test with several users Combinations of tests. Having validated that a test runs as intended with a single user and with multiple users, the next logical step is to validate that the test runs accurately in combination with other tests. Test data validation. Once you are satisfied that your tests are running properly, the last critical validation step is to validate your test data. Performance testing can utilize and/or consume large volumes of test data

Test Validation
The following are some commonly employed methods of test validation, which are frequently used in combination with one another:

Run the test first with a single user only. This makes initial validation much less complex. Observe your test while it is running and pay close attention to any behavior you feel is unusual. Your instincts are usually right, or at least valuable. Use the system manually during test execution so that you can compare your observations with the results data at a later time. Make sure that the test results and collected metrics represent what you intended them to represent. Check to see if any of the parent requests or dependent requests failed. Check the content of the returned pages, as load-generation tools sometimes report summary results that appear to pass even though the correct page or data was not returned. Run a test that loops through all of your data to check for unexpected errors.