Testing

Differences between revisions 1 and 2
Revision 1 as of 2005-10-25 13:39:35
Size: 1410
Editor: henrik
Comment: new spec
Revision 2 as of 2005-11-28 17:06:46
Size: 1955
Editor: henrik
Comment: lessons from the HandsFreeEmailing spec
Deletions are marked like this. Additions are marked like this.
Line 22: Line 22:
Perform test in several categories: The HandsFreeEmailing spec was fairly successful, because it encourages testers and developers to see the Ubuntu system from the perspective of a disabled computer user.

We should expand this concept to a range of well-defined use cases and also define a set of typical tasks users might want to perform. The result from this testing will be a set of bug reports and feedback helpful for developers, but also some advice on how best to perform these tasks that might be useful for affectrd users.

 * ["/UserGroups"]
 * ["/Tasks"]

Existing test categories (less useful):
  • Launchpad Entry:

  • Created: 25.10.2005 by HenrikOmma

  • Contributors:

  • Packages affected: Gnopernicus, GOK, Dasher, BrLTTY, Kmag, Kmousetool, and Kmouth (and possibly anything in Ubuntu desktop).

Summary

Design a structured testing process for the accessibility features in Ubuntu.

Rationale

Most Ubuntu developers and even most of our user community never use the accessibility features during their daily work, because they don't need them. At the same time, the traditional users of this technology are often not early adopters of new distros (or Linux at all) or typical beta testers, because they rely on this technology to be available on their platform to make use of the computer at all. As a result many of these features go untested until after the distro is released and major components such as Gnopernicus have often been broken at release time. With a structured testing plan like LaptopTesting we can catch these issues earlier.

Use cases

Scope

Design

The HandsFreeEmailing spec was fairly successful, because it encourages testers and developers to see the Ubuntu system from the perspective of a disabled computer user.

We should expand this concept to a range of well-defined use cases and also define a set of typical tasks users might want to perform. The result from this testing will be a set of bug reports and feedback helpful for developers, but also some advice on how best to perform these tasks that might be useful for affectrd users.

Existing test categories (less useful):

Implementation

Code

Data preservation and migration

Outstanding issues

BoF agenda and discussion


CategoryAccessibility CategorySpec

Accessibility/Specs/Testing (last edited 2008-08-06 16:31:55 by localhost)