SOFTWARE TESTINGSTRATEGIESCIS518001VA016-1114-001: ADVANCED SOFTWARE ENGINEERING

TERM PAPER

Test strategies that will be presented by this term paper presentation1. 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

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

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.

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.

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.

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.

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.

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.

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.

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.)

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.

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.

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.

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.

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.