software testing introduction. agenda software testing definition software testing objectives...

Software TestingIntroduction

Agenda

• Software Testing Definition

• Software Testing Objectives

• Software Testing Strategies

• Software Test Classifications• According to testing concept• According to requirements

2

Software Testing: Definition

• “Testing is the process of executing a program with intention of finding error”.

• What is Testing? It is a formal process Performed by specialized testing teams Either a unit / integrated units / complete software is

examined By running the programs on a computer Performed by approved test procedures On approved test cases

3

• Formal: Part of the development & quality plan. Included within the

agreement signed by the customer.

• Specialized Teams: Independent teams or external consultants are

hired to perform the task.

They are specialists.

They are unbiased (no favorites)

Results are poor if developers perform themselves

• Running the program: Quality assurance without program execution

is not testing (it can be inspection, walkthrough, review ….)

• Approved test procedures: They should be approved and in-line with

the test plan.

• Approved test cases: Should be defined in the test plan completely.

Nothing should be added or removed from the approved cases.

Software Testing: Definition

4

• Direct Objectives

Identify and reveal as many errors as possible

Make the software of acceptable quality by removing the

errors and retesting.

Perform the test effectively and efficiently within budget and

schedule constraints.

• Indirect Objectives

Compile a record of software errors for use in error prevention

in future.

Software Testing: Objectives

5

• Two basic strategies – common for all test

frameworks

Big-Bang Testing: To test the software the package entirely

once the complete package is available

Incremental Testing: To test the software in modules (unit

tests), then test groups of units integrated with new

components (integration tests). Repeat until the complete

software is done and test again (system tests).

Software Testing: Strategies

6

Top-down Testing: The first module tested is the main module.

The lowest level modules are tested last

Incremental Testing Strategy

7

M11

M9 M10

M8

M6 M7

M1 M2

M3 M4 M5

Integration AIntegration B

Inte

gra

tio

n C

Inte

gra

tio

n D

Stage 1

Stage 2

Stage 3

Stage 4

Stage 5

Stage 6

Bottom-up Testing: The lowest level modules are tested first and

main module is tested last

Incremental Testing Strategy

8

M11

M9 M10

M8

M6 M7M1 M2 M3 M4 M5

Inte

gra

tio

n A

Inte

gra

tio

n B Integration C

Stage 1

Stage 2

Stage 3

Stage 4

• Stubs

Dummy module – If a upper level module is not available (not

yet developed) for testing. Used in botto-up testing.

Software Testing: Strategies

9

M9

M8

M1 M2

Stubs

• Drivers

Dummy module – If a lower level module is not available (not

yet developed) for testing. Used in top-down testing.

Software Testing: Strategies

10

M9

M8

M1 M2

Drivers

• Recommendations

Maintain a library of stubs and drivers – for quick access

Bottom-up strategy

+ Ease of performance

- Lateness – whole program is observed

Top-down strategy

+ Complete program activated after the main module is tested

+ Early identification of analysis and design errors

- Difficult to prepare the stubs

- Difficult to analyze the results of the tests

Software Testing: Strategies

11Finally, depends on the developer which strategy to choose

Big-bang strategy

+ Works well with small and simple programs

- Identification of error is very difficult task

Top-down strategy

+ Easier to find high percentage of errors – unit / integration tests

+ Identification and correction of errors is easier – requires less

resources

- A lot of programming resources are required

- A lot of testing operations required (big-bang has only one)

Software Testing: Strategies

12

Incremental is the preferred to choice

Black-box (functionality) testing

Ignores internal mechanism of the system and is based on the

outputs generated in response to the selected input and conditions.

To evaluate the compliance of a system / component to specified

functional requirements

White-box testing

Internal mechanism is taken into account

Test Classification: Testing Concept

13

McCall Model for Quality Requirements Classification

Test Classification: Requirements

14

1. Output correctness tests

2. Documentation tests

3. Availability (reaction time) tests

4. Reliability tests

5. Stress tests (load tests and durability

tests)

6. Software system security tests

7. Training usability tests

8. Operational usability tests

9. Maintainability tests

10.Flexibility tests

11.Testability tests

12.Portability tests

13.Software interoperability tests

14.Equipment interoperability tests

Correctness

Efficiency

Integrity

Usability

Interoperability