Test case design techniques (Black box

design)
• 1.Equivalent class Portioning : ECP tech devides the input data into
partitions of equivalent classes and from each class minimum 1 data must
be tested at least once.

• Boundary value analysis :Used to identify errors at boundaries instead of

finding errors in canter of input domain
• Error guessing tech: read SW version ,serial no
• State transition
• Use case
Positive tech
scenarios
Negative scenarios
 SW Qualification

• SW Qualification team uses Dynamic Testing to test Customer

Requirements.
• Dynamic Testing:
• Dynamic testing is software testing technique where testing is carried out with
executing the code.
• Static Testing:
• Static testing is software testing technique where testing is carried out without
executing the code.

June 04, 2020 SW_Qualification_TestDesign_Techniques 2

 Dynamic Testing Techniques
Equivalence
Classes

Methods for deriving test cases​ Boundary

Value Analysis
• Testing techniques help us select a
good set of tests from the total Decision Table
Specification
number of all possible tests for a based
State
given set of requirements. Transition Black-Box
• Different techniques offer different Use Case Categories
ways of looking at the item under test.
Random
• Each technique provides a set of rules
or guidelines for the tester to follow Dynamic Experience
based Error Guessing

in identifying test conditions and test

Exploratory
cases.
Statement

Structure
based Decision
White-Box
Categories
Condition

June 04, 2020 SW_Qualification_TestDesign_Techniques 3

 Requirement based technique
ECU Reset (0x11) Hard reset (01) session supported : Extended session - yes

• Test step:
• 1.Send the diag request as 02 10 03
• 2. Send the diag request as 02 11 01

Expected :
• 1. Verify positive response as follows
• 06 50 03 00 32 01 F4
• 2. Verify positive response as follows
• 02 51 01
 Requirement based technique

• Test step:
• 1.Send the diag request as 02 10 03
• 2.Send the diag request as 02 11 04

Expected result:
• 1.Verify positive response as follows
• 06 50 03 00 32 01 F4
• 2.Verify positive response as follows
• 03 7F 11 12
 Equivalence class

What is Equivalence Class?

Equivalent Class Partitioning is a black box technique (code is not visible
to tester) which can be applied to all levels of testing like unit, integration,
system, etc.
• It divides the input data of software into different equivalence data
classes.
• We can apply this technique, where there is a range in the input field.

Why is Equivalence Class important?

• To reduce large number of test cases to manageable chunks.

• Very clear guidelines on determining test cases without compromising on the effectiveness of testing.
• Appropriate for calculation-intensive applications with many variables/inputs

June 04, 2020 SW_Qualification_TestDesign_Techniques 6

 ECP
Equivalent class partitioning

ECP: input : 18-56

In valid input (<=17) or (>=57)
Test case:
Valid class : 18 -56 (Pick any one input) 18 -30 30 -40 40-56
Invalid : <= 17 25 35 50
Invalid : > = 57

Only accept 18 – 56 values I wont take remaining values

3 integers a b c max range of 10 req - c =a+b

a- 0-10
b- 0-10
c- 0-10

ECP – 0 to 5 and 6 to 10

Test step:
c= a+b (value a is 4 and value b is 6)
C = a+b (value a is 1 and value is 9) = passed
C =a+b (value a is 3 and value b is 8) = Failed

Expected Result:
1. Verify C value should be 10
2. Verify C value should be 10
3. Verify C value should be 10
Observed result :

1. Observed C value as 10 (Passed)

2. Observed C value as 10(Passed)
3. .Observed C value as 11 (Failed)
 M i c ro s o f t
W o rk s h eet
E xcel

Equivalence class

Requirement Description:
Vehicle Speed scenario in Forward Collision Alert [FCA] feature.
If vehicle speed is in between 100 – 200 kmph, FCA_Speed_Enabled = TRUE

Detailed Test Case(s) for the above requirement:

Sl No Vehicle Speed [Kmph] FCA_Speed_Enabled

1 0-99 FCA_Speed_Enabled = False

2 100-200 FCA_Speed_Enabled =True

3 >200 Invalid – We cannot go beyond 200kmph

June 04, 2020 SW_Qualification_TestDesign_Techniques 9

 Boundary Value Analysis

What is Boundary Value Analysis?

• In BVA, validation is performed on edge or boundary of partition as well

as adjacent resolution values of boundary.
• The basic idea in boundary value testing is to select input variable
values at their:
• Minimum
• Just above the minimum
• A nominal value
• Just below the maximum
• Maximum
Why is Boundary Value Analysis important?
• In case of relational operator (< > <= >= == !=) conditions on the edge of equivalence partition classes; probability of making
mistake is more.
• On the edge of boundary value, SW/System behavior is non-deterministic.

June 04, 2020 SW_Qualification_TestDesign_Techniques 10

 BVA
BVA

BVA: input : 18-56 (it includes max, min, inside and outside boundaries)
Test scenario:
Valid input : 18, (18+1), 56, (56-1)
Invalid input : 17 and 57
Test case :
1. Enter the value 17 (18-1) = Invalid
2. Enter the value 18 = Valid
3. Enter the value 19 (18+1) = valid
4. Enter the value 55 (56-1) = valid
5. Enter the value 56 = valid
6. Enter the value (56+1) = Invalid
 19 service test case
Test step:
1.Create fault (Passenger side seat belt)
2. Send the diag request as follows
02 10 03
3. Send the diag request as follows
03 19 02 FF
4. Remove fault
5. Send the diag request as follows
02 10 03
6. Send the diag request as follows
03 19 02 FF
Expected result:
2. Verify positive response as follows
06 50 03 00 32 01 F4
3. Verify positive response as follows
59 02 FF 80 55 12 2F
5. Verify positive response as follows
06 50 03 00 32 01 F4
6. Verify positive response as follows
59 02 FF 80 55 12 2E
3 integers a b c max range of 10 req - c =a+b
A- 0-10
b- 0-10
c- 0-10
BVA: input : 0-10 (it includes max, min, inside and outside boundaries)
Test step:
Test scenario: c= a+b (value a is 0 and value b is 10)
C = a+b (value a is 1 and value is 9)
Valid input : 0, (0+1), 10, (10-1)=9 C =a+b (value a is 1 and value b is 11)

Invalid input : (0-1)=-1 and (10+1)=11 Expected Result:

1. Verify C value should be 10
2. Verify C value should be 10
3. Verify C value should be 10
Observed result :

1. Observed C value as 10 (Passed)

2. Observed C value as 10(passed)
3. Observed C value as 12(failed)
 M i c ro s o f t
W o rk s h eet
E xcel

Boundary Value Analysis

Example Requirement:

June 04, 2020 SW_Qualification_TestDesign_Techniques 14

3 swithces A B C
A,B,C- ON GLOW
Test step : Verify bulb glow or not
Precondition : IGN Bat 12 v there is no fault
expected:

A off B off C off - not glow

A on B off C off- not glow
A off B on C off - not glow
a off B off C on - not glow
A ON B on C off - not glow
A off B on C on - not glow

A on B on C on - Glow
A on B ON C on - Not Glow - Failed

Obsevred result: Verify bulb not glow

2. verify bulb not glow
3, verify bulb not glow
Note : No need to write all test cases one positive & Negative scenarios enough
State transition technique
Default to programming
Test step:
1.Send the diag request as 02 10 01
2. Send the diag request as 02 10 02

Expected :
1. Verify positive response as follows
06 50 01 00 32 01 F4
2. Verify positive response as follows
06 50 02 00 32 01 F4
 Decision Table
M i c ro s o f t E xcel
W o rk s h eet

Example: Test Cases using Decision Table Technique

Decision table

Condition monitoring Trigger

Requirement Description
PDM Trigger: The DDSM shall trigger recording of Power Door signals when Ignition_Status = Run AND any of the following CAN Signals
indicating operation of the power doors.
DrMtnFl_D_Stat = 0x1 Opening or 0x2 Closing OR
SldrlMtn_D_Stat = 0x1 Opening or 0x2 Closing OR
DrMtnFr_D_Stat = 0x1 Opening or 0x2 Closing OR
SldrrMtn_D_Stat = 0x1 Opening or 0x2 Closing OR
DrTGate_D_Rq = 0x1 Opening or 0x2 Closing

Test Case Scenarios

Req. ID Sr. No. Input Condition
TC1 TC2 TC3 TC4 TC5 TC6 TC7 TC8 TC9 TC10 TC11 TC12 TC13 TC14 TC15 TC16 TC17 TC18
Start OFF Accessory Invalid Unknown Unused Run Run Run Run Run Run Run Run Run Run Run Run
1 Ignition Status
(0x8) (0x01) (0x2) (0xF) (0x0) (0x03) (0x4) (0x4) (0x4) (0x4) (0x4) (0x4) (0x4) (0x4) (0x4) (0x4) (0x4) (0x4)
2 DrMtnFl_D_Stat 1 1 1 1 1 1 1 0 0 0 0 2 0 0 0 0 3 0
3 SldrlMtn_D_Stat 1 1 1 1 1 1 0 1 0 0 0 0 2 0 0 0 3 0
R_CMP_CM 4 DrMtnFr_D_Stat 1 1 1 1 1 1 0 0 1 0 0 0 0 2 0 0 3 0
Trg_00014 5 SldrrMtn_D_Stat 1 1 1 1 1 1 0 0 0 1 0 0 0 0 2 0 3 0
6 DrTGate_D_Rq 1 1 1 1 1 1 0 0 0 0 1 0 0 0 0 2 3 0
Sr. No. Expected Output D1 D2 D3 D4 D5 D6 D7 D8 D9 D10 D11 D12 D13 D14 D15 D16 D17 D18
1 Trigger initiated Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes
2 Trigger Not initiated Yes Yes Yes Yes Yes Yes Yes Yes

Interpretation:
• In each test case each condition is set (as per each column TCx) and checked for the decision outcome as per Dx (Yes/No).
• The number of possible combinations as per number of variables is (2^6)+14+(2*5) = 88 Test cases.
• Decision table can be enhanced further by adding more requirements and system conditions like Fault -- No Fault, Low Voltage – High Voltage and so on as per individual project.
• Wherever possible make simpler decision table as much as simpler possible without compromising on test coverage
June 04, 2020 SW_Qualification_TestDesign_Techniques 18