Testing Strategy in software testing

The test strategy is a formal description of how a software product will be tested. A test strategy is developed for all levels of testing, as required. The test team analyzes the requirements, writes the test strategy and reviews the plan with the project team. The test plan may include test cases, conditions, the test environment, a list of related tasks, pass/fail criteria and risk assessment.
Inputs for this process:
1. A description of the required hardware and software components, including test tools. This information comes from the test environment, including test tool data.
2. A description of roles and responsibilities of the r resources required for the test and schedule constraints. This information comes from man-hours and schedules.
3. Testing methodology. This is based on known standards.
4. Functional and technical requirements of the application. This information comes from requirements, change request, technical and functional design documents.
5. Requirements that the system can not provide, e.g. system limitations, Outputs for this process:
6. An approved and signed off test strategy document, test plan, including test cases.
7. Testing issues requiring resolution. Usually this requires additional negotiation at the project management level.

1 Reply

Know the answer? Post it — somebody with the same question will find it here.

Satyapriya Nayak14y ago
The test strategy is a formal description of how a software product will be tested. A test strategy is developed for all levels of testing, as required. The test team analyzes the requirements, writes the test strategy and reviews the plan with the project team. The test plan may include test cases, conditions, the test environment, a list of related tasks, pass/fail criteria and risk assessment.
Inputs for this process:
1. A description of the required hardware and software components, including test tools. This information comes from the test environment, including test tool data.
2. A description of roles and responsibilities of the r resources required for the test and schedule constraints. This information comes from man-hours and schedules.
3. Testing methodology. This is based on known standards.
4. Functional and technical requirements of the application. This information comes from requirements, change request, technical and functional design documents.
5. Requirements that the system can not provide, e.g. system limitations, Outputs for this process:
6. An approved and signed off test strategy document, test plan, including test cases.
7. Testing issues requiring resolution. Usually this requires additional negotiation at the project management level.

0