- Compare with Test plan
The test strategy is an outline describing the software development cycle testing approach. This is made to inform project managers, testers, and developers about some key issues of the testing process. These include testing objectives, new function testing methods, total time and resources required for the project, and test environment.
The test strategy describes how the stakeholder's product risk is reduced at the test level, what type of testing should be performed, and which entry and exit criteria apply. They are based on development design documents. Document design systems are mainly used and sometimes, conceptual design documents can be referenced. The design document describes the functionality of the software to be activated in future releases. For each stage of development design, appropriate test strategies should be established to test the new feature set.
Video Test strategy
Test level
The test strategy describes the level of tests to be performed. There are three levels of testing: unit testing, integration testing, and system testing. In most software development organizations, developers are responsible for unit testing. Individual testers or test teams are responsible for system integration and testing.
Maps Test strategy
Roles and responsibilities
The roles and responsibilities of test leaders, individual testers, project managers must be clearly defined at the project level in this section. It may not have a related name: but the role must be defined very clearly.
The test strategy should be reviewed by the developer. They should also be reviewed by test leads for all test levels to ensure complete coverage but not overlap. Both the test manager and the development manager must agree on the testing strategy before testing can begin.
Environmental requirements
Environmental requirements are an important part of the testing strategy. It describes what operating system is used for testing. It also clearly informs the required OS patch level and required security updates. For example, certain test plans may require Windows XP Service Pack 3 to be installed as a prerequisite for testing.
Test tools
There are two methods used in executing test cases: manual and automatic. Depending on the nature of testing, it is usually the case that a combination of manual and automated testing is the best testing method.
Risk and mitigation
Any risks that will affect the testing process should be included together with mitigation. By documenting the risk, the event can be anticipated much before its time. Proactive action may be taken to prevent it from happening, or to reduce its damage. Sample risk is the dependency of coding completion done by the subcontractor, or the ability of the testing tool.
Test schedule
A test plan should make an estimate of how long it will take to complete the testing phase. There are many requirements to complete the testing phase. First, the testers must do all the tests at least once. Furthermore, if defects are found, the developers need to fix the problem. The examiner should then retest the failed test case until it is functioning properly. Last but not least, the tester needs to do regression testing towards the end of the cycle to make sure the developers unintentionally solve parts of the software while improving other parts. This may occur in previously well-functioning test cases.
The test schedule should also record the number of testers available for testing. If possible, assign test cases to each tester.
It is often difficult to make accurate estimates of the test schedule because the testing phase involves a lot of uncertainty. Planners should consider the extra time required to accommodate contingent issues. One way to make this approach is to look at the time required by previous software releases. If the new software, multiplying the approximate initial test schedule with two is a good way to get started.
Regression test approach
When certain problems are identified, the program will be debuged and improvements will be made to the program. To ensure that the repair works, the program will be retested for that criteria. Regression tests will ensure that one fix does not create some other problems in the program or in other interfaces. Thus, a set of related test cases may have to be repeated again, to ensure that nothing else is affected by certain improvements. How this will be done should be described in this section.
Consider different testing levels when choosing a regression test case. Unit testing cases, integration, and systems are good candidates. Select cases that have a direct correlation with the improvement and also include some important business cases that prove basic business scenarios still work. Remember also that non-functional testing (security, performance, usability) plays an important role in proving business continuity.
In some companies, whenever there is an improvement in one unit, all unit test cases for that unit will be repeated, to achieve a higher level of quality.
Group test
From the list of requirements, we can identify related fields, which are similar in function. These areas are the test group. For example, in the railway reservation system, anything related to ticket booking is a functional group; anything related to report generation is a functional group. In the same way, we must identify the test group based on aspects of functionality.
Priority test
Among the trial cases, we need to set priorities. When testing a software project, a particular test case will be treated as the most important and if it fails, the product can not be released. Some other test cases may be treated like cosmetics and if they fail, we can release the product without much compromise on the function. This priority level should be clearly stated. This can be mapped to the test group as well.
Test status collection and reporting
When the test case is implemented, the test leader and the project manager must know, exactly where the project stands in terms of testing activities. To know where the project is located, input from individual testers should be given to the test leader. This will include, what test cases are being run, how long, how many test cases are passed, how many cases fail, and how many cases are not executable. Also, how often does the project collect status should be clearly stated. Some projects will have the practice of collecting status on a daily or weekly basis.
Test record maintenance
When a test case is run, we need to keep track of implementation details as they were executed, who did it, how long, what result, etc. This data should be available to test leaders and project managers, along with all team members, in a central location. These can be stored in a particular directory on the central server and the document should say clearly about the location and the directory. Naming conventions for documents and files should also be mentioned.
Traceability matrix requirement
Ideally, software should really meet a set of requirements. From design, each requirement must be handled in every document in the software process. The documents include HLD, LLD, source code, unit test cases, integration test cases and system test cases. In the requirements matrix traceability, the line will have requirements. The columns represent each document. The intersecting cells are marked when a document discusses a specific requirement with information related to the requirements ID in the document. Ideally, if every requirement is discussed in each document, all individual cells have valid id or part names. Then we know that every requirement is handled. If there is an empty cell, it indicates that the requirements have not been handled properly.
Experiment summary
Senior management may wish to have a weekly or monthly test summary. If the project is so important, they may need it even on a daily basis. This section should discuss what kind of summary report tests will be produced for senior management and their frequency.
The testing strategy should provide a clear vision of what the testing team will do for the entire project for the entire duration. This document can be presented to the client, if required. The person preparing this document should be functionally strong in the product domain, with excellent experience, as it is a document that will encourage the entire team for testing activities. The test strategy should be clearly explained to the test team members at the beginning of the project.
See also
- Software testing
- Test case
- Risk-based testing
References
- Ammann, Paul and Offutt, Jeff. Introduction to software testing. New York: Cambridge University Press, 2008
- Bach, James (1999). "Test Strategy" (PDF) . Retrieved October 31, 2011 .
- Dasso, Aristides. Verification, validation and testing in software engineering. Hershey, PA: Idea Group Pub., 2007
Source of the article : Wikipedia
0 Comments