"Test Design Techniques"

Test Design
Techniques
by Vladimir Arutin

VLADIMIR ARUTIN
QA ENGINEER
ISTQB® Certified Test Manager
ISTQB and QA Manual
Training Instructor
Certified Coach, Public Speaker
ABOUT MYSELF

WHY DO WE NEED TEST
TECHNIQUES?

COMMON TEST TECHNIQUES
STATIC DYNAMIC
• STRUCTURE-BASED
• SPECIFICATION-BASED
• EXPERIENCE-BASED
• STATIC ANALYSIS
• REVIEWS

SPECIFICATION-BASED
TECHNIQUES

Equivalence Portioning
EQUIVALENCE
PORTIONING
1. Positive tests (clean tests):
– tests based on defined requirements
– tests based on common circumstances
2. Negative tests (dirty tests):
– tests based on errors/defects
– test based on special circumstances

EXAMPLE
A fitness tracker ‘Happy Tester’ measures the number of steps that are walked
each day and provides feedback to encourage the user:
Up to 1000 - Couch Potato!
Above 1000, up to 2000 - Lazy Bones!
Above 2000, up to 4000 - Getting There!
Above 4000, up to 6000 - Not Bad!
Above 6000 - Way to Go!
1000 2000 4000 6000
1001 2001 4001 6001
1. 0-1000
2. 1001-2000
3. 2001-4000
4. 4001-6000
5. 6001- +∞

BOUNDARY VALUES
Step 1: Identify equivalence classes
Step 2: Identify the boundary corresponding to each equivalent class
Step 3: Create test cases for each boundary value by selecting a
point on the boundary.
A B C
I II III IV
TWO-POINT BVA
B-1 B+1

EXAMPLE
50
A speed control and reporting system has the following characteristics:
If you drive 50 km/h or less, nothing will happen.
If you drive faster than 50 km/h, but 55 km/h or less, you will be warned.
If you drive faster than 55 km/h but not more than 60 km/h, you will be fined.
If you drive faster than 60 km/h, your driving license will be suspended.
The speed in km/h is available to the system as an integer value.
Which would be the most likely set of values (km/h) identified by applying the boundary value
analysis, where only the boundary values on the boundaries of the equivalence classes are
relevant?
a) 0, 49, 50, 54, 59, 60.
b) 50, 55, 60.
c) 49, 50, 54, 55, 60, 62.
d) 50, 51, 55, 56, 60, 61.
6055
51 56 61

PAIRWISE TESTING
Divide et impera
REQUIREMENTS
COMPANY: Microsoft, Apple, Samsung, BlackBerry, Xiaomi, Sony
SCREEN: 4.5', 5', 5.2', 5.5', 6', 6.9‘
RESOLUTION: HD, FullHD, 4K
RAM: 2Gb, 3Gb, 4Gb, 6Gb, 8Gb
PROCESSOR MAKE: QS650, MSM8230, QS820, A10, A11
OS: Android, BlackBerry OS, iOS, Windows Phone
NET STANDART: CDMA, GSM, LTE, 3G
STORAGE: 16Gb, 32Gb, 64Gb, 128Gb, 512Gb

PAIRWISE TESTING
REQUIREMENTS
COMPANY: Microsoft, Apple, Samsung, BlackBerry, Xiaomi, Sony
SCREEN: 4.5', 5', 5.2', 5.5', 6', 6.9‘
RESOLUTION: HD, FullHD, 4K
RAM: 2Gb, 3Gb, 4Gb, 6Gb, 8Gb
PROCESSOR MAKE: QS650, MSM8230, QS820, A10, A11
OS: Android, BlackBerry OS, iOS, Windows Phone
NET STANDART: CDMA, GSM, LTE, 3G
STORAGE: 16Gb, 32Gb, 64Gb, 128Gb, 512Gb
MINIMUM TEST AMOUNT
6 x 6 x 3 x 5 x 5 x 4 x 4 x 5 = 216000

PAIRWISE TESTING
COMPANY SCREEN RESOLUTION RAM PROCESSOR
MAKE
OS NET
STANDART
STORAGE
BlackBerry 4.5' HD 8Gb QS650 BlackBerry
OS
LTE 32Gb
Xiaomi 6.9' 4K 2Gb QS650 Android CDMA 512Gb
Sony 5' 4K 3Gb QS820 Android CDMA 128Gb
Microsoft 5.2' FullHD 8Gb MSM8230 Windows
Phone
GSM 128Gb
Samsung 6' 4K 6Gb MSM8230 Android 3G 16Gb
Apple 5.5' 4K 2Gb A11 iOS CDMA 64Gb

MORE TOOLS

DECISION TABLE
CONDITIONS RULE 1 RULE 2 RULE 3 RULE 4
EMAIL
ADDRESS (T/F)
F T T F
PASSWORD
(T/F)
F F T T
OUTPUT (E/M) E E M E
M - Main Page, E - Error

DECISION TABLE
R1 R2 R3 R4 R5
CONDITIONS
User Inserts Valid Card F T T T T
User Enters Valid PIN - F T N T
3 Invalid PINs attempted - F - T -
Sufficient balance for the request - - F - T
ACTIONS
Reject Card Y N N N N
Prompt to Reenter PIN N Y N N N
Eat the Card N N N Y N
Dispense Requested Cash N N N N Y

Type of
coffee
Check
selected
coffee
Start
Money
back
Give
coffee
Wait for
enough
money
STATE TRANSITION
Validation
sum
Select type of
coffee
Enter money
Enough money, with or
w/o change
Enter
money
Not enough
money
Coffee exists
Coffee doesn’t exist

STATE TRANSITION
What is the minimum number of cases we should make for sum validation?
▪ Determine all states.
▪ Consider and prioritize according to requirements all
ways which cover whole functionality.
▪ Identify all transitions.
▪ Create a test case for each way, that covers main
functionality.
▪ Create additional test cases that cover remaining
functionality (if it is needed).
How much times user has to enter money to get enough pay?
FIRST

EACH CHOICE
TESTING
Param1 Param2 Param3
A 1 X
B 2 Y
C 3
4
5
Test
Case
1 A 1 X
2 B 2 Y
3 C 3 X
4 A 4 Y
5 B 5 X

BASE CHOICE TESTING
A 1 X
B 2 Y
C 3 Z
Test Case Param1 Param2 Param3
1 A 2 Y
2 B 2 Y
3 C 2 Y
4 A 1 Y
5 A 3 Y
6 A 2 X
7 A 2 Z

CLASSIFICATION TREE
METHOD
ACCESSING RESOURCES
Platform Agent Protocol
Role Browser
Windows
Mac OS
Unix
User Bot HTTP FTP
Admin Inspector Owner Chrome SafariFireFox
TC1
TC2
TC3
TC4
TC5

SYNTAX TESTING
Backus–Naur form or Backus normal form (BNF) is a notation technique
for context grammar for programming languages, document formats and
communication protocols.

SYNTAX TESTING
After BNF is approved, it is time to generate positive and negative cases:
Positive cases: find possible variants of values allowed by the individual elements
of the BNF definition, and then design cases to simply cover these variants.
Negative cases: define and apply possible mutations (e.g.: missing element,
unwanted extra element, invalid value for an element, and so on) to the
individual elements of the BNF definition.

SCENARIO TESTING
(USE CASE)

SCENARIO TESTING
(USE CASE)
12 Ways to Create Good Scenarios (by Cem Kaner):
1. Write life histories for objects in the system.
2. List possible users, analyze their interests and objectives.
3. Consider disfavored users: how do they want to abuse your system?
4. List “system events.” How does the system handle them?
5. List “special events.” What accommodations does the system make for these?
6. List benefits and create end-to-end tasks to check them.
7. Interview users about famous challenges and failures of the old system.
8. Work alongside users to see how they work and what they do.
9. Read about what systems like this are supposed to do.
10. Study complaints about the predecessor to this system or its competitors.
11. Create a mock business. Treat it as real and process its data.
12. Try converting real-life data from a competing or predecessor application.

SCENARIO TESTING
(USE CASE)
ROLES

RANDOM TESTING
You’ll say it’s useless ‘monkey’ testing and I’ll say
- automate it.
• Random Users (objects)
• Testing validation with random data
• Randomized Behavior
• Fake the database
01. emailTextBx.click();
02. Random randomGenerator = new Random();
03. int randomInt = randomGenerator.nextInt(1000);
04. emailTextBx.sendKeys(“username” + randomInt + “@gmail.com”);

RANDOM TESTING
Sample Program Using
Random Class in Java
01. import java.util.Random;
02. public class RandomTestDataGenerator {
03. public static void main(String[ ] args) {
04. Random r = new Random ();
05. String fullName = “fullName” + r.nextInt();
06. String firstName = “firstName” + r.nextInt();
07. String lastName = “lastName” + r.nextInt();
08. String streetAddress = “address” + r.nextInt();
09. long phoneNumber = (long) (Math.random() * 100000 + 3333000000L);
10. String email = “email” + r.nextInt() + “@gmail.com”;
11. System.out.println (“The Full Name is : “ + fullName);
12. System.out.println (“The First Name is : “ + firstName);
13. System.out.println (“The Last Name is : “ + lastName);
14. System.out.println (“The Address is : “ + streetAddress);
15. System.out.println (“The Phone Number is : “ + phoneNumber);
16. System.out.println (“The Email is : “ + email);
17. }
18. }

RANDOM TESTING
Sample Program using
Faker API in Java
01. java.until.Locale;
02. import com.github.javafaker.Faker;
03. public class FakertestDataGenerator {
04. public static void main(String [ ] args) {
05. Locale locale = new Locale (“en-UKR”);
06. Faker faker = new Faker (locale);
07. String fullName = faker.name().fullName();
08. String firstName = faker.name().firstName();
09. String lastName = faker.name().lastName();
10. String phoneNumber = faker.phoneNumber().phoneNumber();
11. String address = faker.name().streetAddress();
12. String email = faker.internet().emailAddress();
13. System.out.println (“The Full Name is : “ + fullName);
14. System.out.println (“The First Name is : “ + firstName);
15. System.out.println (“The Last Name is : “ + lastName);
16. System.out.println (“The Address is : “ + streetAddress);
17. System.out.println (“The Phone Number is : “ + phoneNumber);
18. System.out.println (“The Email is : “ + email);
19. }
20. }

LCSAJ TESTING
(Linear Code Sequence and Jump)
Characteristics of LCSAJ:
o 100% LCSAJ means 100% Statement Coverage
o 100% LCSAJ means 100% Branch Coverage
o LCSAJ is 100% procedure or Function call Coverage
o 100% Multiple condition Coverage

STATEMENT TESTING
01. if (p = q) {
02. r = r + 1;
03. if (r < 5) {
04. s = 10;
05. }
06. } else if (p > q) {
07. s = 5;
08. }
How many test cases are needed to get
100% statement coverage?
Which combination of p, q and r
values will ensure 100 %
statement coverage?

STATEMENT TESTING
01. if (p = q) {
02. r = r + 1;
03. if (r < 5) {
04. s = 10;
05. }
06. } else if (p > q) {
07. s = 5;
08. }
if
r = r + 1
r < 5
p=q
p>q
s = 10 s = 5
ifif
statement
statement statement
Y
Y Y
N
NN

STATEMENT TESTING
The Matrix has you…
Follow the white rabbit…
Knock knock, Neo.

STATEMENT TESTING
01. if (p = q) {
02. r = r + 1;
03. if (r < 5) {
04. s = 10;
05. }
06. } else if (p > q) {
07. s = 5;
08. }
if
r = r + 1
r < 5
p=q
p>q
s = 10 s = 5
ifif
statement
statement statement
Y
Y Y
N
NN
1 2
2 TEST CASES FOR
STATEMENT COVERAGE
ARE REQUIRED

STATEMENT TESTING
if
“Enough, thanks”
b<35
a+b>40
if
Y N
if a+b > 40 THEN
Print “Enough, thanks”
ENDIF
If b < 35 THEN
Print “Please, add more”
ENDIF
“Please, add more”
Y N
ONLY 1 TEST CASE FOR
STATEMENT COVERAGE
IS REQUIRED

if
b<35
a+b>40
if
Y N
if a+b > 40 THEN
ENDIF
If b < 35 THEN
ENDIF
Y N
1
BRANCH TESTING
2
2 TEST CASES FOR
BRANCH COVERAGE
ARE REQUIRED

Y N
if a+b > 40 THEN
ENDIF
If b < 35 THEN
ENDIF
1 2
PATH COVERAGE
34
a+b>40
b<35
NY
4 TEST CASES FOR
PATH COVERAGE
ARE REQUIRED

01. if ((p == 0)II(q>0)) {
02. r = r + 1;
03. if (r < 5) {
04. s = 10;
05. }
06. } else if (p > q) {
07. s = 5;
08. }
if
r = r + 1
r < 5 p>q
s = 10 s = 5
ifif
Y
Y Y
N
NN
CONDITION COVERAGE
(p == 0)II(q>0)

LOOP COVERAGE
1. main()
2. {
3. int i, n, f;
4. printf (“n = “);
5. scanf (“%d’, &n);
6. if (n <0) {
7. printf (“Invalid: %dn”, n);
8. n = -1;
9. } else {
10. f =1;
11. for (i=1; i<=n; i++) {
12. f*= 1;
13. }
14. printf (“%d! =%dn”, n, f);
15. }
16. return n;
17. }
if
for
TC1 n=0
TC2 n=1
TC3 n=15

CYCLOMATIC COMPLEXITY
Cyclomatic complexity is a software metric used to indicate the
complexity of a program and is a metric for software quality.
M = E − N + 2P,
where
E = the number of edges of the graph.
N = the number of nodes of the graph.
P = the number of connected components.

CYCLOMATIC
COMPLEXITY
EXAMPLE:
M = E − N + 2P
X=14
Y>Z
X=Y X=Z
Print
X, Y, Z
M = 5 − 5 + 2*1
M = 2 life hack
M = If+1

ERRORS GUESSING
• Lessons gained from past releases
• Historical learning
• Past defects
• Production tickets
• Review Checklist
• Application UI
• Past test outcomes
• Risk reports of the application
• An assortment of information utilized for testing.
FAULT ATTACK

ERRORS GUESSING
WHERE ARE
THE ERRORS
HIDING?

EXPLORATORY
TESTING
5 Main Activities:
• Identify the purpose of the product
• Identify functions
• Identify areas of potential instability
• Test each function and record problems
• Design and record a consistency verification test

CHECKLIST-BASED
TESTING

DATA FLOW TESTING
Data Flow testing helps to find:
• A variable that is declared but never used within the program.
• A variable that is used but never declared.
• A variable that is defined multiple times before it is used.
• Deallocating a variable before it is used.

CONTROL FLOW
TESTING define x
use y
kill z
define x
use x
use z
kill z
use x
define z
define y
use z
use y
use z
kill y
define z
Control Flow - the sequence in which
operations are performed during the
execution of a test item.
Example:
~define correct, the normal case
define-use correct, the normal case
use-kill acceptable
use-define acceptable
~use major blunder
define-kill probable programming error
define-define suspicious, perhaps a programming error

REVIEWS
Planning
Define entry/exit criteria
Kick-off
Check entry criteria
Individual preparation
Noting incidents
Review meeting
Examine
Rework
Fixing defects
Follow-up
Check exit criteria

REVIEWS
Informal Walkthrough Technical review Inspection
Documented no yes yes yes
Led by author yes yes no no
Use checklists no optional optional yes
Moderator
(facilitator)
no yes ideally trained trained
Scribe no mandatory mandatory mandatory
Individual
preparation
no optional mandatory mandatory
Reviewers colleague, buddy different people technical experts different experts
Potential defects
logs
may be may be mandatory mandatory

REVIEWS
Advantages:
• Pick things which really count
• Clearly plan and track activities
• Provide training to participants
• Continuously improve the process and tools
• Report results
• Each review has clear objective
• Right people involved
• Atmosphere of trust
• Defects found welcomed and expressed objectively
• Checklists/roles used
• Management support
• Testers welcome as reviewers
• Emphasis on learning and process improvement

DOMAIN TESTING
 EQUIVALENCE PORTIONING
 BOUNDARY VALUES
 PAIRWISE
 DECISION TABLES
 PATH TESTING
 EXPIRIENCE-BASED TESTING
 RISK-BASED TESING

TESTING THROUGHT OVER
TESTING IN THE END

PREVENTING BUGS OVER
FINDING BUGS

TESTING UNDERSTANDING OVER
CHECKING FUNCTIONALITY

BUILDING THE BEST SYSTEM OVER
BREAKING THE SYSTEM

TEAM RESPONSIBILITY FOR QUALITY
OVER TESTER RESPONSIBILITY

"Test Design Techniques"

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à "Test Design Techniques"

Similaire à "Test Design Techniques" (20)

Plus de HYS Enterprise

Plus de HYS Enterprise (20)

Dernier

Dernier (20)

"Test Design Techniques"