1. SOFTWARE TESTING STRATEGIES CIS518001VA016-1114-001: ADVANCED SOFTWARE ENGINEERING TERM PAPER

2. Test strategies that will be presented by this term paper presentation 1. Verification and Validation 2. Unit Testing 3. Integration Testing 4. Top-down Integration 5. Bottom-up Integration 6. Regression Testing 7. Smoke Testing 8. Validation Testing 9. Alpha and Beta Testing 10. System Testing 11. Recovery Testing 12. Security Testing 13. Stress Testing 14. Performance Testing

3. Verification and validation  SQA Activities include: Formal Technical Reviews Quality and configuration audits Performance monitoring Simulation Feasibility studies Documentation reviews Database reviews Algorithm analysis Development testing, qualification testing, and installation testing

4. Unit testing Unit testing and component testing typically focus on individual program elements  that are present in the unit or component. Unit testing tests a small software unit at a time, which is typically performed by the individual programmer who implemented the unit. Unit testing typically focuses on the implementation details and uses white-box testing techniques, with various coverage criteria as the exit criteria. It typically focuses on the executable statements and related control and data elements.

5. Integration testing Integration testing deals with the integration of different product components to work together, with the focus on interface and interaction problems among these components. In integration testing, each component is treated as a black-box, while the interconnections among them are examined and modeled to test component interfaces and interactions. Most of the integration testing uses white-box testing techniques. However, the individual units are no longer individual statements or programming unit, but individual components instead.

6. Top-down integration Top-down approach: This approach moves from the top level of the functional-decomposition tree to the leaves of the tree. A breath-first approach is often used to determine the order of integration. The difficulty of the top-down approach is that when testing a partial group of components, stubs have to be developed separately for components that are not included.

7. Bottom-up integration Bottom-up approach: In contrast to top-down approach, the bottom-up approach starts from the leaves of the functional-decomposition tree and works up towards the top level. Bottom-up approaches do not require stubs but require drivers instead.

8. Regression testing Aimed at ensuring that the modified software still meets the specifications validated before the modification activities. regression testing is the re-execution of some subset of tests that have already been conducted to ensure that changes have not propagated unintended side effects.

9. Smoke testing  The smoke test is used to verify that a successfully installed software application  can be subsequently configured properly. Software components that have been translated into code are integrated into a “build.” A build includes all data files, libraries, reusable modules, and engineered components that are required to implement one or more product functions. A series of tests is designed to expose errors that will keep the build from properly performing its function. The intent should be to uncover “show stopper” errors that have the highest likelihood of throwing the software project behind schedule. The build is integrated with other builds and the entire product (in its current form) is smoke tested daily. The integration approach may be top down or bottom up.

10. Validation testing Validation succeeds when software functions in a manner that can be reasonably expected by the customer. Reasonable expectations are defined in the Software Requirements Specification—a document that describes all user-visible attributes of the software. The specification contains a section called Validation Criteria. Information contained in that section forms the basis for a validation testing approach.

11. Alpha and beta testing During alpha testing, for example, a tester might be tasked with simply recreating and documenting defects reported by members of a separate "alpha testing team," which is usually the company's independent testing (Independent Verification and Validation, or IV&V) team. During beta testing, a tester might be tasked with documenting the beta-test procedures to be executed, in addition to recreating and documenting defects found by other beta testers. (Customers are often recruited to become beta testers.)

12. System testing  System testing and acceptance testing typically focus on the overall operations of the  software system as a whole. System testing is actually a series of different tests whose primary purpose is to fully exercise the computer-based system.

13. Recovery testing  To test backup and recovery processes, you must perform a number of backups,  interrupt the application abnormally, and restore the application using just the  backups. Recovery data are then validated against the expected pre-failure state.  This testing approach seems relatively straightforward and somewhat intuitive.

14. Security testing Security testing attempts to verify that protection mechanisms built into a system will, in fact, protect it from improper penetration. During security testing, the tester plays the role(s) of the individual who desires to penetrate the system. Penetration spans a broad range of activities: hackers who attempt to penetrate systems for sport; disgruntled employees who attempt to penetrate for revenge; dishonest individuals who attempt to penetrate for illicit personal gain.

15. Stress testing  Volume-based performance tracking: Focuses on measuring various throughputs (processing rate) in a system and its components. The basic idea of this method is to insert predefined program throughput tracking code into software components to collect and generate throughput performance traces based on a predefined time interval. During the execution of a component (or system), the volume-based performance tracking code counts the occurrence of a targeted event/transaction/message/operation in software components, and generates a performance trace based on a specified time interval.

16. Performance testing Software performance testing and measurement refers to testing activities and evaluation efforts to validate system performance and measure system capacity.  There are three major objectives: The first is to validate a product to see if the given component and system performance requirements are satisfied. The next is to find out the product capacity and boundary limits. And, the last is to discover the performance issues, degradations, improvements, and bottlenecks of a software system and its components to support performance tuning and problem fixing.