Other Types of Testing

for RuBoard

A number of books draw a distinction between testing, code reviews, walkthroughs, and software quality assurance in general. Not this one. From my vantage point, these are all forms of testing. Or, perhaps to say it better, testing is one of many means of ensuring software quality. Whether you're talking about a walkthrough or a code review, the purpose is to identify flaws in the software so that they may be addressed. They are part and parcel of the same activity, and perform the same function in the software development cycle, so, at least in this book, they are grouped under the heading of testing.

That said, these other forms of testing, or other means of ensuring software qualityhowever you want to refer to themare crucial to building good software, so we should explore them. Let's begin with general software quality assurance. The very term sounds sterile and is a bit of a mouthful, but it's really what testing is all about. I briefly considered titling this chapter something like "Ensure Software Quality" or "Ensure Software Solidity," but felt these were too formal. Testing is about ensuring software quality. Improving software quality is the reason we test in the first place. We want applications that are as bug free and functional as possible. We want to publish high-quality software, so we test it before giving it to users.

When programmers talk about testing, they're usually talking about unit testing. As I've said, there are many kinds of testing, and unit testing is just one of them. Unit testing is not the only means of ensuring software quality, and, according to Steve McConnell, [9] it's not even the best way. In fact, according to McConnell, [10] testing in generalwhether it's unit, functional, or integration testingis less than 50% effective at finding bugs before a product is shipped.

[9] McConnell. Code Complete . Redmond, WA: Micosoft Press, 1993. Page 571.

[10] Ibid. Page 574.

What does this tell us? If testing can't find all the bugs, what can? The trick isn't to find the bugs, the trick is to avoid them in the first place. The moral here is that you can't test quality into software. You have to design and plan for it. Software quality assurance must be systematic. You must design and consistently follow a standard process to ensure it. With this in mind, let's examine some of the other methods of improving software quality.

Code Reviews

According to McConnell, [11] code reviews provide a better means of improving software quality than any form of traditional testing. What is a code review? A code review is an examination of a programmer's code by another programmer or team of programmers. Code reviews should be constructive, nonjudgmental affairs that reinforce good practices as much as they discourage bad ones.

[11] Ibid. Page 587.

Code reviews benefit software quality in many ways. First, they allow less experienced developers to leverage the experience of veteran developers. Lessons that took experienced developers a long time to learn can be quickly and easily disseminated to other developers through code reviews. The junior developer is able to learn from the veteran through the veteran's comments about her code. So, not only is the quality of today's code improved, the quality of tomorrow's code goes up as well because the junior developer learns better development techniques because of the review.

Code reviews give technical managers a tool for determining project progress and measuring the quality of a developer's work. They allow managers to determine whether the coding is actually being done and whether it is being done correctly. Essentially, code reviews become a tool for assessing quality at the individual developer and coding level. They give the technical manager what he needs to correct quality problems before these problems get out of hand.

Code reviews have a tendency to improve software quality overall in unexpected ways. If you know that your work will be reviewedthat the standard of completeness isn't limited merely to compiling and running the codeyou'll probably be much more likely to check and recheck your work. Numerous studies have confirmed this behavior. [12] Also, you'll find that explaining a coding problem is often all you need to solve it. The answer occurs to you midway through the explanation. I've been on the receiving end of this many times, and have observed it numerous times in others. Having to explain a problem to someone else forces you to think about it clearly and analytically, and that's often all you need to solve it.

[12] Ibid.. Page 574.

Code Reading

You can think of a code reading as a "distributed code review." People take copies of source code, read it, then comment on it regarding style, quality issues, and, of course, defects. Typically, they meet to discuss these issues with the author of the code, but e-mail is very effective for this as well. The value in meeting personally is that the readers can discuss their comments with the author and possibly come to understand why she wrote the code as she did. Also, the author can better understand what issues there might be with her code and why she should address them.

Inspections

An inspection is a specific type of technical review that focuses on detecting (not fixing) problematic parts of a system. It is not moderated by the author of the software, but by someone trained in moderating inspections. Those participating in an inspection play specific roles and prepare for the inspection by identifying areas of concern in advance. Management should be discouraged from attending inspections. Inspections are supposed to be technical in nature, and management's mere presence can inhibit this.

A key difference between an inspection and a code review is that a report is prepared after an inspection that lists the defects detected by the inspection. The process is much more formal than the typical code review. During a code review, the code's author might take notes regarding suggested changes to his code, and then again, he might not. He might change the code on the spot. It depends on the significance of the change. No coding changes are made during an inspection. The purpose of the exercise is to gather information about flaws in the software and issues that need to be addressed so that they can be dealt with later and can be tracked over time.

The inspection report helps track the defects that need to be corrected as well as identify problem areas in the system. When the inspection is repeated, the previous inspection report will serve as input for the process: Problem areas will be rechecked.

Inspections are common in medium- size and large organizations, but are relatively rare in small ones. They require a team of people and specific training, and resources of this type are often hard to come by in small companies.

The moderator plays a very important role during inspections. The moderator keeps egos from colliding and keeps the meeting focused on technical and business concerns rather than personal ones. She keeps the meeting from becoming a public flogging of the author, while still objectively evaluating the software.

If you're the author of software under inspection, try not to be defensive about your work. This is the worse thing you can do. Listen to the criticisms of it and acknowledge each one. Merely acknowledging a criticism doesn't mean that you agree with it. It means that you recognize that the person bringing the criticism has a concern and that that concern is important enough for you to look into. You should expect a certain number of invalid criticisms and points that seem questionable. Don't worry about it. Later, you can investigate each point privately and decide whether and how to respond to them. When you do respond, don't make it a matter of personal vindication. You were never under personal assault. This is about your work, not you, and as long as you're conducting yourself in a professional matter and doing your job competently, it will likely stay that way.

Walkthroughs

A walkthrough is a loosely defined technical review. Walkthroughs can be many things. Usually they're a sort of code review/inspection hybrid. Typically, they are conducted by the author of the code under consideration, and focus on determining ways of improving the code's quality. As with code reviews, a walkthrough presents a way for junior-level developers to learn from senior developers, and for junior developers to present fresh alternatives to techniques espoused by the veterans on the team.

Walkthroughs are popular because they can mean just about anything. The meeting might be more formal, with slides and a scripted presentation; or it might be informal, with the author of the software simply talking about what he's done and why. Typically, a walkthrough is not a terribly long meeting (usually less than an hour ) and doesn't involve management. It's a flexible type of meeting that can be adapted to a variety of uses depending on the requirements of the parties involved.

for RuBoard


The Guru[ap]s Guide to SQL Server[tm] Stored Procedures, XML, and HTML
The Guru[ap]s Guide to SQL Server[tm] Stored Procedures, XML, and HTML
ISBN: 201700468
EAN: N/A
Year: 2005
Pages: 223

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