Let us start from the V-Model Verification Phases Requirements analysis System Design Architecture Design Module Design Coding Validation phases Unit Testing Integration Testing System Testing User Acceptance Testing This model helped in realizing that Testing has to be started early in the lifecycle of software development and thus more emphasis was laid on Static Testing during the Verification Phases

Why Test Designing The Quality of Testing is as good as its Test Design Usage of formal and customized Test Specification techniques for deriving Test Cases from the Input Documents (Test Basis) will help in achieving the following:  Proper Coverage/Depth in testing each of the functions (/system)‏  Test Specifications prepared by various members in the test team will be uniform  Test Cases will be more Manageable

Understanding test design techniques Classic distinction – black-box and white box techniques Black box - Black-box techniques (also called specification-based techniques) are a way to derive and select test conditions or test cases based on an analysis of the test basis documentation, whether functional or non-functional, for a component or system without reference to its internal structure. White box - White-box techniques (also called structural or structure-based techniques) are based on an analysis of the internal structure of the component or system. Black BoxWhite Box Tests are derived from functional designed specifications Tests require knowledge of the internal program structure and the code Will fail to test “ hidden” functionsWill fail to detect “missing” functions Data drivenLogic driven testing Requires exhaustive input testing to detect all errors Requires exhaustive Path testing to detect all errors

Categories of test design techniques Requirement based techniques: – Models, either formal or informal, are used for the specification of the problem to be solved, the software or its components. – From these models test cases can be derived systematically. Structure based techniques: – Information about how the software is constructed is used to derive the test cases, for example, code and design. – The extent of coverage of the software can be measured for existing test cases, and further test cases can be derived systematically to increase coverage.

Black Box Testing Methodologies  Equivalence Partitioning  Boundary Value Analysis  Decision Table  Cause Effect Graph  State Transition

Equivalence Partitioning Partitioning the input domain of a program into a finite number of classes [sets], to identify a minimal set of well selected test cases to represent these classes. There are two types of input equivalence classes, valid and invalid. Continuous equivalence classes Discrete equivalence classes Equivalence class testing can significantly reduce the number of test cases that must be created and executed A module for a human resources system that decides how we should process employment applications based on a person's age. 0–15Don't hire 16–17Can hire on a part-time basis only 18–54Can hire as a full-time employee 55–99Don't hire

Equivalence Partitioning continued… Normal Test Cases Test Data If (applicantAge == 0) hireStatus="NO"; 0 If (applicantAge == 1) hireStatus="NO"; 1 … … If (applicantAge == 14) hireStatus="NO"; 14 If (applicantAge == 15) hireStatus="NO"; 15 If (applicantAge == 16) hireStatus="PART"; 16 If (applicantAge == 17) hireStatus="PART"; 17 If (applicantAge == 18) hireStatus="FULL"; 18 If (applicantAge == 19) hireStatus="FULL"; 19 … … If (applicantAge == 53) hireStatus="FULL"; 53 If (applicantAge == 54) hireStatus="FULL"; 54 If (applicantAge == 55) hireStatus="NO"; 55 If (applicantAge == 56) hireStatus="NO"; 56 … … If (applicantAge == 98) hireStatus="NO"; 98 If (applicantAge == 99) hireStatus="NO"; 99 Test Cases using equivalence partition Test Data If (applicantAge >= 0 && applicantAge <=15) hireStatus="NO"; 13 If (applicantAge >= 16 && applicantAge <=17) hireStatus="PART"; 17 If (applicantAge >= 18 && applicantAge <=54) hireStatus="FULL"; 27 If (applicantAge >= 55 && applicantAge <=99) hireStatus="NO"; 75 A group of tests forms an equivalence class : They all test the same thing. If one test catches a bug, the others probably will too within each equivalence class. If one test doesn't catch a bug, the others probably won't either within each equivalence class. Using the equivalence class approach, we have reduced the number of test cases from 100 (testing each age) to four (testing one age in each equivalence class) — a significant savings.

Boundary Value Analysis A selection technique in which test data are chosen to lie along "boundaries“ of the input domain [or output range] classes, data structures, procedure parameters, etc. Choices often include maximum, minimum, and trivial values This technique is often called stress testing. ContinuousDiscrete A module for a human resources system that decides how we should process employment applications based on a person's age. Example A module for a human resources system that decides how we should process employment applications based on a person's age. 0–15Don't hire 16–17Can hire on a part-time basis only 18–54Can hire as a full-time employee 55–99Don't hire What about ages -3 and 101? Note that the requirements do not specify how these values should be treated. We could guess but "guessing the requirements" is not an acceptable practice.

Boundary Value Analysis Continued… If (applicantAge >= 0 && applicantAge <=15) hireStatus="NO"; If (applicantAge >= 16 && applicantAge <=17) hireStatus="PART"; If (applicantAge >= 18 && applicantAge <=54) hireStatus="FULL"; If (applicantAge >= 55 && applicantAge <=99) hireStatus="NO"; The interesting values on or near the boundaries in this example are Test Data S. NoStatementLeft Epsilon Left Extreme InteriorRight Extreme Right Epsilon 1applicantAge >= 0 && applicantAge <= applicantAge >= 16 && applicantAge <= applicantAge >= 18 && applicantAge <= applicantAge >= 55 && applicantAge <= Select the test cases at the “edges” of Equivalence classes in addition to selecting an element in the class

Decision Table A Test criteria to identify which actions should be produced in response to particular combinations of conditions Derive the logic function for the model to validate its completeness and consistency Example - A Bank has the following norms fixed to provide personal loans If age <= 25 and no loan has been taken, loan will be 1 lakh else 2 lakhs If age <= 25 and no. of loans taken is one, loan will be 50 thousands else 1.5 lakhs If age <= 25 and no. of loans taken is two, loan will be 25 thousands else 1 lakh If apply for third loan cancel loan approval process No. of loans already taken AgeLoan AmountApproval Status 0 =26 1 lakh 2 lakhs Yes 1 =26 50 thousands 1.5 lakhs Yes 2 =26 25 thousands 1 lakh Yes 30No, Cancel Loan Decision Variable:Age, No. of loans Actions:Loan Amount, Approval status

Cause Effect Graph A graphical representation of inputs or stimuli (causes) with their associated outputs (effects), which can be used to design test cases. A systematic method of generating test cases representing combinations of conditions. The input and output domains are partitioned into classes and analysis is performed to determine which input classes cause which effect. Example - A Bank has the following norms fixed to provide personal loans If age <= 25 and no loan has been taken, loan will be 1 lakh else 2 lakhs If age <= 25 and no. of loans taken is one, loan will be 50 thousands else 1.5 lakhs If age <= 25 and no. of loans taken is two, loan will be 25 thousands else 1 lakh If apply for third loan cancel loan approval process

Cause Effect Graph Continued…

State Transition A test design technique in which test cases are designed to execute state transitions. Events are caused by input and Actions are likely to cause output Helpful in Web based testing Transitions State 1 State 2 input output Event /Action PTBT UT ST/CB ST/CU Example MS-WORD BT – Bold Text UT – Underlined Text PT – Plain Text ST – Select Text CB – Click Bold CU – Click Underline

Thank You