Tekst źródłowy strony Usability testing protocol

This page is in early development.

This page describes the recommended end-user testing that new features should undergo before being added to Moodle.  The process is intended identify difficulties or confusion that targeted users might encounter and communicate that information during appropriate parts of the development cycle for the purpose of improving the end-user experience.

=Testing Phases=

==Developer questionnaire==
This will include items such:

* who the targeted user is (Site administrator, power-user teacher, standard teacher, student, etc.)
* what end-user testing has the developer already undertaken, if any (and what was learned from this)
* what level of instruction or training is anticipated to use the feature, or whether the developer feels the feature's use is self-evident and intuitive
* what other interface is this feature similar to or was inspired by (either within Moodle or with another application)
* whether all features are included in the current form for the next anticipated release of the feature

==Task list devised==
Tasks the developer wants the end user to try to perform should be listed. If the feature was originally specified in terms of use cases, then this list will probably be a subset of the use cases. There should also be the opportunity for additional tasks to be added by the end-user based on his or her perception of how the feature will be used.

In some cases it may be best to use actual data in performing a task when appropriate to find issues that will happen in practice.  Coordination should be made with the subject being tested to make sure the environment and data are similar to what will be used in practice.

==End-user test subjects identified==

It should be recognized that there are diminishing returns to adding more testers in most cases.  The most significant results will be found with observations made by the first subject who is a typical end-user.  Still, when possible, users in different environments such as schools, distant learning courses, trainers, professors of large university classes, users with limited technical skills, etc. can add additional perspective and should be included if their use may be significantly different.

==Testing transcript==

Ideally the end user will be observed as she/he attempts to perform the items on the task list and notes should be taken of the process and difficulties.  The observer should try not to give assistance during the process, but when help is needed, notice should be made of what assistance was required.

When an observer is not available, the end-user should describe the experience and steps and difficulties encountered in the testing process.

See also (Comments and edits welcome!):
* [[Development:Quiz_UI_redesign_-_prototype_testing_background|Quiz UI redesign Test setting and tasks background]]
** [[Development:Usability_testing_in_August_2008/Test_setting_and_tasks_/_background#Test_design|further details]]

==Summary and suggestions==

Based on what happens during testing, a summary and set of recommendations should be constructed to be communicated to the developer.  It should include a recommendation as to what degree additional refinement and retesting is needed.  These reports need not be lengthy.  If a feature is well designed few if any recommendations are needed.  If it has many usability issues, that should be communicated with a few areas to be addressed first.

==Collation==

If multiple institutions did testing, a coordinator should collate the findings and give a quick summary of what were common themes and differences and give a summary recommendation.

==Refinement and retesting==

Based on the feedback received, the developer should make decisions on refining the feature to improve usability.  He or she should make some sort of response to the feedback and if changes made are significant the feature should be resubmitted for going through the retesting protocol.

=Helpful references=

==See also==
* The least resource-intensive testing donce for Moodle so far? [http://www.pilpi.net/software/moodle/2009/08/19/quickie-usability-testing-file-upload-and-forgotten-password/ Quickie Usability testing] of Summer 2009 
* Some of the work done for the [[Development:Quiz_UI_redesign|Quiz UI redesign]] project.
* Syndia Lengyel's work in her [http://moodle.org/blog/index.php?postid=4286 Moodle.org blog]
* [http://www.w3.org/WAI/EO/Drafts/UCD/questions.html WAI Site Usability Testing Questions]

==Web resources==

* http://en.wikipedia.org/wiki/Usability_testing

* http://fluidproject.org/

* http://www.usability.gov/

* http://www.utexas.edu/learn/usability/

==Conferences==

* http://www.uie.com/events/uiconf/2008/

==Journals==

* http://www.upassoc.org/upa_publications/jus/jus_home.html

==Books==

* Don't Make Me Think: A Common Sense Approach to Web Usability ISBN 0321344758

* Designing Interfaces: Patterns for Effective Interaction Design ISBN 0596008031

* Handbook of Usability Testing: ISBN 0470185481

* Moderating Usability Tests: ISBN 0123739330

* Measuring the User Experience: ISBN 0123735580

[[Category:Usability]]