What are Test Strategy, Test Approach and Test method ?
What Is a Test Strategy?
A test strategy is a planning document that provides the overall direction for the software testing needs of a project. Developing a test strategy is about setting direction and resolving high-level testing questions. The value of the test strategy isn’t in the wording, the writing, or the format of the strategy; the value is in planning an approach for testing.
Test strategies can range from informal to very formal. In its simplest form, the test strategy is exactly that—a strategy. It’s a roadmap for what testing will be done, and details the way in
which the testing will be accomplished:
How? Answers to this question might identify the types of testing needed, such as manual or automated testing.
Where? These answers detail the actual test environment, including specific server names, and may include a diagram of all the physical or logical components.
Who? The test strategy must specify the testing resources and other resources needed to accomplish the testing.
When? A good test strategy outlines the time of the first internal build for testing and likely includes a rough schedule for the remainder of the project.
These high-level questions need answers early in a project. The test strategy also might address related testing topics such as purchasing test tools or the defect-reporting process.
The test approach describes the types of tests performed and the sequence of tests as executed in the test lab.
The types of tests that were considered for testing the Small IT Solution include:
These tests are limited to specific configurations made within the solution.
Build Verification Tests
The following goals were adopted for build verification testing:
Clarity: The steps should clearly describe the options that must be selected to enable the service.
Completeness: All configuration options required to configure the service are described.
Presentation: The process for configuring the service is linearly presented and represents the process that must be followed when initially deploying the solution.
Consistency: The configuration options presented in the solution should always use the tools that are best suited for configuring the service. Consistency for each service is summarized as follows:
The following goals were adopted for functional testing:
· Completeness: The functional test cases ensure that the technical goals of the solution are achieved.
The following goals were adopted for security tests:
Technical Writing Tests
The goals of the technical writing tests are as follows:
The following goals were adopted for security tests:
• Principle of least privilege: The configuration recommendations should follow the principle of assigning least privilege.
• Availability: Verify that configuration recommendations have not been made that reduce the availability of the systems within the solution, due to the activity of some person or system. This includes accidental or malicious activity.
• Integrity: Verify that recommendations have not been made that may result in a loss of business data integrity.
• Confidentiality: Ensure that recommendations have not been made that may result in the disclosure of information to unauthorized users.
• Spoofing: Ensure that recommendations have not been made that may allow a user or system to impersonate an authorized user or system. Ensure that recommendations do not allow for credential theft.
• Repudiation: Ensure that there is specific and unchangeable proof of critical actions on a server.
The test involved the following phases:
1. Build phase: Each test cycle began with this phase. In this phase, the required hardware was installed and connected, network cables were connected, and other hardware configuration was completed.
2. Build verification testing phase: The test team performed solution configuration using the solution documentation and build verification test cases. This ensured that the systems were built and configured as documented. Build tests quickly exposed human errors made in the guidance as well as errors in the completeness of the deployment guidance that resulted in services not functioning properly.
3. Functional testing phase: Once build testing was complete, the test team focused on verifying key functions of the products and solution.
4. Management testing phase: Management testing verified that the requirements of the remote management strategy were met within the solution configuration and design.
5. Technical writing testing phase: These tests ensured that the communication style and documentation links were correct and consistent.
6. Security testing phase: The security testing phase was the last phase in each test cycle. This phase ensured that all generated security test cases were executed on the complete end-state environment.
A test method is a definitive procedure that produces a test result.
The test result can be qualititive (yes/no), categorical, or quantititive (a measured value). It can be a personal observation or the output of a precision instrument.
Usually the test result is the dependent variable, the measured response based on the particular conditions of the test or the level of the independent variable. Some tests, however, involve changing the independent variable to determine the level at which a certain response occurs: in this case, the test result is the independent variable.
Posted @ Saturday, September 17, 2011 3:39 AM by Edwin Antony
Here is the blog contains Reusable sharepoint Test Scenarios
Might be this will be very usefull for those who are very new to sharepoint testing
for any more docs, doubts and for suggestions your mails are welcome to firstname.lastname@example.org
Posted @ Saturday, June 4, 2011 3:24 PM by Manas
I was looking for detail in strategy and found this as the best and the statements were more practical not the theoretical.