Testing Guide

From OLPC
Jump to navigation Jump to search

Testing must be carried out at many levels, starting as early as possible in the software development process. Extreme Programming, among others, recommends writing test cases before code, and using the test cases to derive the form of the code. This drastically reduces the number of bugs to be chased down later.

  • Can this piece of code (object, method, interface, function, procedure, library, application) trust that it will never receive bad data, or does it have to test for error conditions and either correct or report them?
  • Are there external events that can cause a failure, and do we have to report them?
  • Does this thread have to worry about coordinating with others?
  • Does this code have to follow a process prescribed by a standard?

And so on.

Unit tests

Each piece of a project needs to be tested on its own against a thorough set of test cases before it is committed to a repository, and integrated with other code that must be tested together.

Regression tests

A set of tests must be created and run through for every build, to determine whether new features or fixes have broken anything that was previously working. Those tests that can be automated should be. Tests requiring human checking of results should be kept to the necessary minimum, but no less. They may perhaps be run less frequently than the fully automated tests.

Testing localized versions

There is no substitute for a human tester going through the user interface of a program and seeing whether the labels and instructions on the screen are grammatical, are unambiguous and understandable, are correctly placed, and so on. Are there any cultural errors in text, colors, layout, or anything else? Have we inadvertently walked into a double entendre? Are the functions of the software discoverable in this culture? Both professionals and end users are needed for this process.

In some cultures, new software must be approved by religious authorities to prevent possible blowups. Consulting with them on the original design can prevent a lot of trouble in the testing and deployment stages.

This article is a documentation stub, an outline for a real manual. Maybe it should be expanded, maybe it should be killed — discuss..