SlideShare una empresa de Scribd logo
1 de 22
Agenda
• Need of Test Case Design Techniques
• Test Case Design Techniques classification
• Black box Test Case Design Techniques
• Equivalence Partitioning
• Boundary Value Analysis
• Decision Table
• Error Guessing
• Need of Test Case Design Techniques
Ex: : Impossibility of testing "everything”
int calc (int j)
{
j = j -1; // should be j = j + 1
j = j / 30000;
return j;
}
1. Note that the second line is incorrect!
2. The function calc accepts an integer j, subtracts one from it, divides
it by 30000 (integer division, whole numbers, no remainder) and
returns the value just computed.
3. . If integers are implemented using 16 bits on this computer
executing this software, the lowest possible input value is -32768
and the highest is 32767. Thus there are 65,536 possible inputs into
this tiny program
Continued..
Will you have the time (and the stamina) to create 65,536 test cases?
Of course not. So which input values do we choose? Consider the following input values
and their ability to detect this defect.
Input (j) Expected Result Actual Result
1 0 0
42 0 0
40000 1 1
-64000 -2 -2
Continued..
o Oops! Note that none of the test cases chosen have detected this defect
o In fact only four of the possible 65,536 input values will find this defect.
What is the chance that you will choose all four?
o What is the chance you will choose one of the four?
o What is the chance you will win the lottery?
What is Black box Testing?
Black box testing is a strategy in which testing is based solely on the requirements and
specifications. Unlike its complement, white box testing, black box testing requires no
knowledge of the internal paths, structure, or implementation of the software under test
(SUT).
The general black box testing process is:
The requirements or specifications are analyzed.
Valid inputs are chosen based on the specification to determine that the SUT processes
them correctly. Invalid inputs must also be chosen to verify that the SUT detects them
and handles them properly.
Expected outputs for those inputs are determined.
Tests are constructed with the selected inputs.
The tests are run.
Actual outputs are compared with the expected outputs.
A determination is made as to the proper functioning of the SUT
Test Case design Techniques
classification
Section I - Black Box Testing Techniques
• Equivalence Class Testing
• Boundary Value Analysis
• Decision Table Testing
• Pair wise Testing
• State-Transition Testing
• Domain Analysis Testing
• Use Case Testing
Section11- White Box Testing Techniques
• Control Flow Testing
• Data Flow Testing
• Testing Paradigms
Section 111: Experience based Technique
• Error Guessing
• Exploratory Testing
Boundary Value Testing
Introduction:
Equivalence class testing is the most basic test design technique.
1.It helps testers choose a small subset of possible test cases while maintaining
reasonable coverage.
2. Equivalence class testing has a second benefit. It leads us to the idea of boundary
value testing, the second key test design technique to be presented.
Continued..
1In the previous example the following rules were given that indicate how we should
process employment applications based on a person's age.
The rules were:
0–16
Don't hire
16–18
Can hire on a part-time basis only
18–55
Can hire as a full-time employee
55–99
Don't hire
Notice the problem at the boundaries—the "edges" of each class. The age "16" is
included in two different equivalence classes (as are 18 and 55). The first rule says don't
hire a 16-year-old. The second rule says a 16-year-old can be hired on a part-time basis
Continued..
Key Point : Boundary value testing focuses on the boundaries because that is
where so many defects hide.
If (applicantAge >= 0 && applicantAge <=16) hireStatus="NO"; If (applicantAge >= 16
&& applicantAge <=18) hireStatus="PART"; If (applicantAge >= 18 && applicantAge
<=55) hireStatus="FULL"; If (applicantAge >= 55 && applicantAge <=99)
hireStatus="NO";
`
Of course, the mistake that programmers make is coding inequality tests improperly.
Writing > (greater than) instead of ≥ (greater than or equal) is an example.
The interesting values on or near the boundaries in this example are {-1, 0, 1}, {15, 16,
17}, {17, 18, 19}, {54, 55, 56}, and {98, 99, 100}.
Technique
The steps for using boundary value testing are simple.
Step 1: identify the equivalence classes.
Step 2: identify the boundaries of each equivalence class.
Step 3: create test cases for each boundary value by choosing one point on the
boundary, one point just below the boundary, and one point just above the
boundary. "Below" and "above" are relative terms and depend on the data value's
units.
Ex 1: If the boundary is 16 and the unit is "integer" then the "below" point is 15
and the "above" point is 17.
Ex 2: If the boundary is $5.00 and the unit is "US dollars and cents" then the
below point is $4.99 and the above point is $5.01. On the other hand, if the value
is $5 and the unit is "US dollars" then the below point is $4 and the above point is
$6.
Key Point Create test cases for each boundary value by choosing one point
on the boundary, one point just below the boundary, and one point just
above the boundary.
Summary
•While equivalence class testing is useful, its greatest contribution is to lead us to
boundary value testing.
•Boundary value testing is a technique used to reduce the number of test cases to a
manageable size while still maintaining reasonable coverage.
•Boundary value testing focuses on the boundaries because that is where so many
defects hide. Experienced testers have encountered this situation many times.
•Create test cases for each boundary value by choosing one point on the boundary, one
point just below the boundary, and one point just above the boundary. "Below" and
"above" are relative terms and depend on the data value's units.
Practice
•ZIP Code—five numeric digits.
•First consider ZIP Code just in terms of digits. Then, determine the lowest and
highest legitimate ZIP Codes in the United States. For extra credit [1]
,
determine the format of postal codes for Canada and the lowest and highest
valid values.
•Last Name—one through fifteen characters (including alphabetic characters,
periods, hyphens, apostrophes, spaces, and numbers). For extra credit [2]
create a few very complex Last Names. Can you determine the "rules" for
legitimate Last Names? For additional extra credit [3]
use a phonebook from
another country—try Finland or Thailand.
•User ID—eight characters at least two of which are not alphabetic (numeric,
special, nonprinting).
Decision Table Testing
Decision tables are an excellent tool to capture certain kinds of system
requirements and to document internal system design
They are used to record complex business rules that a system must
implement.
In addition, they can serve as a guide to creating test cases.
Technique
The general form of a decision table
    Rule 1 Rule 2 Rule 3 Rule 4 Rule N
Conditions            
Condition-1            
Condition-2            
Condition-3            
Condition-4            
Condition-N            
             
Actions            
Technique
•Conditions represent various input conditions.
•Actions are the actions that should be taken depending
on the various combinations of input conditions.
• Each of the rules defines a unique combination of
conditions that result in the execution ("firing") of the
actions associated with that rule.
Ex:
•An auto insurance company gives discounts to drivers
who are married and/or good students. Let's begin with
the conditions. The following decision table has two
conditions, each one of which takes on the values Yes
or No.
A decision table with two binary
conditions
 `   Rule 1 Rule 2 Rule 3 Rule 4
Conditions          
Married?    Yes Yes  No No
Good Student?    Yes No Yes No
A decision table with two binary
conditions and Actions
Note that the table contains all combinations of the conditions. Given two binary conditions
(Yes or No), the possible combinations are {Yes, Yes}, {Yes, No}, {No, Yes}, and {No, No}.
Each rule represents one of these combinations.
As a tester we will verify that all combinations of the conditions are defined. Missing
a combination may result in developing a system that may not process a particular
set of inputs properly.
 `   Rule 1 Rule 2 Rule 3 Rule 4
Conditions          
Married?    Yes Yes  No No
Good Student?    Yes No Yes No
Action
Discount ($) 40 25 20 0
Technique
A decision table with non-binary conditions.
 `   Rule 1 Rule 2 Rule 3 Rule 4
Conditions          
Condition 1    0-1 1-10 10-100
10-
1000
Condition 2    <5 5 6 or 7 >7
Action
Action 1 Do X Do A Do Z Do C
Action 2 Do Y Do X Do B Do A
Key Point Create at least one test case for each rule.
If the system under test has complex business rules, and if your
business analysts or designers have not documented these rules in
this form, testers should gather this information and represent it in
decision table form.
The reason is simple. Given the system behavior represented in this
complete and compact form, test cases can be created directly from
the decision table.
In testing, create at least one test case for each rule. If the rule's
conditions are binary, a single test for each combination is probably
sufficient. On the other hand, if a condition is a range of values,
consider testing at both the low and high end of the range. In this way
we merge the ideas of Boundary Value testing with Decision Table
testing.
Key Point Create at least one test case for each rule.
.  A decision table converted to a test case table. 
  Test Case
1 
Test Case
2 
Test Case
3 
Test Case
4 
Inputs         
•Condition
-1
Yes Yes No No
•Condition
-2
Yes No Yes No
         
Expected 
Results 
       
•Action-1 Do X Do Y Do X Do Z
•Action-2 Do A Do B Do B Do B
To create a test case table simply change the row and
column headings
Applicability and Limitations
Decision tables are used to document complex business rules that a system
must implement. In addition, they serve as a guide to creating test cases.
Conditions represent various input conditions.
Actions are the processes that should be executed depending on the various
combinations of input conditions. Each rule defines a unique combination of
conditions that result in the execution ("firing") of the actions associated with
that rule.
Create at least one test case for each rule. If the rule's conditions are binary, a
single test for each combination is probably sufficient. On the other hand, if a
condition is a range of values, consider testing at both the low and high end of
the range.

Más contenido relacionado

La actualidad más candente

Test Driven Development
Test Driven DevelopmentTest Driven Development
Test Driven Development
Dhaval Dalal
 
Unit Testing And Mocking
Unit Testing And MockingUnit Testing And Mocking
Unit Testing And Mocking
Joe Wilson
 

La actualidad más candente (20)

An Introduction to Test Driven Development
An Introduction to Test Driven Development An Introduction to Test Driven Development
An Introduction to Test Driven Development
 
Exploratory Testing Explained
Exploratory Testing ExplainedExploratory Testing Explained
Exploratory Testing Explained
 
Behavior driven development (bdd)
Behavior driven development (bdd)Behavior driven development (bdd)
Behavior driven development (bdd)
 
Unit tests & TDD
Unit tests & TDDUnit tests & TDD
Unit tests & TDD
 
Test Driven Development
Test Driven DevelopmentTest Driven Development
Test Driven Development
 
Bdd Introduction
Bdd IntroductionBdd Introduction
Bdd Introduction
 
Junit 4.0
Junit 4.0Junit 4.0
Junit 4.0
 
Test driven development
Test driven developmentTest driven development
Test driven development
 
Unit Testing And Mocking
Unit Testing And MockingUnit Testing And Mocking
Unit Testing And Mocking
 
Behavior-Driven Development and Automation Testing Using Cucumber Framework W...
Behavior-Driven Development and Automation Testing Using Cucumber Framework W...Behavior-Driven Development and Automation Testing Using Cucumber Framework W...
Behavior-Driven Development and Automation Testing Using Cucumber Framework W...
 
Java Unit Testing
Java Unit TestingJava Unit Testing
Java Unit Testing
 
Test Driven Development (TDD)
Test Driven Development (TDD)Test Driven Development (TDD)
Test Driven Development (TDD)
 
Successfully Implementing BDD in an Agile World
Successfully Implementing BDD in an Agile WorldSuccessfully Implementing BDD in an Agile World
Successfully Implementing BDD in an Agile World
 
Chapter 2 - Testing Throughout the Development LifeCycle
Chapter 2 - Testing Throughout the Development LifeCycleChapter 2 - Testing Throughout the Development LifeCycle
Chapter 2 - Testing Throughout the Development LifeCycle
 
ATDD Using Robot Framework
ATDD Using Robot FrameworkATDD Using Robot Framework
ATDD Using Robot Framework
 
Chapter 6 - Tool Support for Testing
Chapter 6 - Tool Support for TestingChapter 6 - Tool Support for Testing
Chapter 6 - Tool Support for Testing
 
Unit Test
Unit TestUnit Test
Unit Test
 
Junit
JunitJunit
Junit
 
Regression testing
Regression testingRegression testing
Regression testing
 
Writing Test Cases 20110808
Writing Test Cases 20110808Writing Test Cases 20110808
Writing Test Cases 20110808
 

Destacado

Random testing
Random testingRandom testing
Random testing
Can KAYA
 
Cts informatica interview question answers
Cts informatica interview question answersCts informatica interview question answers
Cts informatica interview question answers
Sweta Singh
 
Test Case Design
Test Case DesignTest Case Design
Test Case Design
acatalin
 

Destacado (16)

Fact table design for data ware house
Fact table design for data ware houseFact table design for data ware house
Fact table design for data ware house
 
Informatica interview questions and answers|Informatica Faqs 2014
Informatica interview questions and answers|Informatica Faqs 2014Informatica interview questions and answers|Informatica Faqs 2014
Informatica interview questions and answers|Informatica Faqs 2014
 
Random testing
Random testingRandom testing
Random testing
 
Insurance domain mishra
Insurance domain  mishraInsurance domain  mishra
Insurance domain mishra
 
Test cases
Test casesTest cases
Test cases
 
Cts informatica interview question answers
Cts informatica interview question answersCts informatica interview question answers
Cts informatica interview question answers
 
ETL QA
ETL QAETL QA
ETL QA
 
SQL for ETL Testing
SQL for ETL TestingSQL for ETL Testing
SQL for ETL Testing
 
Test design techniques: Structured and Experienced-based techniques
Test design techniques: Structured and Experienced-based techniquesTest design techniques: Structured and Experienced-based techniques
Test design techniques: Structured and Experienced-based techniques
 
ETL Testing Interview Questions and Answers
ETL Testing Interview Questions and AnswersETL Testing Interview Questions and Answers
ETL Testing Interview Questions and Answers
 
Test Case Design
Test Case DesignTest Case Design
Test Case Design
 
Software Testing Techniques
Software Testing TechniquesSoftware Testing Techniques
Software Testing Techniques
 
Testing techniques
Testing techniquesTesting techniques
Testing techniques
 
Black box & white-box testing technique
Black box & white-box testing techniqueBlack box & white-box testing technique
Black box & white-box testing technique
 
Software testing life cycle
Software testing life cycleSoftware testing life cycle
Software testing life cycle
 
Black Box Testing
Black Box TestingBlack Box Testing
Black Box Testing
 

Similar a Testcase design techniques final

Similar a Testcase design techniques final (20)

blckboxtesting.ppt il.;io'/ ulio'[ yjko8i[0'-p/ yk
blckboxtesting.ppt il.;io'/ ulio'[ yjko8i[0'-p/ ykblckboxtesting.ppt il.;io'/ ulio'[ yjko8i[0'-p/ yk
blckboxtesting.ppt il.;io'/ ulio'[ yjko8i[0'-p/ yk
 
Dynamic Testing
Dynamic TestingDynamic Testing
Dynamic Testing
 
Testing
TestingTesting
Testing
 
Lec 17.pptx
Lec 17.pptxLec 17.pptx
Lec 17.pptx
 
Unit 2 - Test Case Design
Unit 2 - Test Case DesignUnit 2 - Test Case Design
Unit 2 - Test Case Design
 
Testing Fundamentals
Testing FundamentalsTesting Fundamentals
Testing Fundamentals
 
CTFL Module 04
CTFL Module 04CTFL Module 04
CTFL Module 04
 
SE%200-Testing%20(2).pptx
SE%200-Testing%20(2).pptxSE%200-Testing%20(2).pptx
SE%200-Testing%20(2).pptx
 
Shift-Left Testing: QA in a DevOps World by David Laulusa
Shift-Left Testing: QA in a DevOps World by David LaulusaShift-Left Testing: QA in a DevOps World by David Laulusa
Shift-Left Testing: QA in a DevOps World by David Laulusa
 
Software Testing - Test Design Techniques
Software Testing - Test Design TechniquesSoftware Testing - Test Design Techniques
Software Testing - Test Design Techniques
 
Black Box Testing
Black Box TestingBlack Box Testing
Black Box Testing
 
Lesson 2....PPT 1
Lesson 2....PPT 1Lesson 2....PPT 1
Lesson 2....PPT 1
 
Black box testing techniques
Black box testing techniques Black box testing techniques
Black box testing techniques
 
Software Testing Introduction (Part 2)
Software Testing Introduction (Part 2)Software Testing Introduction (Part 2)
Software Testing Introduction (Part 2)
 
ISTQB, ISEB Lecture Notes- 4
ISTQB, ISEB Lecture Notes- 4ISTQB, ISEB Lecture Notes- 4
ISTQB, ISEB Lecture Notes- 4
 
Testing foundations
Testing foundationsTesting foundations
Testing foundations
 
CIS 1403 lab 4 selection
CIS 1403 lab 4 selectionCIS 1403 lab 4 selection
CIS 1403 lab 4 selection
 
Implementing Blackbox Testing
Implementing Blackbox TestingImplementing Blackbox Testing
Implementing Blackbox Testing
 
ch1. .ppt
ch1. .pptch1. .ppt
ch1. .ppt
 
selection.ppt
selection.pptselection.ppt
selection.ppt
 

Último

Cloud Frontiers: A Deep Dive into Serverless Spatial Data and FME
Cloud Frontiers:  A Deep Dive into Serverless Spatial Data and FMECloud Frontiers:  A Deep Dive into Serverless Spatial Data and FME
Cloud Frontiers: A Deep Dive into Serverless Spatial Data and FME
Safe Software
 
Architecting Cloud Native Applications
Architecting Cloud Native ApplicationsArchitecting Cloud Native Applications
Architecting Cloud Native Applications
WSO2
 
Why Teams call analytics are critical to your entire business
Why Teams call analytics are critical to your entire businessWhy Teams call analytics are critical to your entire business
Why Teams call analytics are critical to your entire business
panagenda
 

Último (20)

Strategize a Smooth Tenant-to-tenant Migration and Copilot Takeoff
Strategize a Smooth Tenant-to-tenant Migration and Copilot TakeoffStrategize a Smooth Tenant-to-tenant Migration and Copilot Takeoff
Strategize a Smooth Tenant-to-tenant Migration and Copilot Takeoff
 
AXA XL - Insurer Innovation Award Americas 2024
AXA XL - Insurer Innovation Award Americas 2024AXA XL - Insurer Innovation Award Americas 2024
AXA XL - Insurer Innovation Award Americas 2024
 
How to Troubleshoot Apps for the Modern Connected Worker
How to Troubleshoot Apps for the Modern Connected WorkerHow to Troubleshoot Apps for the Modern Connected Worker
How to Troubleshoot Apps for the Modern Connected Worker
 
DEV meet-up UiPath Document Understanding May 7 2024 Amsterdam
DEV meet-up UiPath Document Understanding May 7 2024 AmsterdamDEV meet-up UiPath Document Understanding May 7 2024 Amsterdam
DEV meet-up UiPath Document Understanding May 7 2024 Amsterdam
 
CNIC Information System with Pakdata Cf In Pakistan
CNIC Information System with Pakdata Cf In PakistanCNIC Information System with Pakdata Cf In Pakistan
CNIC Information System with Pakdata Cf In Pakistan
 
Cloud Frontiers: A Deep Dive into Serverless Spatial Data and FME
Cloud Frontiers:  A Deep Dive into Serverless Spatial Data and FMECloud Frontiers:  A Deep Dive into Serverless Spatial Data and FME
Cloud Frontiers: A Deep Dive into Serverless Spatial Data and FME
 
Architecting Cloud Native Applications
Architecting Cloud Native ApplicationsArchitecting Cloud Native Applications
Architecting Cloud Native Applications
 
MS Copilot expands with MS Graph connectors
MS Copilot expands with MS Graph connectorsMS Copilot expands with MS Graph connectors
MS Copilot expands with MS Graph connectors
 
AWS Community Day CPH - Three problems of Terraform
AWS Community Day CPH - Three problems of TerraformAWS Community Day CPH - Three problems of Terraform
AWS Community Day CPH - Three problems of Terraform
 
Biography Of Angeliki Cooney | Senior Vice President Life Sciences | Albany, ...
Biography Of Angeliki Cooney | Senior Vice President Life Sciences | Albany, ...Biography Of Angeliki Cooney | Senior Vice President Life Sciences | Albany, ...
Biography Of Angeliki Cooney | Senior Vice President Life Sciences | Albany, ...
 
Polkadot JAM Slides - Token2049 - By Dr. Gavin Wood
Polkadot JAM Slides - Token2049 - By Dr. Gavin WoodPolkadot JAM Slides - Token2049 - By Dr. Gavin Wood
Polkadot JAM Slides - Token2049 - By Dr. Gavin Wood
 
Apidays New York 2024 - The value of a flexible API Management solution for O...
Apidays New York 2024 - The value of a flexible API Management solution for O...Apidays New York 2024 - The value of a flexible API Management solution for O...
Apidays New York 2024 - The value of a flexible API Management solution for O...
 
Artificial Intelligence Chap.5 : Uncertainty
Artificial Intelligence Chap.5 : UncertaintyArtificial Intelligence Chap.5 : Uncertainty
Artificial Intelligence Chap.5 : Uncertainty
 
presentation ICT roal in 21st century education
presentation ICT roal in 21st century educationpresentation ICT roal in 21st century education
presentation ICT roal in 21st century education
 
Exploring Multimodal Embeddings with Milvus
Exploring Multimodal Embeddings with MilvusExploring Multimodal Embeddings with Milvus
Exploring Multimodal Embeddings with Milvus
 
Why Teams call analytics are critical to your entire business
Why Teams call analytics are critical to your entire businessWhy Teams call analytics are critical to your entire business
Why Teams call analytics are critical to your entire business
 
EMPOWERMENT TECHNOLOGY GRADE 11 QUARTER 2 REVIEWER
EMPOWERMENT TECHNOLOGY GRADE 11 QUARTER 2 REVIEWEREMPOWERMENT TECHNOLOGY GRADE 11 QUARTER 2 REVIEWER
EMPOWERMENT TECHNOLOGY GRADE 11 QUARTER 2 REVIEWER
 
Navigating the Deluge_ Dubai Floods and the Resilience of Dubai International...
Navigating the Deluge_ Dubai Floods and the Resilience of Dubai International...Navigating the Deluge_ Dubai Floods and the Resilience of Dubai International...
Navigating the Deluge_ Dubai Floods and the Resilience of Dubai International...
 
Manulife - Insurer Transformation Award 2024
Manulife - Insurer Transformation Award 2024Manulife - Insurer Transformation Award 2024
Manulife - Insurer Transformation Award 2024
 
ICT role in 21st century education and its challenges
ICT role in 21st century education and its challengesICT role in 21st century education and its challenges
ICT role in 21st century education and its challenges
 

Testcase design techniques final

  • 1.
  • 2. Agenda • Need of Test Case Design Techniques • Test Case Design Techniques classification • Black box Test Case Design Techniques • Equivalence Partitioning • Boundary Value Analysis • Decision Table • Error Guessing
  • 3. • Need of Test Case Design Techniques Ex: : Impossibility of testing "everything” int calc (int j) { j = j -1; // should be j = j + 1 j = j / 30000; return j; } 1. Note that the second line is incorrect! 2. The function calc accepts an integer j, subtracts one from it, divides it by 30000 (integer division, whole numbers, no remainder) and returns the value just computed. 3. . If integers are implemented using 16 bits on this computer executing this software, the lowest possible input value is -32768 and the highest is 32767. Thus there are 65,536 possible inputs into this tiny program
  • 4. Continued.. Will you have the time (and the stamina) to create 65,536 test cases? Of course not. So which input values do we choose? Consider the following input values and their ability to detect this defect. Input (j) Expected Result Actual Result 1 0 0 42 0 0 40000 1 1 -64000 -2 -2
  • 5. Continued.. o Oops! Note that none of the test cases chosen have detected this defect o In fact only four of the possible 65,536 input values will find this defect. What is the chance that you will choose all four? o What is the chance you will choose one of the four? o What is the chance you will win the lottery?
  • 6. What is Black box Testing? Black box testing is a strategy in which testing is based solely on the requirements and specifications. Unlike its complement, white box testing, black box testing requires no knowledge of the internal paths, structure, or implementation of the software under test (SUT). The general black box testing process is: The requirements or specifications are analyzed. Valid inputs are chosen based on the specification to determine that the SUT processes them correctly. Invalid inputs must also be chosen to verify that the SUT detects them and handles them properly. Expected outputs for those inputs are determined. Tests are constructed with the selected inputs. The tests are run. Actual outputs are compared with the expected outputs. A determination is made as to the proper functioning of the SUT
  • 7. Test Case design Techniques classification Section I - Black Box Testing Techniques • Equivalence Class Testing • Boundary Value Analysis • Decision Table Testing • Pair wise Testing • State-Transition Testing • Domain Analysis Testing • Use Case Testing Section11- White Box Testing Techniques • Control Flow Testing • Data Flow Testing • Testing Paradigms Section 111: Experience based Technique • Error Guessing • Exploratory Testing
  • 8. Boundary Value Testing Introduction: Equivalence class testing is the most basic test design technique. 1.It helps testers choose a small subset of possible test cases while maintaining reasonable coverage. 2. Equivalence class testing has a second benefit. It leads us to the idea of boundary value testing, the second key test design technique to be presented.
  • 9. Continued.. 1In the previous example the following rules were given that indicate how we should process employment applications based on a person's age. The rules were: 0–16 Don't hire 16–18 Can hire on a part-time basis only 18–55 Can hire as a full-time employee 55–99 Don't hire Notice the problem at the boundaries—the "edges" of each class. The age "16" is included in two different equivalence classes (as are 18 and 55). The first rule says don't hire a 16-year-old. The second rule says a 16-year-old can be hired on a part-time basis
  • 10. Continued.. Key Point : Boundary value testing focuses on the boundaries because that is where so many defects hide. If (applicantAge >= 0 && applicantAge <=16) hireStatus="NO"; If (applicantAge >= 16 && applicantAge <=18) hireStatus="PART"; If (applicantAge >= 18 && applicantAge <=55) hireStatus="FULL"; If (applicantAge >= 55 && applicantAge <=99) hireStatus="NO"; ` Of course, the mistake that programmers make is coding inequality tests improperly. Writing > (greater than) instead of ≥ (greater than or equal) is an example. The interesting values on or near the boundaries in this example are {-1, 0, 1}, {15, 16, 17}, {17, 18, 19}, {54, 55, 56}, and {98, 99, 100}.
  • 11. Technique The steps for using boundary value testing are simple. Step 1: identify the equivalence classes. Step 2: identify the boundaries of each equivalence class. Step 3: create test cases for each boundary value by choosing one point on the boundary, one point just below the boundary, and one point just above the boundary. "Below" and "above" are relative terms and depend on the data value's units. Ex 1: If the boundary is 16 and the unit is "integer" then the "below" point is 15 and the "above" point is 17. Ex 2: If the boundary is $5.00 and the unit is "US dollars and cents" then the below point is $4.99 and the above point is $5.01. On the other hand, if the value is $5 and the unit is "US dollars" then the below point is $4 and the above point is $6. Key Point Create test cases for each boundary value by choosing one point on the boundary, one point just below the boundary, and one point just above the boundary.
  • 12. Summary •While equivalence class testing is useful, its greatest contribution is to lead us to boundary value testing. •Boundary value testing is a technique used to reduce the number of test cases to a manageable size while still maintaining reasonable coverage. •Boundary value testing focuses on the boundaries because that is where so many defects hide. Experienced testers have encountered this situation many times. •Create test cases for each boundary value by choosing one point on the boundary, one point just below the boundary, and one point just above the boundary. "Below" and "above" are relative terms and depend on the data value's units.
  • 13. Practice •ZIP Code—five numeric digits. •First consider ZIP Code just in terms of digits. Then, determine the lowest and highest legitimate ZIP Codes in the United States. For extra credit [1] , determine the format of postal codes for Canada and the lowest and highest valid values. •Last Name—one through fifteen characters (including alphabetic characters, periods, hyphens, apostrophes, spaces, and numbers). For extra credit [2] create a few very complex Last Names. Can you determine the "rules" for legitimate Last Names? For additional extra credit [3] use a phonebook from another country—try Finland or Thailand. •User ID—eight characters at least two of which are not alphabetic (numeric, special, nonprinting).
  • 14. Decision Table Testing Decision tables are an excellent tool to capture certain kinds of system requirements and to document internal system design They are used to record complex business rules that a system must implement. In addition, they can serve as a guide to creating test cases.
  • 15. Technique The general form of a decision table     Rule 1 Rule 2 Rule 3 Rule 4 Rule N Conditions             Condition-1             Condition-2             Condition-3             Condition-4             Condition-N                           Actions            
  • 16. Technique •Conditions represent various input conditions. •Actions are the actions that should be taken depending on the various combinations of input conditions. • Each of the rules defines a unique combination of conditions that result in the execution ("firing") of the actions associated with that rule. Ex: •An auto insurance company gives discounts to drivers who are married and/or good students. Let's begin with the conditions. The following decision table has two conditions, each one of which takes on the values Yes or No.
  • 17. A decision table with two binary conditions  `   Rule 1 Rule 2 Rule 3 Rule 4 Conditions           Married?    Yes Yes  No No Good Student?    Yes No Yes No
  • 18. A decision table with two binary conditions and Actions Note that the table contains all combinations of the conditions. Given two binary conditions (Yes or No), the possible combinations are {Yes, Yes}, {Yes, No}, {No, Yes}, and {No, No}. Each rule represents one of these combinations. As a tester we will verify that all combinations of the conditions are defined. Missing a combination may result in developing a system that may not process a particular set of inputs properly.  `   Rule 1 Rule 2 Rule 3 Rule 4 Conditions           Married?    Yes Yes  No No Good Student?    Yes No Yes No Action Discount ($) 40 25 20 0
  • 19. Technique A decision table with non-binary conditions.  `   Rule 1 Rule 2 Rule 3 Rule 4 Conditions           Condition 1    0-1 1-10 10-100 10- 1000 Condition 2    <5 5 6 or 7 >7 Action Action 1 Do X Do A Do Z Do C Action 2 Do Y Do X Do B Do A
  • 20. Key Point Create at least one test case for each rule. If the system under test has complex business rules, and if your business analysts or designers have not documented these rules in this form, testers should gather this information and represent it in decision table form. The reason is simple. Given the system behavior represented in this complete and compact form, test cases can be created directly from the decision table. In testing, create at least one test case for each rule. If the rule's conditions are binary, a single test for each combination is probably sufficient. On the other hand, if a condition is a range of values, consider testing at both the low and high end of the range. In this way we merge the ideas of Boundary Value testing with Decision Table testing. Key Point Create at least one test case for each rule.
  • 21. .  A decision table converted to a test case table.    Test Case 1  Test Case 2  Test Case 3  Test Case 4  Inputs          •Condition -1 Yes Yes No No •Condition -2 Yes No Yes No           Expected  Results          •Action-1 Do X Do Y Do X Do Z •Action-2 Do A Do B Do B Do B To create a test case table simply change the row and column headings
  • 22. Applicability and Limitations Decision tables are used to document complex business rules that a system must implement. In addition, they serve as a guide to creating test cases. Conditions represent various input conditions. Actions are the processes that should be executed depending on the various combinations of input conditions. Each rule defines a unique combination of conditions that result in the execution ("firing") of the actions associated with that rule. Create at least one test case for each rule. If the rule's conditions are binary, a single test for each combination is probably sufficient. On the other hand, if a condition is a range of values, consider testing at both the low and high end of the range.