 Introduction  This strategy designs tests that are independent of the implementation (code) of the software Black-Box Testing

 Introduction  There are two types of black-box tests: 1)FT: Functional Test: tests cases derived from the functional specification of the software. 2)BT: Boundary Test: test cases derived from boundary conditions on input data (or arguments) Black-Box Testing

 Sample A Operation Specification Operation Name: ComputePay Precondition: N/A Narrative: Compute pay for an hourly employee, given the hours worked (Hrs), and hourly pay rate (Rate). Compute overtime at 1.5 times for hours in excess of 40.0.

 Sample A Decision Table Condition Condition c1: Hrs <= 40 Action a1: Pay = Hrs * Rate a2: Pay = Rate*(40+1.5(Hrs-40)) YN X X tc1 tc

 Sample A Test Cases (functional) CONCEPT: Functional test coverage is achieved by designing at least one test case for each column of the decision table. Each column represents a BEHAVIOR of the function. Mathematically, behavior corresponds to an equivalence class defined by the combination of conditions in that column. This combination of conditions forces the function to exhibit this behavior. The test case designed for a column tests the behavior corresponding to the column.

 Sample A Test Cases (functional) [continued] RULE: Design one test case FOR EACH COLUMN

 Sample A Test Script (later)

 Sample B Operation Specification *Enhancement to the specification of ComputePay given in Sample A Operation Name: GrossPay Precondition: 0 <= Hrs <= <= Rate <= 20 Narrative: Compute pay for an hourly employee, given the hours worked (Hrs), and hourly pay rate (Rate). Compute overtime at 1.5 times for hours in excess of Return -1 when Hrs or Rate are invalid.

 Sample B Decision Table Condition c1: Hrs <= 40 c3: Hrs <= 112 c4: Rate >= 5.15 c5: Rate <= Action a1: Pay = Hrs * Rate a2: Pay = 40*Rate + 1.5*(Hrs-40)*Rate a3: Pay = -1 tc1tc2tc3tc4tc5tc6tc7tc8 YNYNYNYN YYN----- YY-N---- YY--NN-- YY----NN X X XXXXXX tc1tc2tc3tc4tc5tc6tc7tc8

 Sample C Test Cases NOTE: Test cases (3-8) test the preconditions.

 Sample C Test Cases [continued] B4: Test Script (N/A)

 BOUNDARY VALUE TESTING INTRODUCTION CONCEPT: Most programming errors occur at or near the values that define the domain of variables that determine the function of a program. The "off-by-one" error is a common programming error. Boundary value testing is driven by the equalities/inequalities which appear in the condition part of the decision table.

 BOUNDARY VALUE TESTING GUIDELINE Suppose you had c: x <= a The boundary values are typically: {OUT, AT, IN}, where OUT means "just outside" the boundary; AT means on the boundary; IN means just inside. a-1a+1 INATOUT(hi) a

 BOUNDARY VALUE TESTING GUIDELINE [continued] The following test cases must be used: c: x <= a, use test cases: IN: x = a-1; AT: x = a; outHI: x = a+1 c: x >= a, use test cases: IN: x = a+1; AT: x = a; outLO: x = a-1

 BOUNDARY VALUE TESTING GUIDELINE [continued] c: x = a, use test cases: AT: x = a; OUTLO: x = a-1; OUTHI = a+1 Note: for equality, there is no IN, so treat "too small" as OUTLO and "too large" as OUTHI. c: x < a, use test cases: IN: x = a-1; outHI: x = a; Note: for strict inequality, there is no AT. c: x > a, use test cases: IN: x = a+1; outLO: x = a;

 BOUNDARY VALUE TESTING GUIDELINE [continued] General Rule for c: x <= a; AT = a IN = a-prec(a) outHI = a+prec(a) where prec(a) is the precision of a. for integers... prec(a) = 1 when 2 decimal places used... prec(a) = 0.01

 BOUNDARY VALUE TESTING BOUNDARY VALUES FOR GrossPay

 BOUNDARY VALUE TESTING BOUNDARY VALUE TEST CASES for GrossPay

 BOUNDARY VALUE TESTING OBSERVATIONS 1.Functional Testing MFT = Min # functional tests cases = #cols in decision table Functional tests augmented by boundary tests BC = 3 * (#condition rows) - (#strict inequalites) 3.Overall # required black box test cases based on decision table: TC= MFT + BC = #columns + 3 * (#condition rows) - (#strict inequality condition rows)

 BOUNDARY VALUE TESTING OBSERVATIONS For GrossPay: #cols = 8 #condition rows = 5 #strict inequalities = 0 TC = 8 + 3*5 = = 23 INSIGHT: Before thinking about cutting corners, suppose your company had 10,000 employees who were paid weekly. In two years, ComputePay is executed 10000*52*2=1,040,000 times, over a MILLION TIMES!! Is 23 test cases too much to make sure GrossPay works correctly??