Test Case Design

Software can be tested either by running the programs and verifying each step of its execution against expected results or by statically examining the code or the document against its stated requirement or objective. In general, software testing can be divided into two categories, viz. Static and dynamic testing.

Static testing is a non-execution-based testing and carried through by mostly human effort. In static testing, we test, design, code or any document through inspection, walkthroughs and reviews as discussed in Chapter 2. Many studies show that the single most cost-effective defect reduction process is the classic structural test; the code inspection or walk-through.

Code inspection is like proof reading and developers will be benefited in identifying the typographical errors, logic errors and deviations in styles and standards normally followed.

Dynamic testing is an execution based testing technique. Program must be executed to find the possible errors. Here, the program, module or the entire system is executed(run) and the output is verified against the expected result. Dynamic execution of tests is based on specifications of the program, code and methodology.

White Box Testing

This testing technique takes into account the internal structure of the system or component. The entire source code of the system must be available. This technique is known as white box testing because the complete internal structure and working of the code is available.

White box testing helps to derive test cases to ensure:

1. All independent paths are exercised at least once.

2. All logical decisions are exercised for both true and false paths.

3. All loops are executed at their boundaries and within operational bounds.

4. All internal data structures are exercised to ensure validity.

White box testing helps to:

1. Traverse complicated loop structures

2. Cover common data areas,

3. Cover control structures and sub-routines,

4. Evaluate different execution paths

5. Test the module and integration of many modules

6. Discover logical errors, if any.
7. Helps to understand the code

Why the white box testing is used to test conformance to requirements?

1. Logic errors and incorrect assumptions most likely to be made when coding for "special cases". Need to ensure these execution paths are tested.

2. May find assumptions about execution paths incorrect, and so make design errors. White box testing can find these errors.

3. Typographical errors are random. Just as likely to be on an obscure logical path as on a mainstream path.

RELATED POST


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

QUALITY TESTING

QUALITY ASSURANCE

QUALITY ASSURANCE PART TWO

QUALITY ASSURANCE SQA

QUALITY OF DESIGN OF TEST CASE

QUALITY MANAGEMENT IN SOFTWARE TESTING

TOOLS FOR QUALITY MANAGEMENT

STATICAL QUALITY ASSURANCE

ISO APPROACH TO QUALITY TESTING