Software Testing ‐ 1 Xin Feng

A Lawsuit The $100,000 Keying Error Kai A. Olsen Although it sounds disastrous, making a $100,000 mistake seems relatively minor when stockbrokers have lost millions by hitting the wrong key. The following case proved to be different, however. An ordinary bank customer, Grete Fossbakk, used Internet banking to transfer a large amount to her daughter. She keyed one digit too many into the account number field, however, inadvertently  sending the money to an unknown person. This individual managed to gamble away much of the sum before police confiscated the remainder. Subsequently, the case received extensive media coverage in Norway. The Minister of Finance criticized the bank's user interface and requested new and improved Internet banking regulations.  Suddenly, the risk to Internet banking had become apparent to both the government and ordinary citizens. Clearly, the user made a slip. She also had the chance to correct the typo before she hit the confirm button. However, as we shall see, the system also had every opportunity to catch her mistake. Yet  this did not happen. The system's developers had neglected to build in a simple check that would detect if the correct input were missing. This case raises questions about what the minimum validation procedures from a banking system developed for ordinary users should be. It also challenges us, as system designers, to help users  avoid such errors. Today's users operate alone in front of a computer, with intermediates and colleagues replaced by computer systems. This new reality makes it important to have interfaces that can offer as good  as—or even better—error detection than that found in previous manual systems. FOSSBAKK CASE The Fossbakk case provides an illuminating example. The Internet system she employed when making her fatal mistake was one common to a large group of Norwegian banks. Reviewing this case  provides insight into the types of typos that users make, the psychology behind "confirmation," and the pitfalls inherent in many Web‐based transactions systems. Fossbakk's daughter's account number was 71581555022, but she inserted an extra 5 and keyed in 71581555 5022. The user interface accepted only 11 digits in this field (the standard length of a  Norwegian account number), thus truncating the number to 71581555502. The last digit is a checksum based on a modulo‐11 formula. This will detect all single keying errors and errors where two  consecutive digits are interchanged. Inserting an extra 5 changed both the ninth and tenth digits. The average checksum control will catch only 93 percent of the cases in which such errors occur. For Fossbakk, the final eleven‐digit number was a legal account number. However, only a small  fraction of all legal account numbers are in use. Further, the chance of mistyping the account number so that it benefits a dishonest person without income or assets is overwhelmingly low in a  homogeneous country such as Norway. Our user was thus extremely unlucky. The person who received her $100,000 transaction and kept the proceeds has been sentenced to prison, but this does  little to help Fossbakk get her money back. LITIGATION Fossbakk took the case to the Norwegian Complaints Board for Consumers in Banking. This board deals with disputes between consumers and banks. The board has two representatives for the  consumers and two from the banks, with a law professor as chair. In a three‐to‐two vote, Fossbakk lost. The chair voted for the bank, arguing that "she made an error and has to take responsibility."  He also regretted that Norwegian regulations set no limit for a consumer's loss in these cases, as there would have been if Fossbakk had lost her debit card. Fossbakk is now taking the case to court, backed by the Norwegian Consumer Council. She argues that she typed 12 digits and that the bank system should have given an error message in this case,  instead of ignoring all typed digits after the first 11. She has acknowledged she would have no case if only 11 digits had been typed. The bank argues that she cannot prove by any measure of  probability that she keyed 12 digits. They further state that there cannot be different rules of responsibility depending on the number of digits given. Finally, they stress that she confirmed the  $100,000 transaction. At this point, I was called in as an expert witness for Fossbakk. In my opinion, and I should expect that of most other computing professionals, a system should give an error message when the  customer types a too‐long number. Clearly, such a test can be inserted with a minimum of effort. In fact, the Financial Supervisory Authority of Norway has required all banks to implement this  functionality based on the Fossbakk case. Reasonably, we could argue that the bank showed negligence when developing the user interface in question. However, can we prove, beyond doubt, that Fossbakk keyed 12 digits? Since any digits  beyond 11 were stripped from the HTML form, no information log exists that can tell us what happened.

Is This Tested? • A $100,000 keying error Transfer a large amount of money  through internet banking Fossbakk  Fossbakk‘s daughter Fossbakk keyed the number: × 71581555 5022 Account number: 71581555 022

71581555 502 11/19/2014

Software Engineering

3

Software Testing • A very important activity to verify (验证) the software • It is used to check if the software contains bugs that clients do  not expect

11/19/2014

Software Engineering

4

Software Testing • V & V – Verification • Check if the system meets the specification • Are we building the system properly? – Validation • Check if the system meets users’ requirements • Are we building the proper system?

11/19/2014

Software Engineering

5

Software Tester • Software tester is an important role in software development • There are 9000 testers at Microsoft

11/19/2014

Software Engineering

6

Interface – Money Transfer Transfer from: Transfer to: Amount:

(The amount cannot exceed $200,000) Confirm

11/19/2014

Software Engineering

Cancel

7

Interface – Money Transfer Transfer from: Transfer to: Amount:

(The amount cannot exceed $200,000) Confirm

11/19/2014

Software Engineering

Cancel

8

Test Cases • Are these data enough? – 190000 – 200000 – 200000.01 – 199999.99 – ‐100 – 199.9.9

11/19/2014

Software Engineering

9

Test Cases • A test case （测试案例） is a combination （组合）of input  variable values of a program  – (FromAC = 12345678901, ToAC = 23456789012, Amount =  10) is a use case • Different test cases can have different effectiveness （有效性） in finding the bugs of software – Many test strategies have been proposed to generate the  suitable test cases,  – but not all of them are good at finding bugs in the software.

11/19/2014

Software Engineering

10

Test Case Generation • Types of test case generation – Black‐box testing （黑盒测试）(Functional testing) – White‐box testing （白盒测试）(Structural testing).

11/19/2014

Software Engineering

11

Black‐Box Testing • Test cases are generated based on the requirements  specification of software, rather than the source code

Test case  generation

Test cases

Outputs

Compare the  outputs with  the expected

Programs Requirements of the Money Transfer system

11/19/2014

Test report

Software Engineering

12

White‐Box Testing • Test cases are generated based on the source code of  software

Programs Test case  generation

Test cases

BOOLEAN checkAmount(int Amount) { If (Amount  Amount) { Balance = Balance – Amount; Flag = TRUE;  } if (Balance   Amount

N

Balance = Balance ‐ Amount Flag = TRUE

Y

N Balance   Amount

Balance = Balance ‐ Amount Flag = TRUE

Y

Balance   Amount

Balance = Balance ‐ Amount Flag = TRUE

Y

Balance   Amount

(Balance = 9, Amount = 10)

Balance = Balance ‐ Amount Flag = TRUE

Y

Balance   Amount

(Balance = 9, Amount = 10)

Balance = Balance ‐ Amount Flag = TRUE

Y

Balance   Amount

(Balance = 9, Amount = 10)

Balance = Balance ‐ Amount Flag = TRUE

Y

Balance   Amount

(Balance = 9, Amount = 10)

Balance = Balance ‐ Amount Flag = TRUE

Y

Balance