SOFTWARE TETING STATAGIES

A strategy for software testing integrates software test case design methods into a well-planned series of steps that result in the successful construction of software. The strategy provides a road map that describe the steps to be conducted as part of testing, when these steps are planned and then undertaken, and how much effort, time, and resources will be required. Therefore, any testing strategy must incorporate test planning, test case design, test execution, and resultant data collection and evaluation.

A software testing strategy should be flexible enough to promote a customized testing approach. At the same time, it must be rigid enough to promote reasonable planning and management tracking as the project progresses.

In many ways, testing is an individualistic process, and the number of different types of tests varies as much as the different development approaches. For many years, our only defense against programming errors was careful design and the native intelligence of the programmer. We are now in an era in which modern design techniques [and formal technical reviews] are helping us to reduce the number of initial errors that are inherent in the code. Similarly, different test methods are beginning to cluster themselves into several distinct approaches and philosophies.

What is it?

Designing effective test cases is important, but so is the strategy you use to execute them. Should you develop a formal plan for your tests? Should you test the entire program as a whole or run tests only on a small part of it? Should you rerun tests you’ve already conducted as you add new components to a large system? When should you involve the customer? These and many other questions are answered when you develop a software testing strategy.

Why is it important?

Testing often accounts for more project effort than any other software engineering activity, If it is conducted haphazardly, time is wasted, unnecessary effort is expended, and even worse, errors sneak through undetected. It would therefore seem reasonable to establish a systematic strategy for testing software. What are the steps? Testing begins “in the small” and progresses “to the large.”

By this we mean that early testing focuses on a single component and applies white- and black-box tests to uncover errors in program logic and function. After individual components are tested they must be integrated, Testing continues as the software is constructed. Finally, a series of nigh-order tests are executed once the full program is operational. These tests are designed to uncover errors in requirements.

What is the work product?

A Test Specification documents the software team’s approach to testing by defining a plan that describes an overall strategy and a procedure that defines specific testing steps and the tests that will be conducted.

How do I ensure that I’ve done it right?

By reviewing the Test Specification prior to testing, you can assess the completeness of test cases and testing tasks. An effective test plan and procedure will lead to the orderly construction of the software and the discovery of errors at each stage in the construction process.

These "approaches and philosophies" are what we shall call strategy. In Chapter 17, the technology of software testing was presented.1 In this chapter, we focus our attention on the strategy for software testing.

A STRATEGIC APPROACH TO SOFTWARE TESTING:

Testing is a set of activities that can be planned in advance and conducted systematically. For this reason a template for software testing—a set of steps into which we can place specific test case design techniques and testing methods—should be defined for the software process.

A number of software testing strategies have been proposed in the literature. All provide the software developer with a template for testing and all have the following generic characteristics:

• Testing begins at the component level and works "outward" toward the integration of the entire computer-based system.

• Different testing techniques are appropriate at different points in time.

• Testing is conducted by the developer of the software and (for large projects) an independent test group.

• Testing and debugging are different activities, but debugging must be accommodated in any testing strategy.

A strategy for software testing must accommodate low-level tests that are necessary to verify that a small source code segment has been correctly implemented as well as high-level tests that validate major system functions against customer requirements. A strategy must provide guidance for

the practitioner and a set of milestones for the manager. Because the steps of the test strategy occur at a time when dead line pressure begins to rise, progress mjust be measurable and problems must surface as early as possible.

For object-oriented systems, testing begins at the class or object level.

RELATED POST

UNIT TESTING PART ONE

UNIT TESTING PART TWO

UNIT TESTING PART THREE

GUI TESTING

WINDOWS COMPLIANCE GUI TESTING PART ONE

WINDOWS COMPLIANCE GUI TESTING PART TWO

WINDOWS COMPLIANCE GUI TESTING PART THREE

WINDOWS COMPLIANCE GUI TESTING PART FOUR VALIDATION TESTING

WINDOWS COMPLIANCE GUI TESTING PART FIVE CONDITION TESTING

WINDOWS COMPLIANCE GUI TESTING PART SIX GENERAL CONDITION TESTING

CONDITION TESTING

TESTING CONDITIONS PART ONE

TESTING CONDITIONS PART TWO

TESTING CONDITIONS PART THREE

TESTING CONDITIONS PART FOUR

SPECIFIC FIELD TESTING

USABILITY TESTING

INTEGRATION TESTING

INTEGRATION TESTING PART ONE

INTEGRATION TESTING PART TWO

INTEGRATION TESTING PART THREE

INTEGRATION TESTING PART FOUR

INTEGRATION TESTING PART FIVE

INTEGRATION TEST STANDARDS

INTEGRATION TEST STANDARDS PART TWO

No comments:

Post a Comment