Group Validation ★

Testing homemade screen door for strength.

...an activity such as analysis, design, or implementation has been completed and is to be assessed.

✥ ✥ ✥

Product quality is crucial to the success of the enterprise. The job of QA is to assess quality. QA usually assesses the quality of the end product, doing only black-box validation and verification. A group setting brings many insights on product problems and opportunities. Individuals may not have the insight necessary to discover the bug plaguing the system (this may be an issue of objectivity).

Therefore:

Even before engaging QA, the development team — including the Customer — can validate the design. Techniques such as CRC cards and group debugging help socialize and solve problems. Members of a validation team can also work with QA to fix root causes attributable to common classes of software faults.

The software shouldn't be the only focus of debugging and review. Recurring types of software bugs may point to systemic problems in the structure of the organization itself. For example, if the project is seeing a high rate of mismatches in interfaces between components, it might be that integration is taking place too quickly for all the team members to keep in step with the current state of the architecture. The organization can write new patterns to solve these systemic problems (UpdatingThePatterns). See [BibRef-Fagan1976].

✥ ✥ ✥

One can create a culture where the quality of the system is constantly brought into focus before the whole team. Problems will be resolved sooner than if they are deferred to the "official" Quality Assurance function, which typically interacts with the project at the boundaries of design and coding. The cost of this pattern is the time expended in group design/code debugging sessions.

The CRC design technique has been found to be a great team-building tool and an ideal way to socialize designs. Studies of projects inside AT&T have found group debugging sessions to be unusually productive. Bringing the customer into these sessions can be particularly helpful. The project must be careful to temper interactions between Customer and Developer, using the patterns mentioned in the Resulting Context.

There is an empirical research foundation for this pattern. See "An implementation of structured walk-throughs in teaching COBOL programming," CACM, Vol. 22, No. 6, June, 1979, which found that team debugging contributes to team learning and effectiveness. A contrary position can be found in [BibRef-Meyers1978], though this study was limited to fault detection rates and did not evaluate the advantages of team learning.

There are times when reviewing need not be a group effort; sometimes, all it takes is a little help from a friend. DevelopingInPairs is one example; the kind of desk checks mentioned in [BibRef-Votta1993], where one person liberally marks up the work of another, also can be effective (Votta shows that this mode of review is almost as effective and much less costly than a meeting). The Creator-Reviewer pattern [BibRef-Weir1998] calls this a "distribution review" as opposed to a "meeting review". Doug Lea once took this approach to an extreme, working on a one-person Clean Room programming team where he played the roles both of programmer and of reviewer, with no use of a compiler to validate the code between the steps (see DevelopingInPairs). We imagine the psychological forces must have been both interesting and compelling.

StandUpMeeting is an informal form of this pattern.