Test Strategy

1 Test Strategy 1 Introduction This Document entails you towards the better insight of the Test Strategy and its methodology. It is the role of test management to ensure that new or modified service products meet the business requirements for which they have been developed or enhanced. The Testing strategy should define the objectives of all test stages and the techniques that apply. The testing strategy also forms the basis for the creation of a standardized documentation set, and facilitates communication of the test process and its implications outside of the test discipline. Any test support tools introduced should be aligned with, and in support of, the test strategy. Test Approach/Test Architecture are the acronyms for Test Strategy. Test management is also concerned with both test resource and test environment management. 2 Key elements of Test Management: Test organization –the set-up and management of a suitable test organizational structure and explicit role definition. The project framework under which the testing activities will be carried out is reviewed, high level test phase plans prepared and resource schedules considered. Test organization also involves the determination of configuration standards and the definition of the test environment. Test planning – the requirements definition and design specifications facilitate in the identification of major test items and these may necessitate the test strategy to be updated. A detailed test plan and schedule is prepared with key test responsibilities being indicated. Test specifications – required for all levels of testing and covering all categories of test. The required outcome of each test must be known before the test is attempted. Unit, integration and system testing – configuration items are verified against the appropriate specifications and in accordance with the test plan. The test environment should also be under configuration control and test data and results stored for future evaluation. Test monitoring and assessment – ongoing monitoring and assessment of the integrity of the development and construction. The status of the configuration items should be reviewed against the phase plans and test progress reports prepared providing some assurance of the verification and validation activities. Product assurance – the decision to negotiate the acceptance testing program and the release and commissioning of the service product is subject to the ‘product assurance’ role being satisfied with the outcome of the verification activities. Product assurance may oversee some of the test activity and may participate in process reviews. A common criticism of construction programmers is that insufficient time is frequently allocated to the testing and commissioning of the building systems together with the involvement and subsequent training of the Facilities Management team. Testing and commissioning is often considered by teams as a secondary activity and given a lower priority particularly as pressure builds on the program towards completion. Sufficient time must be dedicated to testing and commissioning as ensuring the systems function correctly is fairly fundamental to the project’s success or failure. Traditionally the responsibility for testing and commissioning is buried deep within the supply chain as a sub-contract of a sub-contract. It is possible to gain greater control of this process and the associated risk through the use of specialists such as Systems Integration who can be appointed as part of the professional team. The time necessary for testing and commissioning will vary from project to project depending upon the complexity of the systems and services that have been installed. The Project Sponsor should ensure that the professional team and the contractor consider realistically how much time is needed. Fitness for purpose checklist: • Is there a documented testing strategy that defines the objectives of all test stages and the techniques that may apply, e.g. non-functional testing and the associated techniques such as performance, stress and security etc? • Does the test plan prescribe the approach to be taken for intended test activities, identifying: • the items to be tested, • the testing to be performed, • test schedules, • resource and facility requirements, • reporting requirements, • evaluation criteria, • risks requiring contingency measures? • Are test processes and practices reviewed regularly to assure that the testing processes continue to meet specific business needs? For example, e-commerce testing may involve new user interfaces and a business focus on usability may mean that the organization must review its testing strategies. 3 Test Strategy Flow : Test Cases and Test Procedures should manifest Test Strategy. Test Strategy – Selection Selection of the Test Strategy is based on the following factors  Product Test Strategy based on the Application to help people and teams of people in making decisions.  Based on the Key Potential Risks  Suggestion of Wrong Ideas.  People will use the Product Incorrectly  Incorrect comparison of scenarios.  Scenarios may be corrupted.  Unable to handle Complex Decisions.  Determination of Actual Risk.  Understand the underlying Algorithm.  Simulate the Algorithm in parallel.  Capability test each major function.  Generate large number of decision scenarios.  Create complex scenarios and compare them.  Review Documentation and Help.  Test for sensitivity to user Error. Test Strategy Execution: Understand the decision Algorithm and generate the parallel decision analyzer using the Perl or Excel that will function as a reference for high volume testing of the app.  Create a means to generate and apply large numbers of decision scenarios to the product. This will be done using the GUI test Automation system or through the direct generation of Decide Right scenario files that would be loaded into the product during test.  Review the Documentation, and the design of the user interface and functionality for its sensitivity to user error.  Test with decision scenarios that are near the limit of complexity allowed by the product  Compare complex scenarios.  Test the product for the risk of silent failures or corruptions in decision analysis.  Issues in Execution of the Test Strategy  The difficulty of understanding and simulating the decision algorithm  The risk of coincidal failure of both the simulation and the product.  The difficulty of automating decision tests 4 General Testing Strategies • Top-down • Bottom-up • Thread testing • Stress testing • Back-to-back testing 5 Need for Test Strategy The objective of testing is to reduce the risks inherent in computer systems. The strategy must address the risks and present a process that can reduce those risks. The system concerns on risks then establish the objectives for the test process. The two components of the testing strategy are the Test Factors and the Test Phase.  Test Factor – The risk or issue that needs to be addressed as part of the test strategy. The strategy will select those factors that need to be addressed in the testing of a specific application system.  Test Phase – The Phase of the systems development life cycle in which testing will occur. Not all the test factors will be applicable to all software systems. The development team will need to select and rank the test factors for the specific software systems being developed. The test phase will vary based on the testing methodology used. For example the test phases in as traditional waterfall life cycle methodology will be much different from the phases in a Rapid Application Development methodology. 6 Developing a Test Strategy The test Strategy will need to be customized for any specific software system. The applicable test factors would be listed as the phases in which the testing must occur. Analysis Coding Errors 36% and design Errors 64% Four test steps must be followed to develop a customized test strategy.  Select and rank Test Factors  Identify the System Developmental Phases  Identify the Business risks associated with the System under Development.  Place risks in the Matrix TestFactors\T est Phase Requirements Design Build Dynamic Test Integrate Maintain 7 Conclusion: Test Strategy should be developed in accordance with the business risks associated with the software when the test team develop the test tactics. Thus the Test team needs to acquire and study the test strategy that should question the following:  What is the relationship of importance among the test factors?  Which of the high level risks are the most significant?  What damage can be done to the business if the software fails to perform correctly?  What damage can be done to the business if the business if the software is not completed on time?  Who are the individuals most knowledgeable in understanding the impact of the identified business risks? Hence the Test Strategy must address the risks and present a process that can reduce those risks. The system accordingly focuses on risks thereby establishes the objectives for the test process. Risks Factors . test strategy. Test Approach /Test Architecture are the acronyms for Test Strategy. Test management is also concerned with both test resource and test environment. Test Strategy Flow : Test Cases and Test Procedures should manifest Test Strategy. Test Strategy – Selection Selection of the Test Strategy is based on