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

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

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

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.

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

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.

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

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.

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.

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.

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).

Levels of Testing Unit testing Integration Testing System testing

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.

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

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

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.

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.

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

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.

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.

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

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)

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.

(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.

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.

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