Hi all,

Some background and then a return to the actual question asked.

UATs are really supposed to be the part of the process where it is 
demonstrated that the product/project/whatever meets the users' 
requirements.

In a very simple system, it's possible to construct a test that 
exercises every route through the software and proves that it comes 
out with the right answer. Years ago, I constructed such a test on a 
rather simple hand-held device. (It had to be simple, this was 1981). 
We shipped that baby defect-free.

But, realistically, some sort of sampling of possibilities is 
necessary. Which requirements are going to be tested? How will they be 
tested? And, given that software typically gets delivered in stages 
(due to a combination of defects and phased functionality), how will 
they be repeated?

It's really the 'repeated' bit that leads to the construction and 
running of scripts - as mentioned by Bill Killam. Typing in my test 
script, years ago, got pretty tedious on the fourth or fifth shipment 
from the supplier. So there are automated tools that help.

But it's the 'requirements' bit that should really dominate the good 
UAT. If you don't have something in the requirements about usability, 
tough luck - it's not getting in the UAT. If you do have something, 
then it's a good idea to ensure that you specify the test route (that 
is, testing with users) at the same time as specifying the 
requirement.

Here in the UK, there is a small group called '13407 in Government' 
that has been working with some success towards incorporating 
user-centred design as a requirement in Government contracts by 
specifying that the design approach must conform to ISO 13407.

If that doesn't work for you, consider following a modern requirements 
process such as that described in Robertson and Robertson (1999) 
_Mastering the Requirements Process_. Addison-Wesley. For us usability 
types, it may seem like it doesn't have enough about usability in it. 
But the point is: it does have usability in there, and may show you 
how to wean your organisation from relying purely on functional 
requirements.

And now back to your question:
>Has anyone been able to get usability engineering into a software
>development process by becoming involved in the User Acceptance 
>Testing?

Sure. Preferably by getting involved at the point where the UATs are 
specified - which should be early enough for usability engineering to 
make a difference. If you wait until the point where the UATs are 
being conducted, it's generally too late.

Best,

Caroline Jarrett
[log in to unmask]
01525 370379

Effortmark Ltd
Usability - Forms - Surveys 

    --------------------------------------------------------------
        Tip of the Day: Forward out-of-office replies to
                    mailto:[log in to unmask]
     CHI-WEB: www.sigchi.org/web POSTINGS: mailto:[log in to unmask]
              MODERATORS: mailto:[log in to unmask]
       SUBSCRIPTION CHANGES & FAQ:  www.sigchi.org/web/faq.html
    --------------------------------------------------------------