Beruflich Dokumente
Kultur Dokumente
Testing can find faults. When they are removed, software quality is improved.
IEEE Terminology : An examination of the behavior of the program by executing on sample data
sets.
Fact One
Lets start with the regular software development life cycle:
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.
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.
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:
Start finding the bug the moment the requirements are defined
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 the correctness of the functionality with the help of Inputs and Outputs.
Interface errors.
The following basic techniques are employed during black box testing:
Equivalence Class
Error Guessing
Equivalence Class:
For each piece of the specification, generate one or more equivalence Class
Generate a test case that covers as many Valid Equivalence Classes as possible
A range of 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
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
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.