Testing HCI Usability Testing

1
TestingHCI Usability Testing
2
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)

3
Unit Testing

• Individual routines and modules are tested

4
Every module should be unit tested

• before it is integrated into the rest of the
  system

5
Unit tests are written by

• the programmer who wrote the code (white-box)

6
Logic coverage

• Every statement in a module tested at least once

7
Structured Basis Testing

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

8
What test coverage is needed for this code?

• if (z gt m) x a
• else x a
• if (y lt n) w k x
• else w k --x
• return x w

9
Test Case Coverage
Case Test Description Test Data Data Values Expect Output
1 Nominal case All boolean conditions are true a 1, z 2, m 1, x 0, n 2, y 1, k 5, w 0 8
2 first 'if' false z m z 2, m 2 10
3 second 'if' false y n n 2, y 2 5
4 first and second 'if' false z m  and y n z 2, m 2, n 2, y 2 7
10
Test for bad data

• Too little or no data
• Too much data
• Invalid data
• Wrong data size
• Uninitialized data

11
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

12
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

13
Functional Testing

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

14
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.

15
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

16
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.

17
HCI Usability Testing

• Users give satisfaction ratings and critiques
  regarding interaction with the system

18
Poor usability unused software

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

19
Usability heuristics

• Simple and natural dialogue
• Speak users language
• Minimize user memory load
• Consistency
• Feedback
• Clearly marked exits
• Shortcuts
• Good error messages
• Prevent errors
• Help and documentation

20
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

21
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