User Acceptance Testing(UAT) is generally done after the SIT(System Integration Testing) has been done. It is done by the end user.
Usability Testing is considered to be a part of System Testing done by the testing team. It is done to check how user friendly the aplication is.
UAT is usually done for all applications. Usability testing may or may not be done for all applications
Usability Testing is considered to be a part of System Testing done by the testing team.
[/ QUOTE ]
This comment is so wrong on so many different levels. I'm not fully going to get into but please do your research before posting. Usability testing is done by using real end users and is done in the design phase initally waaayyyy before system testing.
[ QUOTE ]
Usability testing is done by using real end users and is done in the design phase initally waaayyyy before system testing.
[/ QUOTE ]
That is ONE point of view. But it is not the only one. Your statement was as dogmatic (and narrow) as the one you slammed.
Uasability covers many aspects, some of which cannot be effectively tested until at least the application interface exists. Response times could also be considered a factor in usability, and while they can (up to a point) be included in the design, they cannot be tested until the AUT (or at least a part of it) has been built.
And who is to say that "real end users" are the only ones to perform usability testing?
I would hate for people to read imemyself’s posting and think that is Usability Testing. You could loosely take Usability testing and apply it to other things you mentioned but response times really shouldn't fall under Usability Testing as true Usability testing is the GUI front end and its ease of use and intuitiveness nature. Response time should be captured in Requirements and then tested through Load/Stress Testing. I see people on this site all the time “slamming” others for expressing different points of views and even just for asking questions in the wrong thread line. So I didn’t think it was out of line for me to say.
I thought it was extremely important for the masses to understand what traditional Usability is and it's not just another type of testing that happens at the end of the lifecycle. It's extremely important to do it in the design phase for it to be cost effective. You also can conduct Usability testing at the end in construction but if you find major design/navigational issues then you've wasted a lot of $$ coding against a design that isn't effective and is flawed.
To most effectively perform Usability Testing you would want real end users because that's who your building the system for. You can have Usability experts perform Walkthroughs on the application or web site but if they would not be a true user of the product then you could miss some large usability issues that way.
So yes, much like everything you can take a topic like Usability Testing and define it in many ways. I was just trying to steer people to the core definition and practice where it's most cost effective and makes the most sense.
You can test on prototypes or paper mock-ups in the design stage. We have had successes testing with each. You definitely get more detailed results when using a prototype since people react better when they can use something as if it were a 'real' application.
One definition of dogmatic is 'characterized by assertion of unproved or unprovable principles' so I was taking that angle of the definition when I supported my statements with including references to websites where this same content can be found.
If you test from paper mock ups and prototypes at the design stage you can iron out some usability issues and this is good to resolve some issues at an early stage. However in my experience testing in this way is all well and good but all to often the end solution does not match the prototypes or paper mockups as the design develops through construction.
The only way to ensure good quality usable software is to test it once the software has been produced and then to feed these usability issues back to the development team.