Section 5.2. Deskchecks


5.2. Deskchecks

A deskcheck is a simple review in which the author of a work product distributes it to one or more reviewers. In a deskcheck, the author sends a copy of the work product to selected project team members. The team members read it, and then write up defects and comments to send back to the author. Work products that are commonly reviewed using a deskcheck include vision and scope documents (see Chapter 2) and discussion summaries (see Chapter 6).

There are times when a full inspection is neither necessary nor useful. Some work products do not benefit enough to warrant the attention of an entire inspection team because they do not need consensus or approval. In these cases, the author simply needs input from others to prevent defects, but does not require that they approve the document. In these cases, the deskcheck is a useful review practice.

Unlike an inspection, a deskcheck does not produce written logs that can be archived with the document for later reference. There is no follow-up meeting or approval process. It is simply a way for one team member to check another's work. Deskchecks are not formal reviews (where "formal" simply means that it generates a written work product that meets a certain standard and is archived with the rest of the project documentation); there is no standard for the results of the deskcheck. The reviewers simply review the work product and return the results. There is no moderator, and there is not necessarily any consensus generated.

But, despite the lack of formality, the deskcheck is a very important tool for a project team, and there are many times when the project manager will build deskchecks into the organization's software process. If a work product does not need approval by a team but is still a critical part of the software process, the project manager may require a deskcheck in order to ensure that it does not have defects. For example, many QA teams employ automated test scripts, and it is usually necessary to ensure that the finished automated product actually covers the test plan that it was meant to automate. However, it would be unnecessary and very time-consuming to ask programmers, requirements analysts, project managers, and stakeholders to cross-reference each script with a test plan. A deskcheck can be used to verify that the script is correct, and to ensure that more than one QA engineer has taken responsibility for the quality of the script.

Sometimes a checklist is used to ensure that the work product meets the organization's standards. However, unlike an inspection, a deskcheck can be performed without a checklist. The deskcheck usually relies entirely on the reviewer's knowledge of the project and professional standards for the work product.

Figure 5-2 contains an example of comments from a deskcheck that was used by a tester to find defects in an automation script. In this case, the entire review was performed via email: the author mailed the script to the reviewer, and the reviewer read it and emailed the comments back to the author. These comments are much simpler than the inspection log in Figure 5-1. In an inspection, each log entry must either resolve a defect or indicate that it is an open issue that must be resolved. Deskcheck comments can simply point out issues or raise questions without having to supply solutions or promise a resolution. There was no follow-up or approval, and the reviewer had no more contact with this script.

Figure 5-2. Sample deskcheck comments


Deskchecks can be used as predecessors to inspections. In many cases, having an author of a work product pass his work to a peer for an informal review will significantly reduce the amount of effort involved in the inspection. Many defects can be caught by a single person reviewing a document. Approval and consensus is built later on during the inspection meeting; this is simply a way of saving effort. After a deskcheck, many authors will feel much more comfortable sending their document into an inspectionit will often help the author to be more objective and to take the inspection comments less personally.

Finally, a deskcheck can be useful to review a work product that is not meant to be inspected at all. For example, many requirements analysts will generate a discussion summary after a series of interviews and elicitation sessions (see Chapter 6). This is not a work product that is used in later stages of the software process; rather, it is an intermediate document used to generate the software requirements specification. A deskcheck is useful in this case to help interviewees and other requirements analysts identify any information gathered during the interviews that is inaccurate or unclear. No approval is needed, and the requirements analyst is free to ignore any of the comments. The deskcheck simply serves as a checkpoint to ensure that mistakes are caught and addressed as early as possible.


Note: More information on deskchecks can be found in Peer Reviews in Software by Karl Wiegers (Addison Wesley, 2002).


Applied Software Project Management
Applied Software Project Management
ISBN: 0596009488
EAN: 2147483647
Year: 2003
Pages: 122

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net