Software Testing Process Overview

The testing and development processes are in a feedback loop. The testing process feeds identified failures back into the development process.

Failure reports provide a set of symptoms that a developer uses to identify the exact location of a fault or error. The development process feeds new and revised designs and implementations into the testing process.

Testing of development products will help identify defective test cases when testers determine that "failures" result from problems with test cases themselves or the drivers that execute them, and not the software under test.

The form and content of development products affect the testing process. When developers select methods and tools, they establish constraints on the testing process. The testing perspective must be considered, preferably by the presence of professional testers, when development methods and tools are selected.

The form and quality of a requirements specification also affects the process. Product requirements comprise the source of test cases in system and acceptance testing. System testers should participate in the gathering and validation of the requirements in order to have a sufficient understanding of them to assess risks and testability.

Three-step approach for each type of testing performed on a project.

1. Analysis:The product to be tested is examined to identify any special features that must receive particular attention and to determine the test cases that should be constructed. We will present a number of analysis techniques.
   

2. Construction: In this phase the artifacts that are needed for testing are created. The test cases identified during analysis are translated into programming languages and scripting languages, or they are entered in a tool-specific language.
   

3. Execution and Evaluation: This is the most visible and often the only recognized part of the test effort; however, it is also typically the quickest part of the test effort. The test cases that were identified during analysis and then constructed are executed. The results are examined to determine whether the software passed the test suite or failed it.

Test Cases and Test Suites

The basic component of testing is a test case. Test case is a pair (input, expected result), in which input is a description of an input to the software under test and expected result is a description of the output that the software should exhibit for the associated input.

Inputs and expected results are not necessarily simple data values, such as strings or integer values, but they can be complex.

Inputs often incorporate system state information as well as user commands and data values to be processed. Expected result includes not only perceivable things, such as printed reports, audible sounds, or changes in a display screen, but changes to the software system itself.

A test case execution is a running of the software that provides the inputs specified in the test case and observes the results and compares them to those specified by the test case. If the actual result varies from the expected result, then a failure has been detected and we say the software under test "fails the test case."

If the actual result is the expected result for a test case, then we say the software "passes the test case."

Test cases are organized into a test suite. Most test suites have some sort of organization based on the kinds of test cases. If software passes all the test cases in a test suite, then we say that the software "passes the test suite."

Software testing other interesting topics:

SOFTWARE TESTING AND EFFECTING FACTORS
SOFTWARE QUALITY ASSURANCE AND CONTROL

SOFTWARE QUALITY AND COST ASPECT

STABLE PROCESS OF SOFTWARE TESTING

STABLE PROCESS OF SOFTWARE TESTING PART TWO

DEFECTS IN SOFTWARE TESTING

REDUCTION OF DEFECTS IN SOFTWARE TESTING

SOFTWARE TESTING AND EFFECTING FACTORS

SCOPE OF SOFTWARE TESTING

TESTING LIFE CYCLE PART ONE

TESTING LIFE CYCLE PART TWO

TESTING LIFE CYCLE PART THREE

SOFTWARE TESTING AND CONSTRAINTS WITH IN IT