Blackbox Testing Equivalence Partitioning The ATM Simulation System

Blackbox Testing Equivalence Partitioning: The ATM Simulation System

Software Testing Process of executing a program aiming to reveal defects or, failing in this objective, to increase the confidence that the program is correct. z“The” Testing Quote Testing cannot show the absence of defects, it can only show that software defects are present. We cannot test quality into a product, we have to design it in.

Test Objectives y. Tests intended to find errors y. Good test cases have high probability for finding a yet undiscovered error y. Successful tests cause program failure, i. e. find an undiscovered error y. Minimal set of test cases needs to be developed x. Exhaustive testing (test the program with all possible values of input data) is not possible!!

Where does testing fit in? LEVEL 0: Testing == Debugging LEVEL 1: Testing shows the software works LEVEL 2: Testing shows the software doesn’t work LEVEL 3: Testing doesn’t prove anything, it reduces risk of unacceptable software delivery LEVEL 4: Testing is not an act, but a mental discipline of quality

Terminology z Test Case y. Specification of an input of the program and its correspondent expected result z Test Suite y Set of test cases z Testing Criterion y. Systematic way to generate test cases and/or evaluate their effectiveness in revealing errors y. Based upon a testing technique

Testing “Joe the Box” zjoe’s size is 50 z. What would happen if we made: yjoe grow: -60 (try it three times!!) z. If we found no errors: High-quality software? ? ? Low-quality testing? ? ?

Test Activities z Planning z Test Case Design z Test Case Execution z Result Analysis

Testing Techniques z Functional – Blackbox Testing y. Uses the functional requirements (specification) to derive test cases x. Equivalence Partitioning, Partitioning Boundary Value Analysis z Structural – Whitebox Testing y. Uses the internal structure of the program (implementation details) to derive test cases x. Control-flow, Data-flow z Error-Based y. Uses information about the most common errors committed during the software development process x. Mutation Analysis

Equivalence Partitioning z Divide input domain into classes of data y. Equivalence classes z Single test case can cover all “equivalent” data elements z Partitions consist of valid and invalid sets z Equivalence Class y. A set of valid or invalid states for input conditions x. Input Condition: usually a sentence or a clause from the specification

ATM Simulation System z Specification (simplified) y The customer will be required to enter the account number and a PIN. x There is no need of an ATM card. y The ATM must provide the following transactions to the customer: x Cash Withdrawals, Deposits, Tranfers and Balance Inquiries. x Only one transaction will be allowed in each session. y The ATM will communicate the transaction to the bank and obtain verification that it was allowed by the bank. x If the bank determines that account number or PIN is invalid, the transaction is canceled. y The ATM will have an operator panel that will allow an operator to start and stop the servicing of customers. x When the machine is shut down, the operator may remove deposit envelopes and reload the machine with cash. x The operator will be required to enter the total cash on hand before starting the system from this panel.

ATM Simulation System z Classes ATM Operator. Panel Withdrawal. Transaction Inquiry. Transaction Cash. Dispenser Session Deposit. Transaction Bank z Some Scenarios y System Startup y Session y Cash Withdrawal Transaction y Deposit Transaction y Transfer Transaction y Balance Inquiry z CRC Cards. . . Envelope. Acceptor Transaction Transfer. Transaction

Defining Input Conditions Analyse the scenarios and the set of responsibilities for each class/CRC card. 1. 1. Consider the responsibilities in a macroscopic way. • Focus on what each class really has to do. 1. 2. Look for the input data provided by the user. • Analyse the responsibilities of the collaborators and of the other classes too. – Sometimes the input data are, in fact, being treated by some of the collaborators. 1. 3. Write down all the input data for the CRC you are analysing.

CRC Cards z Class: ATM Responsibility - Collaborator Start up system operation (initial cash) Operator. Panel Start a session for each customer Session Shut down on operator request Operator. Panel Get PIN from the customer Get transaction choice from the customer Get account from the customer Get amount entry from the customer (Class xxx. Transaction) Verify the availability of cash for withdrawal Cash. Dispenser Dispense cash Cash. Dispenser Accept deposit envelope Envelope. Acceptor

CRC Cards z Class: Cash. Dispenser Responsibility - Collaborator Set initial cash on hand at startup (Operator Panel) Report cash available Dispense cash z Class: Envelope. Acceptor Responsibility - Collaborator Accept deposit envelope z Class: Operator. Panel Responsibility - Get initial cash on hand from operator Collaborator

CRC Cards z Class: Session Responsibility Collaborator - ATM, Transaction ATM, Bank Perform session use case Perform invalid data Furnish account to Transaction Furnish PIN to Transaction z Class: Transaction Responsibility Collaborator - Withdrawal. Transaction, Deposit. Transaction, Transfer. Transaction, Inquiry. Transaction, Session, Bank Perform a particular transaction use case

CRC Cards z Class: Withdrawal. Transaction Responsibility Collaborator - ATM Session, Bank ATM, Bank Get specifics from customer Send to bank Dispense cash and notify bank when complete z Class: Deposit. Transaction Responsibility Collaborator - ATM Session, Bank ATM, Bank Get specifics from customer Send to bank Accept envelope and notify bank when complete z Class: Transfer. Transaction Responsibility Collaborator - ATM Session, Bank Get specifics from customer Send to bank

CRC Cards z Class: Inquiry. Transaction Responsibility Collaborator - ATM Session, Bank Get specifics from customer Send to bank z Class: Bank Responsibility - Initiate withdrawal Finish withdrawal Initiate deposit Finish deposit Do transfer Do inquiry Collaborator

Defining Input Conditions z Input Data y. Class ATM: account, PIN, transaction y. Class Operator. Panel: initial cash y. Class Withdrawal. Transaction: amount y. Class Deposit. Transaction: amount y. Class Transfer. Transaction: receiver account, amount

Defining Input Conditions 2. Identify the main characteristics of each input data you found. 3. Identify the “interactions” among the input data. 3. 1. Think about how a specific input can be related to the other inputs of the system. • Focus on the system’s operation. • Scenarios can help you. Input Conditions !!!

Defining Input Conditions y. Class ATM xaccount • matching with bank x. PIN • matching with account xtransaction • type y. Class Operator. Panel xinitial cash • valid characters • availability of money in cash dispenser

Defining Input Conditions y Class Withdrawal. Transaction xamount • valid characters • availability of money in the account for withdrawal y Class Deposit. Transaction xamount • valid characters y Class Transfer. Transaction xreceiver account • matching with bank xamount • valid values • availability of money in the sender account for transfer

Identifying Equivalence Classes 1. Analyse each input condition you defined. 1. 1. Think about the valid values to satisfy the input condition. If necessary, refine the input condition into more details. x. They will correspond to the elements of a Valid Equivalence Class 1. 2. Think about other possible values associated to the input condition – invalid values. x. They will correspond to the elements of a Invalid Equivalence Class 2. Enumerate each equivalence class. y Assign a unique number to each class.

Identifying Equivalence Classes Class ATM Input Condition Valid Invalid account matches with bank size (a) of account a = 8 (1) a > 8 (2) 0 a < 8 (3) alpha, special (5) valid characters for account PIN matches with account size (p) of PIN valid characters for PIN type of transaction numerical (4) p = 4 (6) numerical (9) withdrawal (11) deposit (12) transfer (13) inquiry (14) p > 4 (7) 0 p < 4 (8) alpha, special (10) none (“blank choice”) (15)

Identifying Equivalence Classes Class Withdrawal. Transaction Input Condition Valid valid characters for amount numerical (1) Invalid alpha, special (2) availability of money in the account for withdrawal balance - amount 0 (3) balance - amount < 0 (4)

Defining the Test Cases 1. Derive test cases associated with valid classes to cover all of them x. A test case should cover a number of valid equivalence classes, as large as possible 2. Derive test cases associated with invalid classes to cover all of them x. A test case should be written for each invalid equivalence class 3. Write a “specification” for your test cases 4. Write “the” test cases

Defining the Test Cases z Example of a “specification” for a test case Class Equivalence Class # Test Case Expected Result Actual Result Withdrawal Transaction (3) Balance: US$ 100, 00 Transaction OK Transaction Canceled Amount: US$ 90, 00 Balance: US$ 10, 00 Actual Result: fill in after the test case execution Error: Debugging

Our “Testing Process” The testing activities should start in the analysis phase, going through design and implementation phases. y OO Analysis (CRC cards and Scenarios) x Definition of input conditions x Identification of equivalence classes y OO Design (UML class diagrams) x Definition of test cases y OO Implementation (Squeak) x Execution of the test cases against the system • Use the SUnit framework x Check of the obtained results Interative Process !!! You can always return to the previous activities if necessary.

At the End… y. A well-documented test suite x. Basis for regression tests • New features or changes are added to the system y. Agreement with e. Xtreme Programming philosophy Build a little, test a little. Test first, code later.