What is Software Testing
Content
What Is Software Testing?
y It is the process of Creating, Implementing and Evaluating tests. y Testing measures software quality y Testing can find faults. When they are removed, software quality is
improved. y Testing is executing a program with an indent of finding Error/Fault and Failure. y 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 fi xing?
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 Let¶s start with the regular software development life cycle:
When project is planned
y Fi t we e got a planning phase needs are e pressed, people are contacted,
meetings are booked. Then the decision is made we are going to do this project.
y After that analysis will be done, followed by code build. y Now it s 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
y Planning, analysis and code build will take more time then planned. y 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. y 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 wo The earlier you find a bug, the cheaper it is to fi 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 te t 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 testin early! This is what you should do:
Testing should be planned for each phase
y Make testing part of each Phase in the software life cycle y Start test planning the moment the project starts y Start finding the bug the moment the requirements are defined y Keep on doing that during analysis and design phase y Make sure testing becomes part of the development process y 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!
Test Design Techniques
y Black Box Testing y White Box Testing (include its approaches) y Gray Box Testing
Black Box Testing
What is Black Box Testing?
y Test the correctness of the functionality with the help of Inputs and Outputs. y User doesn¶t require the knowledge of software code. y Black box testing is also called as Functionality Testing.
It attempts to find errors in the follo ing categories:
y Incorrect or missing functions. y Interface errors. y Errors in data structures or external data base access. y Behavior or performance based errors. y Initialization or termination errors.
Methods of Black box Testing
The following basic techniques are employed during black box testing:
y Equivalence Class y Boundary Value Analysis y Error Guessing
Equivalence Class:
y For each piece of the specification, generate one or more equivalence Class y Label the classes as ³Valid´ or ³Invalid´ y Generate one test case for each Invalid Equivalence class y Generate a test case that covers as many Valid Equivalence Classes as possible
An input condition for Equivalence Class:
y A specific numeric value y A range of values y A set of related values y A Boolean condition
Equivalence classes can be defined using the following guidelines:
y If an input condition specifies a range, one valid and two invalid equivalence class
are defined. y If an input condition requires a specific value, one valid and two invalid equivalence classes are defined. y If an input condition specifies a member of a set, one valid and one invalid equivalence classes are defined. y If an input condition is Boolean, one valid and one invalid classes are defined. Boundary Value Analysis
y Generate test cases for the boundary values. y Minimum Value, Minimum Value + 1, Minimum Value -1 y Maximum Value, Maximum Value + 1, Maximum Value - 1
Error Guessing.
y Generating test cases against to the specification.
White Box Testing
White Box Testing
y Testing the Internal program logic y White box testing is also called as Structural testing. y User does require the knowledge of software code.
Purpose
y Testing all loops
y Testing Basis paths y Testing conditional statements y Testing data structures y Testing Logic Errors y 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)
y Measures the logical complexity of a procedural design. y Provides flow-graph notation to identify independent paths of processing y Once paths are identified - tests can be developed for - loops, conditions y Process guarantees that every statement will get executed at least once.
Structure Testing:
y Condition Testing - All logical conditions contained in the program module should
be tested. y Data Flow Testing- Selects test paths according to the location of definitions and use of variables. y Loop Testing: y Simple Loops y Nested Loops y Concatenated Loops y Unstructured Loops
Gray Box Testing
Gray Box Testing y It is just a combination of both Black box & white box testing. y It is platform independent and language independent. y Used to test embedded systems. y Functionality and behavioural parts are tested. y Tester should have the knowledge of both the internals and externals of the function y 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.
y It is the process of Creating, Implementing and Evaluating tests. y Testing measures software quality y Testing can find faults. When they are removed, software quality is
improved. y Testing is executing a program with an indent of finding Error/Fault and Failure. y 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 fi xing?
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 Let¶s start with the regular software development life cycle:
When project is planned
y Fi t we e got a planning phase needs are e pressed, people are contacted,
meetings are booked. Then the decision is made we are going to do this project.
y After that analysis will be done, followed by code build. y Now it s 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
y Planning, analysis and code build will take more time then planned. y 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. y 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 wo The earlier you find a bug, the cheaper it is to fi 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 te t 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 testin early! This is what you should do:
Testing should be planned for each phase
y Make testing part of each Phase in the software life cycle y Start test planning the moment the project starts y Start finding the bug the moment the requirements are defined y Keep on doing that during analysis and design phase y Make sure testing becomes part of the development process y 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!
Test Design Techniques
y Black Box Testing y White Box Testing (include its approaches) y Gray Box Testing
Black Box Testing
What is Black Box Testing?
y Test the correctness of the functionality with the help of Inputs and Outputs. y User doesn¶t require the knowledge of software code. y Black box testing is also called as Functionality Testing.
It attempts to find errors in the follo ing categories:
y Incorrect or missing functions. y Interface errors. y Errors in data structures or external data base access. y Behavior or performance based errors. y Initialization or termination errors.
Methods of Black box Testing
The following basic techniques are employed during black box testing:
y Equivalence Class y Boundary Value Analysis y Error Guessing
Equivalence Class:
y For each piece of the specification, generate one or more equivalence Class y Label the classes as ³Valid´ or ³Invalid´ y Generate one test case for each Invalid Equivalence class y Generate a test case that covers as many Valid Equivalence Classes as possible
An input condition for Equivalence Class:
y A specific numeric value y A range of values y A set of related values y A Boolean condition
Equivalence classes can be defined using the following guidelines:
y If an input condition specifies a range, one valid and two invalid equivalence class
are defined. y If an input condition requires a specific value, one valid and two invalid equivalence classes are defined. y If an input condition specifies a member of a set, one valid and one invalid equivalence classes are defined. y If an input condition is Boolean, one valid and one invalid classes are defined. Boundary Value Analysis
y Generate test cases for the boundary values. y Minimum Value, Minimum Value + 1, Minimum Value -1 y Maximum Value, Maximum Value + 1, Maximum Value - 1
Error Guessing.
y Generating test cases against to the specification.
White Box Testing
White Box Testing
y Testing the Internal program logic y White box testing is also called as Structural testing. y User does require the knowledge of software code.
Purpose
y Testing all loops
y Testing Basis paths y Testing conditional statements y Testing data structures y Testing Logic Errors y 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)
y Measures the logical complexity of a procedural design. y Provides flow-graph notation to identify independent paths of processing y Once paths are identified - tests can be developed for - loops, conditions y Process guarantees that every statement will get executed at least once.
Structure Testing:
y Condition Testing - All logical conditions contained in the program module should
be tested. y Data Flow Testing- Selects test paths according to the location of definitions and use of variables. y Loop Testing: y Simple Loops y Nested Loops y Concatenated Loops y Unstructured Loops
Gray Box Testing
Gray Box Testing y It is just a combination of both Black box & white box testing. y It is platform independent and language independent. y Used to test embedded systems. y Functionality and behavioural parts are tested. y Tester should have the knowledge of both the internals and externals of the function y 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.
