Вы находитесь на странице: 1из 6

Definitions of Software Testing

It is the process of Creating, Implementing and Evaluating tests.

Testing measures software quality

Testing can find faults. When they are removed, software quality is improved.

Testing is executing a program with an indent of finding Error/Fault and Failure.

IEEE Terminology : An examination of the behavior of the program by executing on sample data
sets.

Why is Software Testing Important?


1. To discover defects.
2. To avoid user detecting problems
3. To prove that the software has no faults
4. To learn about the reliability of the software.
5. To avoid being sued by customers
6. To ensure that product works as user expected.
7. To stay in business
8. To detect defects early, which helps in reducing the cost of defect fixing?

Why start testing Early?


Introduction :
You probably heard and read in blogs Testing should start early in the life cycle of development". In this
chapter, we will discuss Why start testing Early? very practically.

Fact One
Lets start with the regular software development life cycle:

When project is planned

First weve got a planning phase: needs are expressed, people are contacted, meetings are
booked. Then the decision is made: we are going to do this project.
After that analysis will be done, followed by code build.

Now its your turn: you can start testing.


Do you think this is what is going to happen? Dream on.
This is what's going to happen:

This is what actual happened when the project executes

Planning, analysis and code build will take more time then planned.

That would not be a problem if the total project time would pro-longer. Forget it; it is most likely
that you are going to deal with the fact that you will have to perform the tests in a few days.

The deadline is not going to be moved at all: promises have been made to customers, project
managers are going to lose their bonuses if they deliver later past deadline.
Fact Two
The earlier you find a bug, the cheaper it is to fix it.

Price of Buggy Code

If you are able to find the bug in the requirements determination, it is going to be 50 times cheaper
(!!) than when you find the same bug in testing.
It will even be 100 times cheaper (!!) than when you find the bug after going live.

Easy to understand: if you find the bug in the requirements definitions, all you have to do is change the
text of the requirements. If you find the same bug in final testing, analysis and code build already took
place. Much more effort is done to build something that nobody wanted.
Conclusion: start testing early!
This is what you should do:

Testing should be planned for each phase

Make testing part of each Phase in the software life cycle

Start test planning the moment the project starts

Start finding the bug the moment the requirements are defined

Keep on doing that during analysis and design phase

Make sure testing becomes part of the development process

And make sure all test preparation is done before you start final testing. If you have to start then,
your testing is going to be crap!
Want to know how to do this?
Go to the Functional testing step by step page. (will be added later)

Test Design Techniques


What is Black Box Testing?

Test the correctness of the functionality with the help of Inputs and Outputs.

User doesnt require the knowledge of software code.

Black box testing is also called as Functionality Testing.

Testers make sure that software is working as per the requirements.


It attempts to find errors in the following categories:

Incorrect or missing functions.

Interface errors.

Errors in data structures or external data base access.

Behavior or performance based errors.

Initialization or termination errors.

Methods of Black box Testing

The following basic techniques are employed during black box testing:

Equivalence Class

Boundary Value Analysis

Error Guessing
Equivalence Class:

For each piece of the specification, generate one or more equivalence Class

Label the classes as Valid or Invalid

Generate one test case for each Invalid Equivalence class

Generate a test case that covers as many Valid Equivalence Classes as possible

An input condition for Equivalence Class:

A specific numeric value

A range of values

A set of related values

A Boolean condition
Equivalence classes can be defined using the following guidelines:

If an input condition specifies a range, one valid and two invalid equivalence class are defined.

If an input condition requires a specific value, one valid and two invalid equivalence classes are
defined.

If an input condition specifies a member of a set, one valid and one invalid equivalence classes
are defined.
If an input condition is Boolean, one valid and one invalid classes are defined.
Boundary Value Analysis

Generate test cases for the boundary values.

Minimum Value, Minimum Value + 1, Minimum Value -1

Maximum Value, Maximum Value + 1, Maximum Value - 1


Error Guessing.

Generating test cases against to the specification.

White Box Testing


White Box Testing

Testing the Internal program logic

White box testing is also called as Structural testing.

User does require the knowledge of software code.


Purpose

Testing all loops

Testing Basis paths

Testing conditional statements

Testing data structures

Testing Logic Errors

Testing Incorrect assumptions


Structure = 1 Entry + 1 Exit with certain Constraints, Conditions and Loops.
Logic Errors and incorrect assumptions most are likely to be made while coding for special cases. Need
to ensure these execution paths are tested.
Approaches / Methods / Techniques for White Box Testing
Basic Path Testing (Cyclomatic Complexity(Mc Cabe Method)

Measures the logical complexity of a procedural design.

Provides flow-graph notation to identify independent paths of processing

Once paths are identified - tests can be developed for - loops, conditions

Process guarantees that every statement will get executed at least once.

Structure Testing:

Condition Testing - All logical conditions contained in the program module should be tested.

Data Flow Testing- Selects test paths according to the location of definitions and use of variables.

Loop Testing:

Simple Loops

Nested Loops

Concatenated Loops

Unstructured Loops

Gray Box Testing -

It is just a combination of both Black box & white box testing.

It is platform independent and language independent.

Used to test embedded systems.

Functionality and behavioral parts are tested.

Tester should have the knowledge of both the internals and externals of the function

If you know something about how the product works on the inside, you can test it better from the
outside.
Gray box testing is especially important with Web and Internet applications, because the Internet is built
around loosely integrated components that connect via relatively well-defined interfaces. Unless you
understand the architecture of the Net, your testing will be skin deep.