Testing HCI Usability Testing

Chronological order of testing Individual program units are built and tested (white-box testing / unit testing) Units are hooked together as subsystems and tested (black-box testing / functional testing) Subsystems are hooked together and tested (integration testing) System is placed in its real environment and tested (system testing) All tests are saved and rerun when changes are made (regression testing)

Unit Testing Individual routines and modules are tested

Every module should be unit tested before it is integrated into the rest of the system

Unit tests are written by the programmer who wrote the code (white-box) the programmer who wrote the code (white-box)

Logic coverage Every statement in a module tested at least once

Structured Basis Testing Is used to determine the minimum number of tests needed to test all logic paths 1.Start with 1 2.Add 1 for each potential program selection statement (if, and, or, while, do... until, for, do … while) 3.Add 1 for each case statement (plus 1 if no default case given)

What test coverage is needed for this code? if (z > m) x = a++; else x = ++a; if (y < n) w = k + x++; else w = k + --x; return x + w;

Test Case Coverage CaseTest DescriptionTest DataData Values Expect Output 1Nominal case All boolean conditions are true a = 1, z = 2, m = 1, x = 0, n = 2, y = 1, k = 5, w = 0 8 2first 'if' falsez = mz = 2, m = 210 3second 'if' falsey = nn = 2, y = 25 4first and second 'if' false z = m and y = n z = 2, m = 2, n = 2, y = 2 7

Test for bad data Too little or no data Too much data Invalid data Wrong data size Uninitialized data

Unit testing should be part of the coding process Unit tests should be written by the programmer creating the program. Problem: Tests not written after the program is written. Solution: Write test code before writing the program. More Details

XP approach -- only test things that might break Interface for a method is unclear Implementation is a bit complicated Uncertain code will work If a problem is discovered later, write code for that problem Before refactoring code

Functional Testing customer tests whether requirements are satisfied by the system (black-box)

Customer testing Customers have to determine if the system is functioning correctly and whether requirements are met Customers should write tests on a use case by use case basis. A tester should help translate the tests by the customer into automated tests.

Debugging is separate from testing Problems identified by a test must be recorded: –when was the bug discovered, –where and how it was found, –how can it be reproduced, –what component was fixed –what is the fix –who fixed it –who tested the change

OO Testing Object classes should be exercised in all possible states – all events that cause a state change in the object Integration testing is replaced by thread- based testing -- test the set of classes required to respond to an input or system event or use case scenario.

HCI Usability Testing Users give satisfaction ratings and critiques regarding interaction with the system

Poor usability = unused software Feature rich, high quality software will be shelved by poor usability. Low usability makes the user unproductive and error prone

Usability heuristics Simple and natural dialogue Speak user’s language Minimize user memory load Consistency Feedback Clearly marked exits Shortcuts Good error messages Prevent errors Help and documentation

Most difficult aspect of usability is how to define and measure it Testing is normally performed in a lab where users perform normal tasks and HCI specialists record observations Count user errors, time accomplishments The user is asked about the ease, speed and pleasantness of the application

Keys to improving usability Know the user, their work site, etc Know competing products Set a goal: such as reducing errors or increasing speed per transaction, etc Use participatory design, or prototyping Use iterative design Apply consistency to all the screens used