Understanding the difference between testing in HCI and software development?
Software:
The testing of a piece of software deals with trying to catch what you
expect to go wrong against a known recurrent problem
eg. Forgetting semicolon in pascal;
HCI:
"I never thought about this issue!!":
About catching unexpected problems. The first test run of a program is often
the most important and can reveal things not outlined in the requirements
capture.
eg. the Takoma Narrows Bridge, build in the 1930's, which
collapsed during a cyclone. Since then all bridges are tested in wind tunnels. The example
illustrates how the design methods have evolved creating unforseen problems and
therefore new methods of testing are necessary.
Problems that HCI deals with:
1. Humans are unpredicable because of different
attitudes, expectations and previous experiences.
2. Unexpected problems are often the result of gaps in the requirements
capture.
Possible questions during the testing and design of an interface:
The trade-offs between types of users? - novice versus experienced
It is a good idea to be alert to ideal solutions to satisfy problems both at
once eg. Mac keyboard shortcut keys in addtion to menus.
eg. The design of a computer version of a phone directory. Ideally for a high speed search font size should be a minimum, but once found, for ease of reading the font size should be a maximum. This highlights different needs within a program.
The approach to the design solution
Does it benefit users?
User Centred System Design (UCSD) is an approach to system design which is intended to benefit users of the system. This is not the same as asking what the user wants. But REMEMBER- People are better at saying what they don't like as oppsed to what they want. Therefore it is important to do real user testing
The solution
Generally software testing is carried out at the end of the design process in order to verify that the program works. In the design of an interface the testing cycle will be repeated many times during development.
Methods
1. Observe symptoms
2. Interpret symptoms
3. Decide design modification
This is an interactive cycle approach, and this should be repeated several times during the process.
Testing methods must be open ended as the problems evolve along with the software design. Remember you can not predict what the problems are going to be.
Who did what in the team? Jenny & Helen agonised over the text, while the graphical interphase was designed by Lara & Lesley
Remarks on whether the exercise was useful, impossible; whether different tools might have made the collaboration work better. This has not been decided yet........
Any more contributions to the page are welcome.....