2. Test Case
Test case Describes an input Description and an expected output Description.
Test case ID
Section 1: Before execution
Section 2: After execution
Purpose
Execution History
Pre Condition
Result
Inputs
If fails (any Possible Reasons)
Expected Outputs
Any other Observation
Post Conditions
Any Suggestion
Written By
Run By
Date

3. Functional Testing/ Black Box Testing
It involves only observation of the output for certain input values.
There is no attempt To analyse code which produces the output. We ignore internal structure of code.
Therefore it is also known as Black Box Testing.
Input Test Data
System under test
Output Test data

4. Types of FT Boundary Value Analysis Equivalence Class Testing
Decision Table Based Testing

5. Equivalence Class Testing
Input domain is partitioned into finite number of equivalence.
If one test case in class detects errors , all other test cases in the class would be expected to find same errors.
Two steps are required in implement these methods
1- The equivalence classes are identified by taking each input condition and partition it into valid and invalid classes.

6. 2- Generate test cases Using equivalence classes Valid I/P
System Under
Test
Outputs
Invalid Input

7. Decision Table based testing
Decision tables are use to represent and analyse logical relationships.
It is used in situation where a no of combinations of actions are taken under varying sets of conditions.

8. Condi c1
Entry
tion c2
True
False
stub c3 T F -
ACTION a1 X x
Stub a2 a3

9. Structural Testing/ White box testing
It permits to examine internal structure of the program.
If we have checked program against functional tests and no errors are revealed, then further inspection by structural tests revels a piece of code that is not even needed by specifications and hence not examined by functional testing.

10. Path testing
A group of test techniques based on judiciously selecting a set of test paths through the program.
This testing involves
Generating a set of paths that will cover every branch in the program.
Finding a set of test cases that will execute every path in this set of program paths.

11. Flow Graph
Control flow of a program can be analysed using a graphical representation known as flow graph.
It is a directed graph in which nodes are either entire statements and edges represents flow of control.

12. DD path graph Decision to decision path graph
The nodes flow graph which are in a sequence are combines into a single node.
INDEPENDENT PATHS
It is any path through DD path graph that introduces at least processing statements (edge).

13. Levels of Testing
Unit testing
Integration Testing
System testing

14. Unit testing
It is the process of taking the module and running it in isolation from the rest of the software product.
Reason
The size of single module is small enough that we can locate an error fairly easily.

15. Driver routine is used to call the module
Stub replace the module called by the module to be tested.
I/P Parameter Out
Parameter Back
Mark Scaffolding
(codes)
Driver
Test
Module
Stub
Stub
stub

16. Integration Testing Two or more modules
Integration testing checks interface b/w modules
Top down and Bottom up approaches
SYSTEM TESTING
Whole s/w

17. Alpha Testing
It is conducted by developer’s site by customer. These tests are conducted in controlled environment. Beta testing - It is conducted by customers/ users at their sites. It is tested in controlled environment that is not controlled by developer. Customers are expected to report failures reports, developer modify the code and fix the bug and prepare the product for final release.

18. Verification
It is the process of evaluating a system or component to determine whether the products of a given development satisfies the condition imposed at the start of that phase.
Verification is primarily related to manual testing.
Verification activities are applied to early phase of SDLC such as requirement, design, planning etc.

19. Validation
It is a process of evaluating a system or component during or at the end of development process to determine whether it satisfies the specified requirement.
Validation requires actual execution of the program and it is also known as computer based testing.
Testing= verification+validation

20. Regression testing
Regression testing is the process of retesting the modified parts of the s/w and ensuring that no new errors have been introduced into previously tested code.
Development Testing
Regression Testing
We creates test cases
We can make use of existing test cases
We test all s/w component
We retest affected components that have been modified by modifications.
Budget gives time for testing
Budget often does not give time for testing
We perform testing just once on a s/w product
We perform it many times over the life of the s/w product.

21. Debugging Debugging is the activity of locating and correcting errors.
Debugging occurs as a consequence of successful testing.
Symptom may appear in one of a program, while the cause may actually be located in other part.
Symptom may disappear (temporarily) when another error is corrected.

22. Symptom may actually be caused by non errors ( round off)
Symptom may be result in timing problems rather than processing elements.

23. Debugging Strategies Brute force: Let the computer find the error.
Backtracking: source code is traced backward until the site of code is found.
Cause elimination: Induction (device a hypothesis, prove hypothesis ), deduction ( make count of hypothesis, prove remaining hypothesis)

24. Testing Tools Two broad categories of s/w testing tools are:
Static and Dynamic
Static tools: These are the tools that perform analysis of the programs without executing them at all.
(A) Static Analysers: It operates from a pre computed database of descriptive information derived from the source text of the program. It checks whole program.

25. (b) Code Inspectors: who inspect programs automatically to make sure they adhere to minimum quality standards.
(c) Standards enforcers: which impose simple rules on the developer. It will look at single statement.

26. Dynamic Testing tools:
Coverage Analyzers: Which measures the extent of coverage.
Output Comparators: Used to design whether the output in a program is appropriate or not.
Regression testing.
Test file/data generators: Used to set up test inputs.

27. Test harness: used to simplify test operations.
Test archiving systems : used to provide documentation about programs.