Testing

Introduction

After a project is broken down into tasks, and tasks selected, the pair working on a task must be able to determine, with confidence, that the task is complete and correct. XPers do this by writing software tests. They write a test, change the code to make the test pass, then add another test and repeat the cycle. When all the tests pass and they can't think of any more tests, the task is done.

Testing Alternatives

Most XPM tasks can't be tested with software, so we must devise alternatives to give us that same level of confidence. Here are some examples of testing alternatives:

Testlists

Similar to checklists, we can develop a list of tests for each task. If the task satisfies each list item and we can't think of any more tests to add, the task is done. Where possible, we should automate specific tests. For a more complete discussion of testlists, see testlists.

Examples

Examples are a step up from testlists in the testing hierarchy. They show the result of applying all testlist tests. If faithfully adapted to a task, examples can provide the same level of confidence as testlists.

Standard Details

Standard Details are a step up from examples in the testing hierarchy. A standard detail is an adaptation of an example to a specific instance. Ideally, standard details have been tested in practice, so we know they work as expected. We may need to supplement standard details with testlist tests to determine if the standard detail is appropriate for its intended use.

Mistake-Proofing

Based on Japanese "poka-yoke" manufacturing practices, we can perform tasks in such a way that errors are amplified and thus easily observed and corrected.

Meeting Agendas

Tasks that require meetings can be based on meeting agendas, adapted from testlists.

Standard Forms

Many tasks involve collecting information or material. Standard forms help assure that all appropriate material is collected. Standard forms can be adapted from testlists.

Prototypes

Develop a prototype, and use it as the standard on which other drawings are used. See using prototypes.

Form Letters

Tasks that require written communications can be based on form letters; the form letters based on testlists.

Peer Reviews

If testing alternatives are insufficient and we are not confident that a task is correct and complete, we can, as a last resort, rely on peer reviews. Peer reviews, and pairing, which is a form of peer review, are usually not adequate by themselves to provide a confidence level equivalent to actual testing.

Improving Testing Alternatives

The testing alternatives described above are effective because, like software tests, they provide feedback almost immediately. On the other hand, in architecture, there are other, delayed, feedback loops involved: during construction, after completion of construction, and after long-term use. During each of these time periods, we have an opportunity to evaluate whether or not our work is performing as expected and to improve our tests accordingly.

Testing Library

This site has a section dedicated to providing testing alternatives for specific tasks involved in architecture: See the project checklists home page.

Printer-Friendly Version

Click here for a version of this page that's more suitable for printing. After printing, click the back-arrow of your browser to return to the original format with an index alongside.

Feedback Wanted

I welcome your comments and suggestions. See contact us for more information.

Copyright 2004, Dennis V. O'Neill