TESTING STRATEGY

Test Strategy

Actual writing of a strategy involves aspects, which define other issues between the Testing organization and the client. Testers must basically understand some of the issues that are discussed in the strategy document, which are outlined below.



Testing Approach

The testing process may take the form of an End-to-End approach or individual segment testing using various values.

End-to-End: The test path uses the entire flow provided in the application for completion of a specified task. Within this process various test conditions and values are covered and results analyzed. There maybe a possibility of reporting several defects relating to the segments while covering the test path. The advantage of using this approach is to minimize combination and permutation of conditions/values and ensure coverage and integration.

Individual Segment Testing: Several conditions and values are identified for testing at the unit level for testing. These are tested as separate cases.

Automation Strategy

Automation of testing process is done to reduce the effort during regression testing. In some cases automating the entire testing process may not possible due to technical and time constraints. The possible automation strategies that could be adopted depending on the type of the project are

Selective: Critical and complex cases are identified. These test cases are generally automated to simplify the testing process and save time.

Complete: As the term suggests, all test cases technically possible are automated.


Performance Strategy

The client specifies the standards for the performance testing. It generally contains

· Response time
· Number of Virtual Users

Using the above information, a Usage Pattern of the application is derived and documented in the strategy. Issues discussed in the performance strategy document are

Resources: Personnel trained in Performance testing tool identified. Datewise utilization of the resources is laid down.
Infrastructure: Generation of virtual users require huge amount of RAM. The performance team should be given a machine, which is suitable for the performance tool.

Report: The type of report that will be generated after the tests are discussed. Reports are ideally in the form of graphs. Reports generated are:

· Detailed Transaction Report (By Virtual user)
· Throughput Graph
· Hits per second Graph
· Transaction per second
· Transaction Response Time Graph
· Transaction Performance Summary Graph
· Transaction Distribution Graph
· Transaction Performance Summary Graph

Risk Analysis

Risk’s associated with projects are analyzed and mitigation’s are documented in this document. Types of risk that are associated are

Schedule Risk: Factors that may affect the schedule of testing are discussed.





Technology Risk: Risks on the hardware and software of the application are discussed here

Resource Risk: Test team availability on slippage of the project schedule is discussed.

Support Risk: Clarifications required on the specification and availability of personnel for the same is discussed.

Effort Estimation

The function points in the Functional Specifications will be used, as the basis for the purpose of estimating the effort needed for the project. The average of the different estimates from the Peers in the test team will be taken as the basis for calculation of the effort required.

There could be some variation in the planned to actual effort. An effort estimation review will be done by a Senior Consultant to identify gaps, if any.

In case of the UAT, function points are taken from the Business Requirement document.

Infrastructure

Hardware and software requirements for the testing the application are documented. Apart from this, any other requirement should also be documented. Infrastructure that has to be provided by the client is also specified.