Step methdology

The Systematic test and evaluation process (STEP)was first introduced in 1985 as part of the course material for the Systematic software testing seminar series .it has since been revised many times and field tested through consulting engagements and the shared experience of many individuals and organizations. STEP is built upon the foundation of the IEEE std. 829-1983 Standard for software Test Documentation and subsequently updated based on the latest vesion (IEEE std.828-1998) of this standard and the IEEE std. 1008-1987 Standard for software Unit testing . While retaining compatiability with these standards,this methodology has grown in scope and now stands as one of the leading models for effective software testing throughout the industry.

SCOPE and objectives of STEP

STEP covers the broad activity of software evaluation Evaluation is defined as that sub discipline of software engineering concerned with determining whether software products do what they are supposed to do .The major techniques employed in evaluation are analysis , review and test. STEP focuses on testing as the most complex and planning of all aspects of evaluation as a key to success . it stesses the prevention of potential of testing,with defect detection and demonstration of capability as secondary goals.

Early views saw testing as phase that occurred after software development ,or something that programmers did to get the bugs out of their programs. The more modern view sees testing as a process to be performed in parallel with the software development or maintenance effort (refer to figure 1-2) incorporating the activities of planning (determining risks and selecting strategies); analysis (setting test objectives and requirements); design (specifying tests to be developed); implementation (constructing or acquiring the test procedures and cases); execution (running and rerunning the tests); and maintenance (saving and updating the tests as the software changes).

EARLY VIEW Build Test

MODERN VIEW
Build\Rebuild Test

This lifecycle perspective of testing represents a major change from just a few years ago ,when many equated testing with executing tests. The contribution of planning ,analyzing and designing tests was under-recognized

(and still is by many people)and testing was not seen as really starting until tests started running.Now we understand the evaluation power of test planning and analysis. These activities can be more powerful than test execution in defect prevention and timely detection .We also understand that an accurate interpretation of the situation when all running successfully requires a clear understanding of the test design.

The lifecycle model for testing that has emerged borrows heavily from the methodology weve grown accustomed to for software. Considering that a test set is made up of data and procedures (which are often implemented as executable test programs) ,it should not come as a surprise that what it takes to build good software is also what it takes to build good testware!

Elements of STEP
STEP draws from established foundation of software methodologies to provide a process model for software testing. The methodology consists of specified tasks (individual actions); work products (documentation and implemented tests); and roles (defined responsibilities associated with groups of tasks )as shown in Figure 1-3 ,packaged into a system with proven effectiveness for consistently achieving quality software.

Roles

Phases

Work products

Plan
Manager

strategy

Documentation

Analyst

Procedures

Acquire
Techniciation

Testware

Data

Reviewer

Measure Behavior

support software

Figure 1-3 Elements of STEP

The STEP methodology is not tool dependent and does not assume any particular test organization or staffing(such as independent test groups).it does assume a development (not a research )effort , where the requirements information for the product and the technical design information are comprehensible and available for use as inputs to testing. Even if the requirements and design are not specified, much of the STEP methodology can still be used and can, in fact, facilitate the analysis and specification of software requirements and design.

STEP Architecture
Figure1-4 shows how STEP assumes that the total testing job is divided into levels during planning . A level represents a particular testin environment(e.g. ,unit testing usually refers to the level associated with program testing in a programmers personal development library). Simple projects,such as minor enhancements,may consist of just one or two levels of testing (e.g. ,unit and acceptance).Complex projects ,such as a new product development ,may have more levels (e.g. ,unit, function, subsystem,system,acceptance,alpha ,beta,etc.).

Project Testing
Levels * * Phases *

Level n

* * *

PLAN
* * Activities *

Acquire

Measure
* * *

Analyze
Tasks

Design

Implement

Task Figure 1-4 Activities Timing At each level of test * * *

Task * * *

Task * * *

STEP provides a model that can be used as a starting point in establishing a detailed test plan. All of the components of the model are intended to be tailored and revised, or extended to fit each particular test situation . The three major phases in STEP that are employed at every level include: planning the strategy(selecting strategy and specifying levels and approach), acquiring the testware(specifying detailed test objectives,designing and implementing test sets),and measuring the behavior (executing the tests and evaluating the software and the process). The phases are further broken down into eight major activites,as shown in Table 1-3.

Table 1-3 STEP Activities & Their Locations in This Book

Timing of STEP Activities

STEP specifies when the testing activities and tasks are to be performed ,as well as what the tasks should be and their sequence,as shown in Figure 1-5. The timing emphasis is based on getting most of the design work completed before the detailed design of software .The trigger for beginning the test design work is an external , functional , or black box specification of the software component to be tested. For higher test levels(e.g.,acceptance or system),the external specification is equivalent to the system requirements document. As soon as that document is available ,work can(and should) begin on the design of the requirements-based tests.
Project Plan Requirement Specification Architectural Detailed Implementation Design Design Figure1-5 Activities timing at

Various level of test

Acceptance Testing Master Test Planning And Methdology Standards Guidelines Plan detail
Plan Detail

Acquire

Measure

System Testing Acquire Measure

Integration\Build Testing
Plan Detail Acquire Measure

The test design process continues as the software is being designed and additional tests based on the detailed design of the software are identified and added to the requirements-based tests. As the software design process proceeds , detailed design documents are produced for the various software components and modules comprising the system. These in turn, serve as functional specifications for the component of module , and thus may be used to trigger the development of requirements-based tests at the component or module level. As the software project moves to the code and implementation details.

The inventory and design activities at the various levels overlap. The goal at each level is to complete the bulk of test design

STEP also requires careful and systematic development of requirements and design-based coverage inventories and for the resulting test design to be calibrated to these inventories. The result is that in STEP, the test coverage is known and measured(at least with respect to listed inventories).Prevalent practice largely ignores the issue of coverage measurement and often results in ad hoc or unknown coverage.

A final major difference lies in visibility of the full testing process. Every activity in STEP leads to visible work products. From plans, to inventories ,to test design , to test specs, to test sets, to test reports, the process is visible and controlled. Industry practice provides much less visibility ,with little or no systematic evaluation of intermediate products.

These difference are significant and not necessarily easy to put into practice . However, the benefits are equally significant and well worth the difficulty and investment.